Previous

2. The computer and the program

The meaning of a program in the strict language is explained in terms of a hypothetical computer which performs the set of actions {2.1.4 } which constitute the elaboration {2.1.4.1 } of that program. The computer deals with a set of "objects" {2.1.1 }.

2.1. Terminology

{``When I use a word,'' Humpty Dumpty said, in rather a scornful tone, ``it means just what I choose it to mean - neither more nor less.'' Through the Looking-glass, Lewis Carroll.}

2.1.1. Objects

An "object" is a construct {1.1.3.2.e }, a "value" {2.1.1.1.a }, a "locale" {2.1.1.1.b}, an "environ" {2.1.1.1.c } or a "scene" {2.1.1.1.d}.

{Constructs may be classified as "external objects", since they correspond to the text of the program, which, in a more realistic computer, would be compiled into some internal form in which it could operate upon the "internal objects", namely the values, the locales, the environs and the scenes. However, the hypothetical computer has no need of a compilation phase, it being presumed able to examine the program and all of its descendent constructs at the same time as it is manipulating the internal objects.}

2.1.1.1. Values, locales, environs and scenes

a) A "value" is a "plain value" {2.1.3.1 }, a "name" {2.1.3.2 }, a "stowed value" (i.e., a "structured value" {2.1.3.3 } or a "multiple value" {2.1.3.4} ) or a "routine" {2.1.3.5 }.

{For example, a real number is a plain value. A special font is used for values appearing in the text of this Report, thus: 3.14, true. This is not to be confused with the italic and bold fonts used for constructs. This same special font is also used for letters designating such things as constructs and protonotions.}

b) A "locale" {is an internal object which} corresponds to some 'DECSETY LABSETY' {1.2.3.C,I }. A "vacant locale" is one for which that 'DECSETY LABSETY' is 'EMPTY'.

{Each 'QUALITY TAX' {4.8.1.F, G } enveloped by that 'DECSETY LABSETY' corresponds to a QUALITY-defining-indicator-with-TAX {i.e., to an identifier, operator or mode-indication} declared in the construct whose elaboration caused that locale to be created. Such a 'QUALITY TAX' may be made to "access" a value or a scene "inside" that locale {2.1.2.c }

A locale may be thought of as a number of storage cells, into which such accessed objects are placed.}

{The terminal metaproductions of the metanotions "DEC", "LAB" and "FIELD" (or of the more frequently used "PROP", which includes them all) are all of the form 'QUALITY TAX'. These "properties" are used in the syntax and semantics concerned with nests and locales in order to associate, in a particular situation, some quality with that 'TAX'.}

c) An "environ" is either empty, or is composed of an environ and a locale.

{Hence, each environ is derived from a series of other environs, stemming ultimately from the empty "primal environ" in which the program is elaborated {2.2.2.a }.}

d) A "scene" S is an object which is composed of a construct C {1.1.3.2.e } and an environ E. C is said to be the construct, and E the environ, "of" S.

{Scenes may be accessed inside locales {2.1.2.c } by 'LAB's or 'DEC's arising from label-identifiers or from mode-indications, and they may also be values {2.1.3.5 }.}

2.1.1.2. Modes

{Each value has an attribute, termed its "mode", which defines how that value relates to other values and which actions may be applied to it. This attribute is described, or "spelled", by means of some 'MOID' {1.2.1.R } (thus there is a mode spelled 'real', and there is a mode spelled 'structured with real field letter r letter e real field letter i letter m mode'). Since it is intended that the modes specified by the mode-indications A and B in

MODE A = STRUCT(REF A b), MODE B = STRUCT(REF STRUCT(REF B b) b)should in fact be the same mode, it is necessary that both the 'MOID'

'mui definition of structured with reference to mui application field letter b mode'and the 'MOID'

'muii definition of structured with reference to structured with reference to muii application field letter b mode field letter b mode'(and indeed many others) should be alternative spellings of that same mode. Similarly, the mode specified by the declarer UNION(INT, REAL) may be spelled as either 'union of integral real mode' or 'union of real integral mode'. All those 'MOID's which are spellings of one same mode are said to be "equivalent to" one another {a}.

Certain 'MOID's, such as 'reference to muiii application', 'reference to muiiii definition of reference to muiiii application', 'union of real reference to real mode', and 'structured with integral field letter a real field letter a mode', are ill formed {7.4 , 4.7.1.f , 4.8.1.c} and do not spell any mode.

Although for most practical purposes a "mode" can be regarded as simply a 'MOID', its rigorous definition therefore involves the whole class of 'MOID's, equivalent to each other, any of which could describe it.}

a) 'MOID1' {1.2.1.R } is "equivalent to" 'MOID2' if the predicate 'where MOID1 equivalent MOID2' {7.3.1.a } holds {1.3.2 }.

{A well formed 'MOID' is always equivalent to itself: 'union of integral real mode' is equivalent to 'union of real integral mode'.}

A protonotion P is "equivalent to" a protonotion Q if it is possible to transform a copy Pc of P into at copy Qc of Q in the following step:

Step :
If Pc is not identical to Qc, then some 'MOID1' contained in Pc, but not within any {larger} 'MOID2' contained in Pc, is replaced by some equivalent 'MOID', and the Step is taken again.
{Thus 'union of integral real mode identifier' is equivalent to 'union of real integral mode identifier'.}

b) A "mode" is a class C of 'MOID's such that each member of C is equivalent {a}to each other member of C and also to itself {in order to ensure well formedness}, but not to any 'MOID1' which is not a member of C.

{However, it is possible (except when equivalence of modes is specifically under discussion) to discuss a mode as if it were simply a terminal metaproduction of "MOID", by virtue of the abbreviation to be given in 2.1.5.f .}

c) Each value is of one specific mode.

{For example, the mode of the value 3.14 is 'real'. However, there are no values whose mode begins with 'union of', 'transient reference to' or 'flexible ROWS of' (see 2.1.3.6 ).}

2.1.1.3. Scopes

{A value V may "refer to" {2.1.2.e }, or be composed from {2.1.1.1.d } another internal object O (e.g., a name may refer to a value; a routine, which is a scene, is composed, in part, from an environ). Now the lifetime of the storage cells containing {2.1.3.2.a } or implied by {2.1.1.1.b} O may be limited (in order that they may be recovered after a certain time), and therefore it must not be possible to preserve V beyond that lifetime, for otherwise an attempt to reach some no-longer-existent storage cell via V might still be made. This restriction is expressed by saying that, if V is to be "assigned" {5.2.1.2.b } to some name W, then the "scope" of W must not be "older" than the scope of V. Thus, the scope of V is a measure of the age of those storage cells, and hence of their lifetime.}

a) Each value has one specific "scope" {which depends upon its mode or upon the manner of its creation; the scope of a value is defined to be the same as that of some environ}.

b) Each environ has one specific "scope". {The scope of each environ is "newer" {2.1.2.f } than that of the environ from which it is composed {2.1.1.1.c }.}

{The scope of an environ is not to be confused with the scopes of the values accessed inside its locale. Rather, the scope of an environ is used when defining the scope of scenes for which it is necessary {7.2.2.c } or of the yields of generators for which it is "local" {5.2.3.2.b }. The scope of an environ is defined relative {2.1.2.f } to the scope of some other environ, so that hierarchies of scopes are created depending ultimately upon the scope of the primal environ {2.2.2.a }.}
 
Next