![]() |
Annex C:
|
![]() |
This annex incorporates all of the vdm-sl value and type definitions together with individual explanations 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.
values
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!
Visibility = set of Accesses ;
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, 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 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 ;
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 ]
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 ;
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 ;
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 ;
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 ] ;
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.
Assign_Name = token inv aname == aname = Assign ;
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 = Bind) 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) ;
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) ;
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 ;
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.
Guarded_Statement = Case_Statement | Typecase_Statement | Select_Statement | Protect_Statement | Lock_Statement | Conditional_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.
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.
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 ;
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] ;
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 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 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 ;
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.
Reference_Value = token ;
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.
Address = token ;
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.
Bit_Pattern = seq of Bit ;
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 the numeric class features add, minus, times, etc. |
Value_Domain = token inv vdom == (vdom = Numeric) or (vdom = Text) ;
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 ;
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: Wednesday, 25 April 2001. |
![]() |