![]() |
Annex C:
|
This annex incorporates all of the vdm-sl value and type definitions together with an explanation of their function in the language model.
The value of tokens in a vdm-sl model expresses some concept which the functions and operations of an explicit version of the model - encapsulating the run-time semantics ('m-' meaning functions) - must define. The descriptive notes attached to each token value and group form a natural language description of the meta-semantics involved.
The types in the vdm-sl model of the Sather language enable the abstract structure of an arbitrary well-formed program to be represented as the abstract syntax. This is a graph/tree structure with no circularities.
Accesses is a token type, restricted by the invariant to have one of four possible access values only. It models a kind of use to which a component having this value may be put.
This type models the set of uses which may be made of an individual feature or argument. If a type feature is marked as private then a set will be empty!
Class_Kind is another token type used to model the kind of semantics to be attached to a particular class definition.
Method_Kind, another token type, models the kind of semantics to be attached to a class method - whether it is a routine or an iterator.
A complete program consists of the definition of the distinguished class which contains the method to be invoked by the external environment when executing the program, together with all of those classes on which it (recursively) depends.
This type is at the 'head' of a section of the abstract syntax. One of these is necessary for each class in a program being translated. The class kind component indicates which of the possible kinds of class is defined. In turn this may lead to different invariants and well-formedness functions as described in the body of this specification.
A Type graph is the structure which is used to determine type correctness for a complete compiled program. Either of the sets may, of course, be empty. It is expected that the checking of the type graph should only be done once, filling in as needed from the collection of individual class definitions.
A Type_Specifier type defines the structure of individual components of a type graph - as well as the properties of an individual object instantiation.
All types in a program require a 'name' whether explicitly specified by the programmer or library writer or generated by the implementation.
This is the principle type to be found in this abstract syntax model since each component of a class is a feature of one kind or another. It encapsulates all of the descriptors necessary to define each component and argument of the abstract type definition which is the class concept.
The Sather language defines a number of statements and expressions which have pre-defined semantics.
Because of its special nature in being able to change state, this type has been included - even though it only has one possible value.
Those routines which correspond to Sather statement kinds or iters which are implementation routines which do not generate code to return some object to the environment from which the method invoked the statement routines are modelled in this class. Note that this is done by merely identifying them as token names. The related semantics of the routine are defined in the body of this specification.
Those routines which correspond to Sather statement kinds or iters which are implementation routines which generate code to return some object to the environment from which the method invoked the statement routines, are modelled in this class. Note that this is done by merely identifying them as token names. The related semantics of the routine are defined in the body of this specification.
This type defines the names of all of those routines which have been written by the programmer, a list which must be disjoint from those corresponding to values, statement or expression routines.
The statements which form the implementation of a feature or feature application are modelled in the structures shown below which is deliberately intended to 'merge' concurrency features into the main syntax tree structures.
The Statement type has three principal variant types provided by the language. Note in particular that all actions are carried out by a call statement of some kind.
The Guarded statement comprises all variants of statement for which execution of some actions is conditional upon the result of evaluating some logical expression. Note that the 'lock' statement alternatives specified in Sather 1.1 have intentionally been separated into a Select statement and a Lock statement although their meaning has not changed.
Bounded statement variants all have the common property that a possible sequence of statements is delimited by markers which dictate how and where the statements are to be executed.
The Call statement comprises all of the statement variants which carry out the actions of a program.
All of this group are variants of the case statement with, for some, additional protection clauses.
Apart from the location statement all of these forms of statement are just a sequence of statements.
The call statement comprises all of the statement variants which carry out the actions of a program.
in which the assignment call is treated specially. There are two variants of application statement - one pre-defined by the language and the other user written.
The expression evaluation calls are analogous to the Application_Statement above, thus -
The similarity between prredefined call statements and predefined call expressions extends to them having the same abstract syntax - with different invariants, thus for the statement variant -
and for the expression variant -
Feature application is again common to both expression and statement, the only restriction occurring in the well-formedness function in relation to returned value (or not).
This last section of the abstract syntax contains types which define the various result yielding operations of the language.
An expression may either yield a value (which may be further used in obtaining another value) or a location (ie a reference to a storage location).
An expression which returns a handle to some storage location may provide this in one of three ways :-
This type models an uninterpretable token provided to a program from its external environment.
This type models a location which is on the computer system which created the location.
This type models a location which is not on the computer system which created the location.
An Address models a computer location which may be derived by an implementation as the result of using programming expressions. It refers to a location which is defined by the Sather language. The actual location (or indeed address token) indicated during any program execution is implementation dependent.
A value expression yields a value of some program type the semantics of which are defined by the defining class. The way in which such values may be manipulated is not defined by the Sather language.
The bit pattern is the fundamental way of expressing values of any kind. Any semantics attributed to it are defined by the appropriate class definition. The length of the sequence for any given class is implementation defined.
The Sather language definition requires that numeric and textual values may be expressed when writing programs. The form in which such values appear is necessarily implementation defined.
NOTE | It is important to note that the language specifies no operations on such values unless they are converted into a required library (or other) numeric or text class which defines those pre-defined operations such as add, minus, times, etc. |
Sather defines two general forms of user-specifiable literal values - numbers and text (including individual characters). This type models both the token value and the kind of literal it represents.
Sather defines a small number of literal values which are modelled by the following small group of types.
![]() |
Specification Index | ![]() |
Language Index |
Comments
or enquiries should be made to Keith Hopper. Page last modified: Wednesday, 17 May 2000. |
![]() |