Sather Home
        Page

Annex C:
Collected Abstract Syntax

This annex incorporates all of the vdm-sl value and type definitions together with an explanation of their function in the language model.

C.1 Values

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.

values
  1. The first group of tokens is used to model the uses (see the Accesses type) to which some entity may be put.
  2. The four tokens below are used to differentiate the various kinds of class which form part of the abstract syntax (see the Class_Kind type).
  3. The kinds of method (ie those which have different semantics) are modelled by the two following tokens.
  4. Sather defines two kinds of literal value which are represented by the two following tokens.
  5. The following single token has an implementation-defined name or translation-time defined name not defined by the Sather language but which an implementer is required to specify, either as a fixed name or as being determinable by the implementation when a program is actually implemented.
  6. The next single token is the model value of void - ie no value at all.
  7. The next pair of tokens give the model values of the Bit type.
  8. The following pair of tokens provide model values for the Boolean type.
  9. The following single token models the name of the assign feature. While this is merely a method in the conventional sense, it has a fixed semantic model of its operation - fixed by the Sather language to mean providing a value to some object - which that object retains until some other value may be assigned to it. It uses conventional store semantics.
  10. The following group of tokens identifies those which name routines or iterators built-in to the Sather language, not returning a value. See the Built_in_Name type for details.
  11. The following group of tokens identifies those which name routines built-in to the Sather language which return a value. See the Built_in_Exp_Name type for details.

C.2 Vdm-sl Object & Type related Types

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

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.

types

Accesses = token
inv acc ==
(acc = Read)
or (acc = Write)
or (acc = Use)
or (acc = Once) ;

Visibility

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!

Visibility = set of Accesses ;

Class_Kind

Class_Kind is another token type used to model the kind of semantics to be attached to a particular class definition.

Class_Kind = token
inv class ==
(kind = External)
or (kind = Abstract)
or (kind = Immutable)
or (kind = Reference) ;

Method_Kind

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.

Method_Kind = token
inv times ==
(times = One_Shot)
or (times = Multiple) ;

A Complete Program

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.

Program ::
program_class : Class_Def
dependent_classes : set of Class_Def

inv mk_Program(dist,_) ==
dist.kind in set {Immutable, Reference}
and program_class not in set dependent_classes
and let names : set of token = {forall feat in dist.features & feat.name} in
Distinguished_Method in set names ;

Class_Def

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.

Class_Def ::
kind : Class_Kind
features : set of Feature
typenode : [ Type_Graph ]

Type_Graph

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.

Type_Graph ::
subtypes : set of Type_Specifier
supertypes : set of Type_Specifier ;

Type_Specifier

A Type_Specifier type defines the structure of individual components of a type graph - as well as the properties of an individual object instantiation.

Type_Specifier ::
id : Type_Name
args : [ set of Type_Specifier]
type_def : Class_Def ;

Type_Name

All types in a program require a 'name' whether explicitly specified by the programmer or library writer or generated by the implementation.

Type_Name = token ;

Feature

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.

Feature ::
name : token
args : [ set of Feature ]
kind : [ Type_Specifier ]
value : [ Expression ]
impl : [ seq of Statement ]
vis : [ Visibility ]
ext_vis : Visibility
uses : [ Method_Kind ] ;

C.3 Pre-defined Identity Types

The Sather language defines a number of statements and expressions which have pre-defined semantics.

Assign_Name

Because of its special nature in being able to change state, this type has been included - even though it only has one possible value.

Assign_Name = token
inv aname ==
aname = Assign ;

Built-in_Name

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.

Built_in_Name = token
inv bname ==
(bname = Assert)
or (bname = At)
or (bname = Attach)
or (bname = Break_Iter)
or (bname = Pre_Condition)
or (bname = Post_Condition)
or (bname = Quit)
or (bname = Raise)
or (bname = Return)
or (bname = Synchronise)
or (bname = Unlock)
or (bname = Until_Iter)
or (bname = While_Iter)
or (bname = Yield) ;

Built-in_Exp_Name

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.

Built_in_Exp_Name = token
inv bien ==
(bien = Exception)
or (bien = Initial)
or (bien = Is_void)
or (bien = New)
or (bien = Result)
or (bien = Self) ;

Defined_Feature_Name

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.

Defined_Feature_Name = token
inv dfn ==
(dfn not in set {ex | ex : Built_In_Name})
and (dfn not in set {ex | ex : Built_In_Exp_Name})
and (dfn not in set {ex1 | ex1 : Built_in_Value})
and dfn <> Assign_Name ;

