5.2. Units associated with names {Names may be assigned to {5.2.1 }, compared with other names {5.2.2 } and created {5.2.3}.}
5.2.1. Assignations {In assignations, a value is "assigned", to a name. E.g., in x := 3.14, the real number yielded by the source 3.14 is assigned to the name yielded by the destination x.}
5.2.1.1. Syntax a) REF to MODE NEST assignation{5A } : REF to MODE NEST destination{b}, becomes{94c } token, MODE NEST source{c}.
b) REF to MODE NEST destination{a} : soft REF to MODE NEST TERTIARY{5B } .
c) MODE1 NEST source{a,44d } : strong MODE2 NEST unit{32d } , where MODE1 deflexes to MODE2{47a,b,c,-}. {Examples:
}
5.2.1.2. Semantics a) An assignation A is elaborated as follows:
· let N and W be the {collateral} yields {a name and another value} of the destination and source of A;
· W is assigned to {b}N;
· the yield of A is N.
b) A value W is "assigned to" a name N, whose mode is some 'REF to MODE', as follows: It is required that
· N be not nil, and that
· W be not newer in scope than N;
· that field is assigned to the
subname selected by 'TAG' in N;
· let V be the {old} value
referred to by N;
· it is required that the descriptors of W and V be identical; For each index I selecting an element in W,
· that element is assigned to the subname selected by I in N;
· let V be the {old} value
referred to by N;
· N is made to refer to a multiple value composed of
· N is endowed with subnames
{2.1.3.4.g
}; For each index I selecting an
element in W,
· that element is assigned to the subname selected by I in N; Other Cases {e.g., where 'MODE' is some 'PLAlN' or some 'UNITED'} :
· N is made to refer {2.1.3.2.a } to W. {Observe how, given
FLEX [1: 0] [1: 3] INT flexfix, the presence of the ghost element {2.1.3.4.c } ensures that the meaning of flexfix := LOC [1: 1] [1: 3] INT is well defined, but that of flexfix := LOC [1: 1] [1: 4] INT is not, since the bound pairs of the second dimension are different.}
5.2.2. Identity relations {Identity-relations may be used to ask whether two names of the same mode are the same.
E.g., after the assignation draft := ("abc", NIL), the identity-relation next OF draft :=: REF BOOK(NIL) yields true. However, next OF draft :=: NIL yields false because it is equivalent to next OF draft :=: REF REF BOOK(NIL); the yield of next OF draft, without any coercion, is the name referring to the second field of the structured value referred to by the value of draft and, hence, is not nil.}
5.2.2.1. Syntax a) boolean NEST identity relation{5A } : where soft balances SORT1 and SORT2{32f } , SORT1 reference to MODE NEST TERTIARY1{5B } , identity relator{b}, SORT2 reference to MODE NEST TERTIARY2{5B } .
b) identity relator{a} : is{94f } token ; is not{94f } token. {Examples:
}
5.2.2.2. Semantics The yield W of an identity-relation I is determined as follows:
· let N1 and N2 be the {collateral} yields of the 'TERTIARY's of I;
· W is true
if {the name} N1 is the same as N2, and is false
otherwise;
· W is true
if N1 is not the same as N2, and is false,
otherwise.
The use of a local-generator implies (with most implementations) the reservation of storage on a run-time stack, whereas heap-generators imply the reservation of storage in another region, termed the "heap", in which garbage-collection techniques may be used for storage retrieval. Since this is less efficient, local-generators are preferable; this is why only LOC may be omitted from sample-generators of variable-declarations.}
5.2.3.1. Syntax {LEAP :: local ; heap primal.}
a) reference to MODE NEST LEAP generator{5C } : LEAP{94d ,-} token, actual MODE NEST declarer{46a} .
b) reference to MODINE NEST LEAP sample generator{44e } : LEAP{94d ,-} token, actual MODINE NEST declarer{44b,46a} ; where (LEAP) is (local), actual MODINE NEST declarer{44b ,46a} . {Examples:
}
5.2.3.2. Semantics a) The yield W of a LEAP-generator or LEAP-sample-generator G, in an environ E, is determined as follows:
· W is a newly created name which is made to refer {2.1.3.2.a } to the yield in E of the actual-declarer {4.4.2.d , 4.6.2.a} of G;
· W is equal in scope to the environ E1 determined as follows:
· E1 is the "local environ"
{b}accessible from E;
· E1 is {the first environ
created during the elaboration of the particular-program, which
is} such that
· E1 is the primal environ;
{The only examples of primal-generators occur in the standard- and system-preludes {10.3.1.1.h , 10.3.1.4.b, n, o , 10.4.1.a}.
When G is a reference-to-routine-sample-generator, the mode of W is of no relevance.}
b) The "local environ" accessible from an environ E is an environ E1 determined as follows:
5.2.4.1. Syntax a) strong reference to MODE NEST nihil{5B } : nil{94f } token. {Example:
}
5.2.4.2. Semantics
The yield of a nihil is a nil name.
Next