RSL - the RAISE specification language. Language design

Citation preview

RSL – the RAISE specification language: Language Design Version 0.1 Anne Haxthausen The Common Framework Initiative January 15, 1996 This document is part of the CFI Catalogue of Algebraic Specification Frameworks1 . It was provided by Anne Haxthausen; any comments and corrections should be addressed to [email protected]. It will be made available formatted for printing as compressed Postscript2 (˜350Kb) and DVI3 (˜50Kb). The WWW version provides only a rough approximation (mostly generated automatically by Hyperlatex) to the symbols used in the formatted versions. Please inform [email protected] about any places where an alternative approximation is desirable! N.B. All sections of the catalogue are TENTATIVE first versions, unless explicitly marked otherwise. Sections dealing with Methodology, Tools, and Documentation will be added later.

1 Specification in the Small 1.1 Basic Constructs 1.1.1 signatures Characterize: The signatures of RSL extends the usual many-sorted signatures by also allowing the use of built-in type constructors and the definitions of (imperative) variables and channels. Notation for declaring sorts/types: Basic forms: 1. type id 2. type id = type expr There are also a number of derived forms for defining union, record and variant (including enumeration) types: 1. type id = id1 | ... | idn 2. type id :: f1 : type expr1 ... fn : type exprn 3. type id == variant1 | ... | variantn 1 http://www.brics.dk/Projects/CFI/Catalogue 2 ftp://ftp.brics.dk/pub/BRICS/Projects/CFI/Catalogue/RSL.ps.Z 3 ftp://ftp.brics.dk/pub/BRICS/Projects/CFI/Catalogue/RSL.dvi

1

RSL

2

Notation for declaring operations/functions, predicates/relations: Basic form: value id or op : type expr Derived forms: 1. value id or op : type expr = value expr 2. value id or op : type expr · logical-value expr 3. value id : type expr id(x1, ..., xn) ≡ value expr pre logical-value expr 4. value id : type expr id(x1, ..., xn) as y post logical-value expr1 pre logicalvalue expr2 Notation for declaring variables: No common declarations for variables used in axioms. Each axiom should explicitly quantify over variables that it uses. Any restrictions on order of declarations: No. Notation for indicating local/private/hidden items: The local construct may be used in value expressions to declare any kind of entity with a restricted scope. Hiding can be indicated at the module level, cf. 2.2.4. 1.1.2 axioms Characterize: The axioms are value expressions of type Bool. They are similar to formulas of 1. order logic, but there is no distinction between terms and formulas (and between functions and predicates), and functions are considered as 1. order values. Notation: axiom logical-value expr 1.1.3 models Characterize the structure of a model: A model consists of (1) a map from names to their denotations (types, values, (variable) locations, channels, schemes and objects), and (2) a store. Do specifications have loose semantics? Yes 1.1.4 constraints Characterize (initiality, (free) generating, etc.): No constraints. However, generatedness and disjointness can be specified by inductions axioms and inequalities, respectively. These can either be stated explicitly or be implicit in variant type definitions. For example, the variant type definition type List == empty | cons(head : Elem, tail : List) declares a List type generated by the (syntactically indicated) constructors empty and cons through an implicit induction axiom. The use of variant type definitions (rather than their equivalent sort definitions, value definitions and axioms) enables special tactics to be used in theorem provers or rewrite tools. Notation: 1.1.5 status Can one indicate the status of items and axioms, e.g., differentiate between constructors/selectors, axioms/theorems, equations/rewrite-rules?

RSL

3

In value definitions there is no special notation for differentiating between constructors and selectors, but in variant type definitions constructors and selectors are syntactically indicated. For example, in type List == empty | cons(head : Elem, tail : List) empty and cons are the constructors by which the List type is generated, and head and tail are selectors. Theorems (including refinement relations) are not stated in modules but in special entities, and the syntax is a small extension of the syntax for axioms. Differentiation between equations/rewrite-rules is mostly a tooling issue. In justifications (proofs) axioms and theorems generate rewrite rules. Notation: 1.1.6 other Any feature not covered above: Assignment to (imperative) variables, sequencing, iteration and concurrency are also included. Notation for declaring (imperative) variables in signatures: variable id : type expr Notation for declaring channels in signatures: channel id : type expr

