This section describes the syntax and informal semantics of the general block structure in gbeta. Syntactically, the general block structure amounts to the support for declaration ofMainParts withinMainParts in various ways, as it can be seen in the full grammar in App. A. Already the simplied grammar in Fig. 2.1 on page 23 shows the most important case, namely the possibility to write aMainPartnested inside aMainPartas a part of an attribute declaration, anAttributeDecl.
The semantic support for general block structure is also quite straightforward to describe, because all the descriptions of semantic (or run-time) entities given sofar have been designed to t into the greater, contextualized framework.
Patterns are by denition context dependent since each mixin, as described in Sect. 3.3, includes the identity of the enclosing part-object. Similarly, each part of an object receives a part-object as its context from the mixin of which it is an instance.
This contextuality support in each part object is used in the general case of name lookup. In Sect. 3.10 the rule for local lookup was given. The global lookup rule builds on the local lookup rule, as specied in Fig. 5.1. Basically, it says that the local lookup rule is applied to each object in the context, starting with the immediate context and one by one searching more and more global ones until the requested name has been found, or the entire context has been exhausted and an `undened name' error must be reported.
Note that the search of the next enclosing object in each step always uses that view whose most specic mixin is associated with the next syntactically enclosing MainPart. In other words, lookup starts from the MainParts which are there to look at, directly surrounding the name which is being looked up.
This means that the programmer can mentally annotate each MainPart with the environment that it provides, and then any name lookup will simply be
5.3. GENERAL BLOCK STRUCTURE INGBETA 113
1 1(#
2 company:
3
2(# employee: 3(# ::: #);
4 project:
5
4(# client: ^customer;
6 manager: ^employee
7 #);
8 realProject: project
9
5(# meeting:
10
6(# from,to: @dateTime;
11 ::: from :::
12 ::: manager :::
13 ::: employee :::
14 #)
15 #)
16 #);
17 customer: 7(# ::: #);
18 dateTime: 8(# ::: #)
19 #)
Figure 5.2: Global lookup example
a succession of searches in those environments. As a result of the ubiquity of the outermost environments (they are the context of very large portions of the program) and the syntactic and semantic immediacy of the innermost environments, name searches performed mentally by a programmer will often be rather easy, either because the name is nearby or because it is generally well-known.
The organization of objects corresponds to the physical nesting model ganization, and the search order corresponds to the relevance and urgency or-dering of the models by searching the most relevant objects rst. Note that it is perfectly possible to construct program entity nesting structures that do not correspond to a physical nesting of phenomena, but that may just be an example of using our metaphorical capabilities to understand non-spatial issues in terms of a spatial-like organization, such as for example considering a novel in context of the life of the author. Hence, there is no policy that prescribes that the physical nesting model organization should only be used to model actual physical nesting. The overall goal is to make programs understandable, and the use of metaphors to go beyond actual physical nesting is an important human capability that should of course be leveraged.
A few examples of global lookup are given in Fig. 5.2. The block structure of executions of a program using the patterns in Fig. 5.2 is illustrated in Fig. 5.3 on page 114. The gure only shows the nesting and inheritance relations between theMainParts, not the actual conguration of part objects and mixins at
run-block structure 1
2
7 8
3 4
5 6
inheritance Figure 5.3: The block structure in Fig. 5.2
time. That is because there are so many possible congurations, so we have to give a slightly abstract representation of it.
The relation to potential run-time entities is as follows: Each box in Fig. 5.3 represents the MainPart with the same number in Fig. 5.2, so any company pattern will consist of one mixin, and that mixin will be associated with the MainPart(and the box) numbered 2; an instance of such acompanypattern will consist of one part object which is an instance of the mixin. Similarly for other patterns and objects associated with the source code in Fig. 5.3.
Whenever the code inside a MainPart M is being executed it happens in context of a current part object, and the current object is always an instance of
a pattern which includes mixins associated withM and all theMainParts of the statically known superpattern; the current object may also contain additional mixins which are not known statically. For any given part object there will be part objects for all boxes which are reachable by either block structure links or inheritance links (going left along an arrow or up along a double-line in Fig. 5.3).
For example, given a meeting object (associated with box 6), there will be a uniquely determined object, associated with [5;4] (an instance of arealProject
pattern), which is the enclosing object for themeetingobject. Similarly, there will be an enclosingcompany, [2], around therealProject, etc.
Now, when looking up the names which are mentioned inside MainPart 6, we get the results as follows: dateTimeis looked up by searching 6, 5, 4, 2, 1, in that order; fromis looked up locally, just 6 has to be searched; 6, 5, and 4 are searched to ndmanager; and nally, 6, 5, 4, and 2 are searched in order to look upemployee.
5.4. THE RELATION TO MODULES 115