Allocation | Uniqueness | Binding | Allocators | Shared-Memory | Optimzing |
allocator-label ::= label format ::= identifier section-label ::= label format ::= identifier shared-area-label ::= label format ::= platform-dependant allocation ::= an [allocator-label] | the [section-label] | my | our | same shared-area-label
Each variable name must be unique with the current scope. That means that it is illegal to have an index integer 'i' in a 'for' loop, and another integer 'i' in a loop nested within.
Please note that full-type is defined under type definition.
var-names ::= identifier [ds] [list-start expression list-end] | list-start var-names [step var-names]... list-end typed-vars ::= full-type [[s] unit-label] [s] var-names | list-start typed-vars [step typed-vars ]... list-end new-vars ::= allocation s typed-vars
Note that initialisation is not an assignment! During assignment there is a previous value which is destroyed, and some variables (constants) can not be assigned.
my Integer i(0); my Integer (a1(0); a2(a1)); # both initialized to zero, note the semi-colon my Integer (b1(0), b2(1));
...
The value of shared-area-label is fully platform (or perhaps even compiler) dependant.
All 'the' variables with the same section label will be allocated consequtive, followed by the next group of 'the' variables with the same label, etcetera. The order of the labels is unicode order. 'the' variables without a label are considered to have the label 'main', but this can be overruled by a compiler flag.
This can be used to store all frequently used variables in the same page(s), thus decreasing swap time.
Nota Bene: this is an optimalization which should take place (if at all) after the project is finished and extensive profiling has been done.