1.2 Types Is type-checking decidable? Yes. 1.2.1 predefined types Notation for predefined types (e.g., Booleans): Bool, Int, Nat, Real, Char, Text, Unit 1.2.2 algebra of types Notation for predefined type constructors (e.g., enumerations, records): ∼ ∼ ×, -set, -infset, ∗ , ω , → m →, → m → See also 1.1.1 for notation for unions, records and variants (including enumerations). 1.2.3 parametrized type constructors Notation for declaring parametrized type constructors: None. 1.2.4 polymorphic types How is polymorphism expressed: free variables, quantification, subtypes? Notation: Can the effect of type classes be achieved? Notation: 1.2.5 dependent types Can types depend on values (e.g., lists of definite length)? Types can not be parameterized by values, but they can depend on fixed values as for example integer lists of length 5: {| l : Int∗ · len l = 5 |} Notation: If not, can the same effect be achieved by other means?

RSL

4

1.2.6 other Any feature not covered above:

1.3 Partiality Can partiality be represented? Yes. 1.3.1 subtypes defined by predicates Are such ‘semantic’ subtypes allowed? Yes. Notation: {| id : type expr · p(id) |} Is ‘subtype checking’ decidable? No. 1.3.2 subtypes declared in the signature Notation: Is the interpretation of functions ‘universal’ or ‘overloaded’ ? Are ‘retracts’ available? No. 1.3.3 equations Notation: Two forms: (1) e1 = e2 (2) e1 ≡ e2 Interpretation (existential, strong, weak): The first form is weak equality, the second is strong. 1.3.4 (un)definedness Notation for asserting definedness: No special notation (like definedness-predicates). Definedness is expressed by other means, e.g. by the use of total function types, or by axioms of the form e post true, which asserts that the expression e is defined (and non-deterministic). Notation for asserting undefinedness: No special notation. Canonical undefined term: chaos 1.3.5 logic Notation and interpretation for logical connectives: The logic is conditional: eb1 ∨ eb2 is equivalent to if eb1 then true else eb2 end eb1 ∧ eb2 is equivalent to if eb1 then eb2 else false end eb1 ⇒ eb2 is equivalent to if eb1 then eb2 else true end ∼eb is equivalent to if eb then false else true end If the logic is two-valued: can truth-values be undetermined/irrelevant? 1.3.6 strictness Are all operations strict w.r.t. undefinedness? No, if-then-else is not. If so, how is the effect of an if-then-else operation provided? Can exception-handling and/or error-recovery be expressed? There are no special constructs. 1.3.7 other Any feature not covered above:

5

RSL

1.4 Notations 1.4.1 offside rule Is layout significant for parsing? No. If so, explain how, e.g., ‘offside rule’: 1.4.2 graphical symbols Are non-ASCII characters allowed? Yes. If so, is there always an equivalent ASCII representation? Yes. 1.4.3 overloading Can the same declared operation symbol be used on distinct (unrelated) types? Yes. Are there any built-in overloaded operation symbols? Yes. 1.4.4 mixfix notation Can applications of declared operations/predicates be written prefix, infix, postfix, mixfix? Yes, prefix and infix. Notation for declaring fixity: No special notation. The fixity is determined by the operation symbol itself. Notation for applications with alternative fixity, if any: Can operations with varying numbers of arguments be declared? No. Notation: 1.4.5 operator precedence Can grouping in terms be disambiguated using precedence? Yes. If so, how is precedence declared/determined? It is pre-defined. 1.4.6 associativity Can (binary) operations be declared associative? No. Can (binary) operations be declared left- or right-associative? No. Notation: 1.4.7 values of predefined types Notation: Values of type Values of type Values of type Values of type Values of type Values of type Values of type

Bool: true, false. Int: ..., -1, 0, 1, ... Nat: 0, 1, ... Real: ..., -1.03, 0.0, ... Char: ’a’, ...,’5’, ..., ’ ’ Text: ..., ”house”, ... Unit: skip

1.4.8 other Any feature not covered above:

RSL

6

