| ||
Tutorial: Transparency and Coercion |
A very important, implicit, and pervasive aspect of the gbeta language is that there is a very consistent transparency of entity category. When used in a given context, whatever category of entity is available will be transformed to the category requested by the context. Entity categories are object, pattern, object identity and pattern identity, including concurrent variants. An imperative is an object contextAn imperative is an object context, and that means that whatever is denoted by a name which occurs as an imperative in a program will be transformed into an object, implicitly and without special syntax which reveals what it was before the transformation. That information is available by looking up the declaration anyway. This is good since it makes the syntax at the point of application independent of the precise category of entity declared, and this means that the declaration may be changed without affecting all the usages of that declared name. The most basic example of this is that a name which denotes an object and a name which denotes an object reference (think "a pointer" if you like) are used in the same way,
i into an object reference, that
is a change which is local to the declaration; the rest of the program
works as before without changes.
Of course, this means that it is very un-BETA-like to give names like
Since this transparency is a very basic property of the BETA family of
languages, the traditional BETA terminology is that Method invocation is coercion!A very important example of the imperative as an object context is method invocation. If a name which denotes a pattern occurs as an imperative, the pattern is coerced into an object (this transformation from pattern to object is normally called "object instantiation"), and the resulting, anonymous object is executed. As an example:
p and x that
p is a pattern (which is implicitly instantiated to
create a "procedure activation record"), whereas x is an
object which is simply executed (hence keeping its local state intact
between "invocations").
As a consequence of this, a pattern may be thought of as a procedure or method, since applying them as an imperative "works like" an invocation as known in other imperative languages. An evaluation is also an object contextSince an evaluation is also an object context, the mechanism of the following examples are the same as explained above:
i is printed with the assignment evaluation
i+ir->putint , the transformation of i is a
no-op since it is already an object. However, ir is
coerced from object reference to object. You may think of it as
"dereferencing a pointer." On the right hand side of the assignment
evaluation, putint is coerced from a pattern into an
object, i.e. an instance is created, and this instance is then
executed.
The next imperative is a composite (multiple) assignment evaluation.
Everywhere, whether a name delivers a value (it occurs before
The next section deals with a number of non-object contexts. |