C.4 Statement Types

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.

Statement

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.

Statement =
Guarded_Statement
| Bounded_Statement
| Call_Statement ;

Guarded_Statement

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.

Guarded_Statement =
Case_Statement
| Typecase_Statement
| Select_Statement
| Protect_Statement
| Lock_Statement
| Conditional_Statement ;

Bounded_Statement

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.

Bounded_Statement =
Loop_Statement
| Parallel_Statement
| Fork_Statement
| Location_Statement ;

Call_Statement

The Call statement comprises all of the statement variants which carry out the actions of a program.

Call_Statement =
Assign_Call
| Predefined_Application
| Feature_Application ;

C.4.1 Guarded Statements

All of this group are variants of the case statement with, for some, additional protection clauses.

Case_Statement ::
when : [seq of Guard_Clause]
default : [seq of Statement] ;


Guard_Clause ::
val : Expression
body : [seq of Statement] ;


Typecase_Statement =
Case_Statement ;

Protect_Statement ::
body : [seq of Statement]
prot : Case_Statement ;


Select_Statement =
Case_Statement ;

Lock_Statement =
Case_Statement ;

Conditional_Statement =
Case_Statement ;

C.4.2 Bounded Statements

Apart from the location statement all of these forms of statement are just a sequence of statements.

Loop_Statement ::
impl : [seq of Statement] ;

Parallel_Statement ::
impl : [seq of Statement] ;

Fork_Statement ::
impl : [seq of Statement] ;

Location_Statement ::
objs : set of Feature
impl : [seq of Statement] ;

C.5 Method Calls

The call statement comprises all of the statement variants which carry out the actions of a program.

Call_Statement =
Assign_Call
| Application_Statement

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.

Application_Statement =
| Predefined_Call
| Feature_Application ;

The expression evaluation calls are analogous to the Application_Statement above, thus -

Eval_Expression =
Predefined_Call
| Feature_Application ;

Predefined Calls

The similarity between predefined call statements and predefined call expressions extends to them having the same abstract syntax - with different invariants, thus for the statement variant -

Predefined_Call ::
id : token
args : Feature
impl : Feature
rval : [Value_Expression] ;

inv mk_Predefined_Call(expid,_,_,val) ==
expid in set dom Built_In_Name
and val = nil

and for the expression variant -

Predefined_Call ::
id : token
args : Feature
impl : Feature
rval : [ Value_Expression] ;

inv mk_Predefined_Call(expid,_,_,val) ==
expid in set dom Built_In_Exp_Name
and val <> nil

Feature_Application

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).

Feature_Application ::
id : Defined_Feature_Name
body : Feature ;

C.6 Expression Types

This last section of the abstract syntax contains types which define the various result yielding operations of the language.

Expression

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).

Expression =
Store_Expression
| Value_Expression ;

Store_Expression

An expression which returns a handle to some storage location may provide this in one of three ways :-

  1. A reference to some entity in the environment in which the program is executing. This is provided by that environment and is merely a token as far as the executing program is concerned.
  2. Some local memory or port address to which the program may (or may not, of course!) have some form of access. This address forms part of the computer in which the program is executing.
  3. Some non-local memory or port address to which the program has some access by virtue of being a distributed program.
Store_Expression =
Reference_Value
| Eval_Near
| Eval_Far ;

Reference_Value

This type models an uninterpretable token provided to a program from its external environment.

Reference_Value = token ;

Eval_Near

This type models a location which is on the computer system which created the location.

Eval_Near = Address ;

Eval_Far

This type models a location which is not on the computer system which created the location.

Eval_Far = Address ;

Address

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.

Address = token ;

Value_Expression

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.

Value_Expression =
Bit_Pattern
| Literal_Value
| Built_in_Value
| Eval_Expression ;

Bit_Pattern

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.

Bit_Pattern = seq of Bit ;

Value_Domain

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.
Value_Domain = token
inv vdom ==
(vdom = Numeric)
or (vdom = Text) ;

Literal_Value

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.

Literal_Value ::
code : Bit_Pattern
kind : Value_Domain ;

Language defined literal values

Sather defines a small number of literal values which are modelled by the following small group of types.

Built_in_Value =
Bit
| Boolean
| Void ;


Bit = token
inv bitval ==
(bitval = Set_Bit)
or (bitval = Clear_Bit) ;


Boolean = token
inv bval ==
(bval = True)
or (bval = False) ;

Specification Index Language Index
Comments or enquiries should be made to Keith Hopper.
Page last modified: Tuesday, 24 October 2000.
Produced with Amaya