1.5 Abbreviations 1.5.1 type inference Can instantiation of polymorphic operations be inferred? If so: always, usually, or only sometimes? Usually. Are explicit ‘casts’ allowed? Yes. Notation: value expr : type expr 1.5.2 conditionals Can several conditional axioms with the same tests be combined? No. 1.5.3 variable abstraction Can terms be assigned to variables explicitly in formulae or subterms, e.g., using let or where? Yes, using a let. 1.5.4 variable inference Can/must declarations of variables be left implicit? Variables must be bound but in let and case expressions their types may be implicit. Can variables of unrestricted type (‘wild cards’) be declared? Wildcards can be used in case and let expressions. They are not of unrestricted type, as their types can be inferred; rather they are just anonymous variables. 1.5.5 lambda-abstraction Is it allowed in terms? Yes. Notation: λ id : type expr · value expr 1.5.6 other Any feature not covered above:

1.6 Other Any aspect not covered above:

2 Specification in the Large 2.1 Structuring Concepts 2.1.1 structure of specifications v. programs Does the specification language include a programming language? Not explicitly, but there is a directly executable subset (sorts only in formal parameters, explicit definitions, no axioms, etc.) If so, what differences are there between specification and program structuring? None. 2.1.2 structuring logic/institution-independence Are all the structuring constructs independent of the details of ‘specification in the small’ ? Yes apart from some (statically decidable) well-formedness conditions.

RSL

7

2.1.3 other Any feature not covered above:

2.2 Basic Constructs 2.2.1 naming What are the scopes of declared names? The immediate scope of a name, id, is the class expression, C, in which it is defined. The scope can be extended to another class expression, C2, by the construct extend C with C2. Notation for referring to particular names: If an object module, M, defines an entity with name, id, this entity can be referred to outside M by M.id How are entities having the same name treated when combined (by union, import, etc.): Two class expressions combined by the extend construct must not declare non-value entities with the same name. Two object modules, M1 and M2, can define the same name, id, since these can be distinguished as M1.id and M2.id 2.2.2 union Notation: extend class expr1 with class expr2 Is the combination ‘syntactic’ or ‘semantic’: ‘syntactic’ 2.2.3 renaming Notation: use id1 for id2 , ... in class expr Are unrenamed entities hidden, preserved, or forbidden? preserved 2.2.4 hiding Notation: hide id-list in class expr 2.2.5 sub-specifications Can parts of specifications be inherited? No. If so, is multiple inheritance allowed? Notation: 2.2.6 nesting of signatures Can signatures be nested? Signatures do not appear as independent entities in RSL. Notation: 2.2.7 morphisms as entities Notation: 2.2.8 behavioural encapsulation Notation: 2.2.9 other basic structuring constructs Notation and interpretation:

RSL

8

2.2.10 other Any feature not covered above: RSL includes as modules both schemes (possibly parametrized classes) and objects (models of classes). In particular objects allow the resolution of the “sharing” problem, which is particularly critical given (imperative) variables and channels. Modules can be nested.

2.3 Parametrization 2.3.1 specifications parametrized by programs Notation: 2.3.2 specifications of parametrized programs Notation: Schemes may be parameterized. The form is: scheme S(X1 : ce1, ..., Xn : cen) = ce, where ce1, ..., cen and ce are class expressions. There are no distinctions between class expressions that may be used as formal parameters and class expressions that may be used as bodies. 2.3.3 higher-order parametrization Notation: None, but some of the effects are possible because one can write for example scheme S(X1 : ce1, X2 : S2(X1), ...) = ce 2.3.4 dependent specifications Notation: None. 2.3.5 uniqueness of instantiations Do two identical instantiation expressions denote the same entity? No. 2.3.6 other Any feature not covered above: RSL also provides object arrays.

2.4 Multiple Logics 2.4.1 heterogeneous specifications Can several different logics be used in the same specification? No. 2.4.2 heterogeneous developments Is it possible to change the logic during development? No. 2.4.3 logic morphisms, representation morphisms With heterogeneity, what constructs support the composition/change of logics? 2.4.4 navigation in logic graph With heterogeneity, what is the relationship between the different logics provided?

RSL

2.4.5 composition, instantiation, sub-framework Notation: 2.4.6 other Any feature not covered above:

2.5 Other Any aspect not covered above:

9