Methods and Behavior

Like the previous section, this section is also about patterns and objects; but the focus is on the behavioral aspects, so the patterns will be similar to meth-ods, and the instances of the patterns will often be implicit, unnoticed, not unlike activation records for method invocations in traditional object-oriented languages. This presentation serves to introduce the reader who does not know

Betato the somewhat unusual syntax used for expressions such as assignment and parameter transfers. Since gbeta and ^Beta are identical at this level of detail, the reader who knows^Betamight wish to skip to the next section.

A simplied grammar forMainPartwith focus on the method-like aspects of patterns is given in Fig. 2.3 on page 26. The simplication mainly aects Eval-uation, which just includes names, lists, and addition here. Of course, the full grammar in App. A will be needed in order to write useful programs, but the rather drastic simplication is appropriate here since the semantics of subtrac-tion, multiplication and other expressions and control structures is generally

MainPart^{::= `(#'</sup> AttributeDecl EnterPart<sup>?</sup> DoPart<sup>?</sup> ExitPart<sup>? `#)'} EnterPart::= `enter' Evaluation

DoPart^{::= `do'} Imp

ExitPart^{::= `exit'} Evaluation

Evaluation^::| Name ^| Evaluation ^`+' Evaluation

| `(' Evaluation <sup><`,'</sup> Evaluation^{> `)'} Imp^::| Name ^| Assignment

Assignment^::= Evaluation ^`->' Name

Figure 2.3: Simplied (method) syntax of MainPart

unsurprising; moreover, later sections, e.g., Sect. 9.1, will cover some control structures and other aspects neglected here.

The derivation of lists fromEvaluations uses some new notation, namely angle

brackets (`<sup><</sup>' and `^>'). They are only used for grouping, such that the repetition operator (`') is applied to the comma and the Evaluation together. Hence, that alternative allows an Evaluationto be a parenthesized, comma separated, non-empty list of Evaluations, for example^(x,(y,z)).

The rest of this section introduces the various parts of pattern specications associated with behavior, as well as the interconnections between those parts which may be constructed usingAssignments.

The simplest part is the ^DoPart, marked by the keyword^doand containing

a sequence of imperatives. Imperatives are often called `statements' in other

languages, but the word imperative is standard^Betaterminology, and moreover it species unambiguously that we are talking about commands given to the computer, not, e.g., about questions or assertions.

The informal semantics of executing an imperative which is aNameis to look

up the attribute denoted by that Name, obtain an object from it, and execute that object. How an object is obtained from dierent kinds of attributes is explained in Sect. 2.3, in particular in 2.3.4. The rules for name lookup are described in two phases, in Chap. 3 for the so-called local case and in Chap. 5 for the general case.

The informal semantics of executing anAssignmentis to look up the attribute denoted by theNamesubterm, obtain an object from it, evaluate theEvaluation subterm, insert the obtained value into the object, and nally execute the object.

In order to give a description which aligns better with main-stream terminology we might phrase it like this: To execute anAssignmentis to look up the method denoted by the Name subterm, create an activation record for it, evaluate the arguments, transfer them into the parameters in the activation record, and nally execute the method with that activation record. Or, alternatively: To execute anAssignmentis to look up the object specied by the Namesubterm, evaluate the Evaluation subterm, assign the result to the object, and nally

2.2. LANGUAGE CONSTRUCTS FOR THE BASIC CONCEPTS 27 execute the default method of the object, to let it integrate the received values correctly. Those translations reveal that theAssignmentimperative covers both expression evaluation and function call for the left hand side, as well as method invocation and value assignment for the right hand side.

Note that the general support for (possibly nested) lists allows combining expressions into lists and thereby returning more than one value from a func-tion; or accepting a list of values and thereby supporting argument lists for procedures or methods without introducing a separate concept or syntax for argument lists; or specifying logical, user-dened notions of value assignment (similar to user dened assignment methods in C++) by using EnterParts with objects.

To execute an object means to execute its DoPart, which again means to execute the imperatives of the DoPartsequentially.⁸

The insertion of a value into an object has an inductive denition. The basic cases are associated with the basic patterns, and with variable attributes. Value insertion and evaluation involving variable attributes is described in Sect. 2.3.4, but the semantics is similar to the semantics of basic objects in Assignments.

With basic objects, e.g., inserting an integer value v into an ^integer object oi means changing the state of oi such that, until its next state change, an evaluation ofoiwill deliverv; similarly for other basic values and objects. Cor-respondingly, the evaluation of object state is dened inductively with basic objects providing the basic cases, as implied in the description of value inser-tion. For example, a^booleanobjectobwill deliver either the valuetrueorfalse, depending on the value last inserted into ob. The composite (non-basic) cases of value insertion and evaluation are described below, after the description of theEnterParts andExitParts.

The inital values of basic objects arefalse(for^boolean),^'\0'(the nul char, for^char), 0 (for^integer), 0.0 (for^real), and(the empty string, for^string).

When executing an objecto, instance of a pattern whose syntax contains an EnterPart Nand/or anExitPart X, bothNandXare ignored; whenois evaluated, Xspecies how to obtain the value ofoand what structure that value has; and when a value is being inserted intoo,Nspecies what kind of value is accepted, and how to insert it.

As promised above, the composite case in the inductive denition of the informal semantics of object state evaluation and value insertion will now be explained. Given an objectowhose patternpis associated with syntax contain-ing theEnterPart NandExitPart X. Then value insertion proceeds as follows:

If theEvaluationin Nis aNamethen inserting a value intoois the same as inserting it into the entity denoted by thatName, with lookup starting fromo.

If theEvaluationinNis a listLof evaluations, then the value accepted for insertion must have the structure obtained recursively from the structure of values accepted by the elements ofL; the eect of inserting such a value

8The complete explanation depends on inheritance and^INNER; see Chap. 3

is the same as the combined eect of inserting the elements of the value into the elements of L.

If the Evaluationin Nis on the form Evaluation⁺Evaluationthen the pro-gram is rejected with a static semantic error (similarly for other sions which do not specify a pattern or object, including all binary expres-sions).

The explanations about evaluation are parallel:

If theEvaluationinXis aNamethen evaluating the value ofois the same as evaluating the value of the entity denoted by that Name, with lookup starting fromo.

If theEvaluationinXis a listLof evaluations, then the value delivered by o is obtained recursively by evaluating each element of L.

If the Evaluation in X is on the form Evaluation⁺Evaluationthen each of the operands must deliver a single integer value when evaluated; they are evaluated, left to right, and the (integer) sum of the obtained values is delivered; otherwise, each of the operands must deliver a single string value when evaluated; they are evaluated, left to right, and the (string) concatenation of the obtained values is delivered.

The integer addition which provides the abovementioned sum happens in a monoid (integer;+) whose properties are not specied exactly here. It may, e.g., raise overow errors, be non-commutative, and/or compute the sum modulo 2³¹. It is apparently nice for a language to conform to a mathematically beautiful denition of, e.g., integer addition, but not all users of a language may want to pay for it in terms of lower performance, higher space usage, or similar.

Specialized versions of a language might be very beautiful in this respect.

Of course, the full languagegbetahas more expressions than just addition.

There is also the topic of value coercions, e.g., `1+2.5' will coerce 1 into 1.0 and then perform an addition of realvalues. Since thegbetaapproach to these issues is non-innovative we skip over the details.

One topic has been silently skipped over in the entire description above, namely the eects of a variable object attribute providing an object which is an instance of another pattern than the qualication. Of course, this only occurs when the variable object is not exact (see Sect. 2.2.5 about attributes in general and exact ones in particular), and then only with patterns which are specializations of the qualication. The general rule is that the statically known pattern unconditionally determines what part of an object is taken into consideration for evaluation and value insertion, whereas all parts of an object contribute withDoParts to the behavior of the object. More details can be found in Sect. 3.

Notice that the full generality of theMainPartis needed for patterns used as methods, since the DoPartis the body, the EnterPart species incoming argu-ments, theExitPartspecies the returned results, and the attributes are used for

2.3. TRANSPARENCY AND COERCION 29