variable vs. immutable

Premises with Uncertainty.

  • 0, each entity may be immutable.
  • 1, a package may be variable.
  • 2, a device could be independently variable.

Rules with Certainty.

  • 0, a programmer should not assume any entity is definitely variable.
  • 1, only package and its descendants may be locally replaced.
  • 2, an independently variable property of a device must be accessed by a function implemented in native code.

Supplements about Local-Replacing.

  • 0, “impl”, “enable” and “disable” will try to apply local-replacing for the package.
  • 1, a class can explicitly provide a Local-Replacing Method, which name should start with a “$”.
  • 2, a LRM is also an instance method.
  • 3, in a LRM, all explicitly This-Calls will try to use corresponding LRMs. – ?
  • 4, in a LRM, all explicitly Base-Calls will try to use corresponding LRMs. – ?
  • 5, in a loop, all explicitly Last-Calls will try to use corresponding LRMs. – ?
  • 6, if a LRM without a normal version of method, the runtime will generate one which works like ‘((this:clone ):$method …)’.
  • 6, if a LRM without a LRM, the runtime will try to call its normal version.

closure - computer science vs. mathematics

0,closure in computer science.
In computer science, a closure (also lexical closure or function closure) is a function or reference to a function together with a referencing environment. – Wikipedia

1,closure in mathematics.
A set has closure under an operation if performance of that operation on members of the set always produces a member of the same set. – Wikipedia

2, the core functions of foolang should make up a closure in meaning of mathematics.
2.0, option-1: to keep the existing relatively complex structure.
2.0, option-2: to reduce it to a simple model.- like lisp?

foo – syntax of local-replacing hint.

0, semantics.
0.0, level-entity: notify the runtime to try the local-replacing as much as possible.
0.1, level-reference: level-entity + save the result to the same reference – it looks like performing an update.

1, syntax.
1.0, level-entity-func: (&func …)
1.0.0, (impl this …) => (&impl this …)
1.0.1, (impl stmt …) => (&impl stmt …) – reasonable?
1.0.2, (impl ref …) => (impl ref …)
1.0.3, (&impl ref …) => (&impl ref …)

1.1, level-entity-pkg: (&pkg:method …)
1.1.0, (this:method …) => (&this:method …)
1.1.1, (stmt:method …) => (&stmt:method …) – reasonable?
1.1.2, (ref:method …) => (ref:method …)
1.1.3, (&ref:method …) => (&ref:method …)

1.2, level-reference-func: ($func target) => (decl target (&func target))
1.2.0, ‘target’ must be a reference.

1.3, level-reference-pkg: ($pkg:method …) => (decl pkg (&pkg:method …))
1.3.0, ‘pkg’ must be a reference.

foo – generic semantics

0, fundamental concepts
0.0, reference – identifiers, static, environment.
0.1, evaluation – statements, dynamic, variation, evolution.

1, fundamental elements
1.0, list – fixed-point, static.
1.1, eval – evaluating, dynamic.
1.2, quote – evaluable, transitional.

2, static-based semantics
2.0, (…) – fixed-point.
2.1, (quote …) – evaluable.
2.2, (eval …) – evaluating.

3, dynamic-based semantics
3.0, (…) – evaluating.
3.1, (quote …) – evaluable.
3.2, (list …) – fixed-point.

4, comparison of them.
4.0, static-based is more easy to build a tree.
4.1, dynamic-based is more easy to express evaluating.