Previous

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:

}

a)
x := 3.14
b)
x
c)
3.14

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;

Case A: 'MODE' is some 'structured with FIELDS mode': For each 'TAG' selecting a field in W,


· that field is assigned to the subname selected by 'TAG' in N;

Case B: 'MODE' is some 'ROWS of MODE1':


· 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;

Case C: 'MODE' is some 'flexible ROWS of MODE1':


· let V be the {old} value referred to by N;

· N is made to refer to a multiple value composed of

( 1) the descriptor of W,
( 2) variants {4.4.2.c } of some element {possibly a ghost element} of V;


· 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:

}

a)
next OF draft:=: REF BOOK(NIL)
b)
:=: ·:/=:
{Observe that a1 [i] :=: a1 [j] is not produced by this syntax. The comparison, by an identity-relation, of transient names {2.1.3.6.c } is thus prevented.}

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;

Case A: The token of the identity-relator of I is an is-token:


· W is true if {the name} N1 is the same as N2, and is false otherwise;

Case B: The token of the identity-relator of I is an is-not-token:


· W is true if N1 is not the same as N2, and is false, otherwise.

5.2.3. Generators

{And as imagination bodies forth The forms of things unknown, the poet's pen Turns them to shapes, and gives to airy nothing A local habitation and a name. A Midsummer-night's Dream, William Shakespeare.}
{The elaboration of a generator, e.g., LOC REAL in xx := LOC REAL := 3.14, or of a sample-generator, e.g., [1 : n] CHAR in [1: n] CHAR u, v;, involves the creation of a name, i.e., the reservation of storage.

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:

}

a)
LOC REAL
b)
LOC REAL ·REAL
{There is no representation for the primal-symbol (see 9.4.a ).}

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:

Case A: 'LEAP' is 'local':


· E1 is the "local environ" {b}accessible from E;

Case B: 'LEAP' is 'heap':


· E1 is {the first environ created during the elaboration of the particular-program, which is} such that

( 1) the primal environ {2.2.2.a } is the environ of the environ of the environ of E1 {sic}, and
( 2) E1 is, or is older than, E;

Case C: 'LEAP' is 'primal':


· E1 is the primal environ;

· if W is a stowed name {2.1.3.2.b }, then W is endowed with subnames {2.1.3.3.e , 2.1.3.4.g }.

{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:

If E is "nonlocal" {3.2.2.b },
then E1 is the local environ accessible from the environ of E;
otherwise, E1 is E.
{An environ is nonlocal if it has been established according to a serial-clause or enquiry-clause which contains no constituent mode-, identifier-, or operation-declaration, or according to a for-part {3.5.1.b } or a specification {3.4.1.j, k }.}

5.2.4. Nihils

5.2.4.1. Syntax

a) strong reference to MODE NEST nihil{5B } : nil{94f } token. {Example:

}

a)
NIL

5.2.4.2. Semantics

The yield of a nihil is a nil name.
 
Next