Introduction to CASL, the Common Algebraic Specification Language Franz Lichtenberger Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria [email protected]
Introduction to CASL,the Common Algebraic Specification
LanguageFranz Lichtenberger
Research Institute for Symbolic Computation (RISC)Johannes Kepler University, Linz, Austria
[email protected]linz.ac.at
Franz Lichtenberger http://www.risc.unilinz.ac.at 2
Contents
● Historical remarks● General remarks about CASL● Underlying Concepts● CASL by examples
(Basic Specifications only)
Franz Lichtenberger http://www.risc.unilinz.ac.at 3
Historical Remarks
● First papers on Algebraic Specification of Abstract Data Types, around 1975: Liskov/Zilles, Guttag/Horning, ADJGroup (Goguen, Thatcher, Wagner, Wright)
● Several AlgSpec languages developed in the next 20 years● CoFI: The Common Framework Initiative for Algebraic
Specification and Development, EUProject, started 1995● The specification language defined by CoFI:
CASL – The Common Algebraic Specification Language
Franz Lichtenberger http://www.risc.unilinz.ac.at 4
Algebraic Specification
● Observation/Claim/Thesis:● Data types are algebras (set(s)+operations+axioms)● Abstract data types (ADTs) are classes of (usually heterogeneous)
algebras● (Software) Systems can be specified by ADTs.
● Thus:ADTs / Software systems can/should be specified algebraically
● CASL: a language for specifying requirements and designs, not a programming language
Franz Lichtenberger http://www.risc.unilinz.ac.at 5
CASL
● Core of a family of languages:● restrictable (e.g. for executability)● extendable (higher order, state based, reactive, modal, ...)
● CASL specifications denote classes of models● CASL has a complete formal definition● Abstract and concrete syntax are defined formally● CASL has a complete formal semantics● The foundations of CASL are rocksolid!
(Claim by CoFI)
Franz Lichtenberger http://www.risc.unilinz.ac.at 6
CASL Specifications
● Basic specifications (this talk)● Structured specifications
● Large and complex specifications are easily built out of simpler ones by means of (a small number of) specification building operations
● Architectural specifications● impose structure on implementations
● Libraries● are named collections of named specifications● The CASL Basic Libraries contain the standard datatypes
Franz Lichtenberger http://www.risc.unilinz.ac.at 7
Underlying concepts
● CASL is based on standard concepts of algebraic specification● Basic specifications declare symbols, and give axioms and
constraints● The semantics of a basic specification is (a signature and) a
class of models:● A signature ∑ corresponding to the symbols introduced by the
specification● a class of ∑-models, corresponding to those interpretations of the
signature that satisfy the axioms and constraints of the specification● When a model M satisfies a specification SP we write
M \models SP
Franz Lichtenberger http://www.risc.unilinz.ac.at 8
Specifications
● CASL specifications may declare● sorts● subsorts● operations● predicates
● A spec is called manysorted if it has no subsort specifications (otherwise subsorted)
● A spec is called algebraic if it has no predicate declarations
Franz Lichtenberger http://www.risc.unilinz.ac.at 9
Sorts
● A sort is a symbol which is interpreted as a set, called a carrier set
● The Elements of carrier sets are abstract representations of data: numbers, characters, lists, trees, etc.
● A sort is approx. a type in a programming language● CASL allows compound sort symbols, i.e.
List[Int]
Franz Lichtenberger http://www.risc.unilinz.ac.at 10
Subsorts
● Subsort declarations are interpreted as embeddings● Set inclusion would be sufficient for, e.g.
Nat < Int● Embedding is necessaray for, e.g.
Char < String(Char and String are disjoint)
● An embedding is a 11 function
Franz Lichtenberger http://www.risc.unilinz.ac.at 11
Operations
● Operations may be declared as total or partial● An operation symbol consists of its name together with its profile● Profile: number and sort of arguments, and result sort● An operations is interpreted as a total or a partial function from
the Cartesion product of the carrier sets of the arguments to the carrier set of the result sort
● The result of applying an operation is undefined if any of the arguments is undefined
● Constant: operation with no arguments, interpreted as an element of the carrier set of the result sort
Franz Lichtenberger http://www.risc.unilinz.ac.at 12
Predicates
● A predicate symbol consists of a name and its profile● Profile: number and sorts of the arguments, but no result sort● Predicates are different from booleanvalued operations!!!● Predicates are used to form atomic formulas, rather than terms● A predicate symbol is interpreted as a relation on (i.e., a subset
of) the Cartesian product of the carrier sets of the argument sorts● Predicates are never undefined, they just do not hold if any of the
arguments is undefined (twovalued logic)● For booleanvalued operations: threevalued logic (true, false,
undefined)
Franz Lichtenberger http://www.risc.unilinz.ac.at 13
Overloading
● Operation and predicate symbols may be overloaded, i.e.● can be declared with different profiles in the same specification● Examples:
● 'empty' for empty list and empty set● < : predicate on unrelated sorts such as Char and Int
● Overloading has to be compatible with embeddings between subsorts, i.e.
● for sorts Nat < Int, operation +, predicate <:interpretations are required to be such that it makes no difference whether the embedding from Nat to Int is applied to the arguments (and the result) or not
Franz Lichtenberger http://www.risc.unilinz.ac.at 14
Atomic Formulas
● predicate applications● equations (strong or existential)
● existential: both sides are defined and equal● strong: hold as well, if both sides are undefined
● definedness assertions● subsort membership assertions
Franz Lichtenberger http://www.risc.unilinz.ac.at 15
Axioms
● Axioms are formulas of firstorder logic● Logical connectors have usual interpretation● Quantification: universal, existential, uniqueexistential● Interpretation of quantification: completely standard!● Variables in formulas range over the carrier sets of specified
sorts● An axiom either holds or does not hold in a particular model:
there is no “maybe” or undefinedness about holdig(regardless of whether the values of terms occurring in the axioms are defined)
Franz Lichtenberger http://www.risc.unilinz.ac.at 16
Constraints
● Sort generation constraints eliminate “junk” from specific carrier sets, i.e. restrict the class of models
● Default case: all sets allowed as carriers● Generated: no junk
all elements can be obtained by consecutively applying the operations of the sort in question
● Free: no junk, no confusiongenerated, and no equations hold except those implied by the axioms
Franz Lichtenberger http://www.risc.unilinz.ac.at 17
CASL by examples
● Simple specifications can be written essentially as in many other algebraic specification languages
● CASL provides useful abbreviations and annotations● Tools: the Heterogeneous Tools Set (HETS) is the main analysis
tool for CASL;● it provides a parser, static analysis and translation to an
intermediate/exchange format (so called Aterms)● Useful only together with other tools like theorem provers
(Isabelle/HOL, etc.), SWdevelopment environments, ...● Not tried out yet!
Franz Lichtenberger http://www.risc.unilinz.ac.at 18
Loose specifications
spec Strict_Partial_Order =%% Let's start with a simple example ! sort Elem pred __<__ : Elem * Elem %% pred abbreviates predicate forall x, y, z:Elem . not (x < x) %(strict)% . (x < y) => not (y < x) %(asymmetric)% . (x < y) /\ (y < z) => (x < z) %(transitive)% %{ Note that there may exist x, y such that neither x < y nor y < x. }%end
Franz Lichtenberger http://www.risc.unilinz.ac.at 19
Specification extension
spec Total_Order = Strict_Partial_Orderthen forall x, y:Elem . (x < y) \/ (y < x) \/ x = y %(total)%end
Franz Lichtenberger http://www.risc.unilinz.ac.at 20
Abbreviations
spec Total_Order_With_MinMax = Total_Orderthen ops min(x, y :Elem): Elem = x when x < y else y; max(x, y :Elem): Elem = y when min (x, y) = x else xendabbreviates forall x,y:Elem . min(x,y) = x when x<y else ywhich abbreviates (x<y => min(x,y)=x) /\ (not(x<y) => min(x,y)=y)
Franz Lichtenberger http://www.risc.unilinz.ac.at 21
Prettyprinting
spec Partial_Order = Strict_Partial_Orderthen pred __<=__(x, y :Elem) <=> (x < y) \/ x = yend
“less or equal” can be prettyprinted using
%display __<=__ %LATEX __\le__
Not tried out yet!
Franz Lichtenberger http://www.risc.unilinz.ac.at 22
Redundancy with %implies annotation
spec Partial_Order_1 = Partial_Orderthen %implies forall x, y, z:Elem . (x <= y) /\ (y <= z) => (x <= z) %(transitive)%end
Can be used to generate the proof obligation
Partial_Order \models (x <= y) /\ (y <= z) => (x <= z)
Franz Lichtenberger http://www.risc.unilinz.ac.at 23
Attributes
spec Monoid = sort Monoid ops 1 : Monoid; __*__ : Monoid * Monoid > Monoid, assoc, unit 1end
assoc abreviates, as expected, the following axiom:
forall x,y,z:Monoid . (x*y)*z = x*(y*z)
Franz Lichtenberger http://www.risc.unilinz.ac.at 24
Generic specifications via parameters
spec Generic_Monoid [sort Elem] = sort Monoid ops inj : Elem > Monoid; 1 : Monoid; __*__ : Monoid * Monoid > Monoid, assoc, unit 1 forall x, y:Elem . inj (x) = inj (y) => x = yend
Franz Lichtenberger http://www.risc.unilinz.ac.at 25
Datatype declarations by constructors
spec Container [sort Elem] = type Container ::= empty | insert(Elem; Container) pred __is_in__ : Elem * Container forall e, e':Elem; C:Container . not (e is_in empty) . (e is_in insert (e', C)) <=> e = e' \/ (e is_in C)end
Abbreviation for:
sort Container ops empty: Container; insert: Elem * Container > Container
Franz Lichtenberger http://www.risc.unilinz.ac.at 26
Generated Specifications
spec Generated_Container [sort Elem] = generated type Container ::= empty | insert(Elem; Container) pred __is_in__ : Elem * Container forall e, e':Elem; C:Container . not (e is_in empty) . (e is_in insert (e', C)) <=> e = e' \/ (e is_in C)end
● Generated types allow induction over the constructors!
Franz Lichtenberger http://www.risc.unilinz.ac.at 27
Free specifications
spec Natural = free type Nat ::= 0 | suc(Nat)end
Equivalent to
generated type Nat ::= 0 | suc(Nat) forall x,y: Nat . suc(x)=suc(y) => x=y forall x:Nat . not(0 = suc(x))
Franz Lichtenberger http://www.risc.unilinz.ac.at 28
Enumerated types
● Free datatype declarations are particulary convenient for defining enumerated types
spec Color = free type RGB ::= Red | Green | Blue free type CMYK ::= Cyan | Magenta | Yellow | Blackend
With generic instead of free one woud have to add
not(Red=Green) /\ not(Red=Blue) /\ ...
Franz Lichtenberger http://www.risc.unilinz.ac.at 29
Freeness constraints
spec Integer =free {type Int ::= 0 | suc(Int) | pre(Int) forall x:Int . suc (pre (x)) = x . pre (suc (x)) = x}end
Franz Lichtenberger http://www.risc.unilinz.ac.at 30
Predicates and freeness
● Predicates hold minimally in models of free specifications
spec Natural_Order = Naturalthenfree {pred __<__ : Nat * Nat forall x, y:Nat . 0 < suc (x) . (x < y) => (suc (x) < suc (y))}end
Franz Lichtenberger http://www.risc.unilinz.ac.at 31
Inductive definitions of operations/predicates
spec Natural_Arithmetic = Natural_Orderthen ops __+__ : Nat * Nat > Nat; __*__ : Nat * Nat > Nat forall x, y:Nat . x + 0 = 0 . x + suc (y) = suc (x + y) . x * 0 = 0 . x * suc (y) = (x * y) + xend
Franz Lichtenberger http://www.risc.unilinz.ac.at 32
Partial Functions
● Partial functions arise naturally● Partial functions are declared differently from total functions
spec Set_Partial_Choose [sort Elem] = Generated_Set [sort Elem]then op choose : Set >? Elemend
Franz Lichtenberger http://www.risc.unilinz.ac.at 33
Partial functions: properties
● Terms containing partial functions may be undefined, i.e., they may fail to denote any value.
● Functions, even total ones, propagate undefinedness.● Predicates do not hold on undefined arguments.● Equations hold when both terms are undefined.● Special care is needed in specifications involving partial
functions
Franz Lichtenberger http://www.risc.unilinz.ac.at 34
Partial functions: subtle sideeffects
● Asserting choose(S) is_in S as an axiom implies choose(S) is defined for any S.
● Asserting insert(choose(S),S)=S as an axiom implieds that choose(S) is defined for any S.
● If an operation is declared both as a total operation and as a partial operation with the same profile then it is interpreted as a total operation in all models of the specification.
Franz Lichtenberger http://www.risc.unilinz.ac.at 35
Specifying Domains of Definition
● The domains of definition of partial functions can be specified exacty
spec Set_Partial_Choose_2 [sort Elem] = Set_Partial_Choose [sort Elem]then forall S:Set . def choose(S) <=> not (S = empty) forall S:Set . def choose(S) => choose(S) is_in Send
Franz Lichtenberger http://www.risc.unilinz.ac.at 36
Domains of definition: specified too implicitely
● Same meaning as previous spec, but some reasoning necessary:
spec Set_Partial_Choose_3 [sort Elem] = Set_Partial_Choose [sort Elem]then . not def choose(empty) forall S:Set . not (S = empty) => choose(S) is_in Send
Franz Lichtenberger http://www.risc.unilinz.ac.at 37
Partial functions and free specifications
● Partial functions are minimally defined by default in free specifications
spec List_Selectors_1 [sort Elem] = List [sort Elem]thenfree {ops head : List >? Elem; tail : List >? List forall e:Elem; L:List . head(cons(e, L)) = e . tail(cons(e, L)) = L}end
Franz Lichtenberger http://www.risc.unilinz.ac.at 38
The same, but easier to understand
spec List_Selectors_2 [sort Elem] = List [sort Elem]then ops head : List >? Elem;tail : List >? List forall e:Elem; L:List . not def head(empty) . not def tail(empty) . head(cons(e, L)) = e . tail(cons(e, L)) = Lend
Franz Lichtenberger http://www.risc.unilinz.ac.at 39
Partial selectors and constructors
● Selectors can be specified concissely in datatype declarations, and are usually partial
spec List_Selectors [sort Elem] = free type List ::= empty | cons(head:?Elem; tail:?List)end
Franz Lichtenberger http://www.risc.unilinz.ac.at 40
Existential Equality
● Existential equality requires the definedness of both terms as well as their equality
spec Natural_Partial_Subtraction_2 = Natural_Partial_Subtraction_1then forall x, y, z:Nat . y x =e= z x => y = z %{ y x = z x => y = z would be wrong, def (yx) /\ def (zx) /\ y x = z x => y = z is correct, but better abbreviated in the above axiom }%end
Franz Lichtenberger http://www.risc.unilinz.ac.at 41
Subsorting
● Subsort declaratins directly express relationsships between carrier sets
spec Generic_Monoid_1 [sort Elem] = sort Elem < Monoid ops 1 : Monoid; __*__ : Monoid * Monoid > Monoid, assoc, unit 1end
Franz Lichtenberger http://www.risc.unilinz.ac.at 42
Inheritance
● Operations on a sort are automatically inherited by its subsortsspec Vehicle = Naturalthen sorts Car, Bicycle < Vehicle ops max_speed : Vehicle > Nat; weight : Vehicle > Nat; engine_capacity : Car > Natend● Inheritance applies also for subsorts that are declared afterwardsspec More_Vehicle = Vehiclethen sort Boat < Vehicleend
Franz Lichtenberger http://www.risc.unilinz.ac.at 43
● Subsort membership can be checked or assertedspec Speed_Regulation = Vehiclethen ops speed_limit : Vehicle > Nat; car_speed_limit, bike_speed_limit : Nat forall v:Vehicle . (v in Car) => speed_limit(v) = car_speed_limit . (v in Bicycle) => speed_limit(v) = bike_speed_limitend
Franz Lichtenberger http://www.risc.unilinz.ac.at 44
Subsorts in type declarations
● sorts Car, Bicycle, Boattype Vehicle ::= sort Car | sort Bicycle | sort Boat
● is equivalent to:sorts Car, Bicycle, Boat < Vehicle
● Vehicle 'contains' the union of Car, Bicycle, Boat● generated type Vehicle ::= sort Car | sort Bicycle | sort Boat
Vehicle 'is exactly' the union of Car, Bicycle, Boat● free type Vehicle ::= sort Car | sort Bicycle | sort Boat
Vehicle 'is exactly' the disjoint union of Car, Bicycle, Boat
Franz Lichtenberger http://www.risc.unilinz.ac.at 45
Explicit definition of subsort values
spec Natural_Subsorts = Natural_Arithmeticthen pred even : Nat . even(0) . not even(1) forall n:Nat . even(suc(suc(n))) <=> even(n) sort Even = {x : Nat . even(x)} sort Prime = {x : Nat . 1 < x
/\ (forall y, z:Nat . x = y * z => y = 1 \/ z = 1)}end
Franz Lichtenberger http://www.risc.unilinz.ac.at 46
Subsorts and overloading
spec Positive = Natural_Partial_Prethen sort Pos = {x : Nat . not x = 0}end
spec Positive_Arithmetic = Positivethen ops 1 : Pos;suc : Nat > Pos;
__+__, __*__ : Pos * Pos > Pos;__+__ : Pos * Nat > Pos;__+__ : Nat * Pos > Pos
end
Franz Lichtenberger http://www.risc.unilinz.ac.at 47
Subsorts and partiality
● Using subsorts may avoid the need for partial functionsspec Positive_Pre = Positive_Arithmeticthen op pre : Pos > Natend● instead of then op pre : Nat >? Nat
Franz Lichtenberger http://www.risc.unilinz.ac.at 48
Supersorts for errors or exceptions
spec Set_Error_Choose [sort Elem] = Generated_Set [sort Elem]then sort Elem < ElemError op choose : Set > ElemError pred __is_in__ : ElemError * Set forall S:Set . not S = empty => (choose(S) in Elem) /\ choose(S) is_in Send
Franz Lichtenberger http://www.risc.unilinz.ac.at 49
Casting is explicit
spec Set_Error_Choose_1 [sort Elem] = Generated_Set [sort Elem]then sort Elem < ElemError op choose : Set > ElemError forall S:Set . not S = empty => (choose(S) as Elem) is_in Send
Franz Lichtenberger http://www.risc.unilinz.ac.at 50
Final remarks
● This talk covered only basic specifications● Next talk: Structured specifications and libraries, with examples
of the CASL Basic Libraries● Further topics:
● Arcitectural specifications● Larger application example● Experiments with CASL + a theorem prover (probably ISABELLE)● Logic independence: the institution level