CASL Common Algebraic Specification Language Guided Tour Peter

CASL Common Algebraic Specification Language Guided Tour Peter D. Mosses (BRICS, Aarhus, Denmark) External Relations Coordinator of COFI: The Common Framework Initiative for algebraic specification and development 1

Plan Background CASL – basic specifications – structured specifications – architectural specifications – libraries of specifications Foreground 2

Background Lack of a common framework meant – industrial acceptance: discouraged – dissemination: hindered – tool applicability: limited Why not agree on a common framework? – concepts – language – methodologies 3

Aims a common framework—a collaborative effort for algebraic specification & development attractive – short term: to researchers; long term: for use in industry providing a common specification language – syntax: uniform, user-friendly; semantics: straightforward subsuming many previous frameworks good documentation & tool support free—but protected! 4

Scope specifying functional requirements formal development & verification of software relation of specifications to: – informal requirements – implemented code prototyping, theorem-proving libraries, reuse, evolution providing tool interoperability 5

CASL: Common Algebraic Specification Language critical selection of existing constructs expressive, simple, pragmatic specifying requirements and design for conventional software packages restrictions to sub-languages extensions to higher-order, state-based, concurrent, … 6

CASL Design Process design started: September 1995 design proposed: May 1997 – summary, abstract syntax, semantics – tentatively approved by IFIP WG 1. 3 design finalized: October 1998 – complete language summary available – formal semantics, rationale are being updated 7

Parts of CASL Basic specifications – declarations, definitions, axioms Structured specifications – translations, reductions, unions, extensions, freeness – named specifications, generic specifications, views Architectural specifications – implementation units, composition Specification libraries – distributed 8

Aspects of CASL design Design issues – methodology, tools, aesthetics Semantic concepts – formal (institutions, environments) – informal (expansions, scopes) Language constructs – abstract syntax (structure, annotations) – concrete syntax (input, display) 9

Presentation 10

Basic specifications Design issues Semantic concepts Language constructs – concrete syntax (display format) – trivial illustrative examples 11

Design issues Partial and total functions Logic and predicates Classes of models Overloading Subsorts Datatype constructors/selectors 12

Partial and total functions error propagation implicit (strictness) – any argument undefined result undefined totality an important special case – all arguments defined result defined domain of definition may be implicit – not always a natural sort/subsort equations may require definedness or not – existential equations require it, strong do not 13

Logic and predicates classical 2 -valued first-order logic – standard interpretation of connectives predicates – better than (total) Boolean functions! – any argument undefined unsatisfied quantification, connectives – expressiveness – restrictions in sublanguages 14

Classes of models all models – loose semantics generated models – only expressible values considered – induction proofs sound initial (and freely-generated) models – minimal satisfaction, definedness – may not exist (disjunction, negation, . . . ) 15

Overloading declaration – same symbol, various profiles (arg/result sorts) » e. g. ‘ ’ on integers, reals, strings, … use – intended profile determined by context – disambiguation when needed by specifying profile (or result sort) of applications 16

Subsorts embeddings – not necessarily inclusions (e. g. Int values represented differently from Real values) commute with overloaded functions – values independent of profiles – 2+2=4 (natural numbers, integers, …) no ‘regularity’ conditions on declarations – for simplicity, modularity 17

Datatype constructors/selectors frequently needed – correspond to (unions of) record types, enumeration types abbreviate tedious declarations, axioms – for constructors and selectors may be loose, generated, or free 18

Semantic concepts Signatures Models Sentences Satisfaction Sort generation constraints Institution Semantic functions 19

Signatures S TF PF P sorts S operations: total TF, partial PF (disjoint) predicates P subsort embeddings unrestricted overloading 20

Models Mod , S TF PF P carrier sets are non-empty embedding, overloading are compatible – embeddings commute with overloaded ops operations are partial functions – necessarily total when so declared predicates are relations on carriers 21

Sentences Sen S TF PF P closed, many-sorted first-order formulae atomic formulae: – equations: strong, existential – definedness, membership assertions – fully-qualified predicate applications terms: – fully-qualified operation applications, variables, sorted terms, casts 22

Satisfaction M Mod , Sen the value of a term may be undefined when value of argument undefined: – predicate never holds – operation result always undefined existential equation: defined and equal strong equation: both undefined or equal 23

Sort generation constraints S TF PF P sentences Sen : S F S F where F TF PF satisfaction M : – when carriers of sorts in S generated by functions in F (possibly from sorts not in S ) 24

Institution M Mod Sen S TF PF P morphisms – preserve overloading, embeddings, totality – determine reducts Mod homomorphisms h M M M 1, M 2 Mod – preserve operation values, holding predicates translation preserves satisfaction – M iff Mod 25

Semantic functions expansion of atomic formulae – gives a set of well-sorted fully-qualified atoms – well-formed when unique (up to embeddings) reduction from subsorts to embeddings – S TF PF P S TF PF P embs, s s s basic specification semantics: – signature class of models Mod 26

Language constructs Signature declarations – sorts, operations, predicates, datatypes – sort generation constraints Axioms – variable declarations – quantifiers, connectives, atoms, terms Scope rules: declaration before use 27

Sorts declarations sorts Elem, List sorts Nat < Int subsort definitions sort Pos = { n: Nat • n > 0 } 28

Operations declarations ops 0 : Nat ; suc : Nat ; pre : Nat ? Nat ; __+__ : Nat, assoc, comm, unit 0 definitions ops 1 : Nat = suc(0) ; dbl(n: Nat) : Nat = n+n 29

Predicates declarations preds odd : Nat ; __<__ : Nat definitions preds even(n: Nat) odd(n) ; __ __(m, n: Nat m<n m=n 30

Datatypes non-linear visibility within types type Set : : = Set) free type Bit : : = free type Pair : : = free type List : : = free types List Ne. List Ø | {|__|}(Elem) | __ __(Set; 0 | 1 pair(left, right: Elem) nil | cons(hd: ? Elem; tl: ? List) : : = nil | sort Ne. List; : : = cons(hd: Elem; tl: List) 31

Sort generation constraints types generated type Bag : : = empty | add(Elem; Bag) generated types Nat : : = 0 | sort Pos; Pos : : = suc(pre: Nat) declarations generated { sorts Pos < Nat ; ops 0 : Nat ; suc : Nat Pos } 32

Axioms lists of axioms vars m, n : Nat; p : Pos axioms n < m … ; suc(n)=p … ; … vars x, y, z : Elem • x x • x y y z x z quantifiers n: Nat • m: Nat • n < m p: Pos • ! n: Nat • suc(n)=p 33

Axioms… logical connectives • • even(n) odd(n) m n m < n m = n m < n n = 0 even(m+n) if odd(m) odd(n) 34

Atomic formulae definedness • def pre(suc(n)) def pre(0) equations: existential, strong • def pre(n) suc(pre(n)) e= pre(suc(n)) • ok(x, e) find(x, cons(e, l)) = find(x, l) subsort membership • n Pos def pre(n) predicate application 35

Terms constants and variables • nil, Ø, empty_set, n, n , CURRENT_STATE applications (functional, mixfix notation) • cons(e, l), {|e|} s, (op pre: Nat ? Nat)(n) sorted terms (identity, embedding) • dbl(suc(n): Nat) casts (projection) • pre(n as Pos) 36

Basic specification example free types Nat : : = 0 sort Pos; Pos : : = suc(pre: Nat) op pre : Nat ? Nat axioms def pre(0); n: Nat • pre(suc(n)) = n pred even__ : Nat var n: Nat • even 0 • even suc(n) even n 37

Break! 38

Structured specifications Design issues Semantic concepts Language constructs 39

Design issues No model structure Names of symbols Generic extension 40

No model structure of specification of structure! models of structured specifications – same kind as for basic specifications separate architectural specifications 41

Names of symbols general principle: same name, same thing! – the “name” of an operation or predicate includes its profile, so overloading does not require identification (except with subsorts) applies both to unions and extensions – but not to named specifications in libraries – clashes can be eliminated by renaming 42

Names of symbols… auxiliary symbols are to be hidden – hidden symbols are irrelevant – revealed symbols are significant tools may warn about duplicate declarations – no problem when same origin 43

Generic extension specification definitions – reuse by reference to name generic parameters – parameters intended to vary – reuse requires instantiation – not intended for defining arbitrary functions on specifications (macros) 44

Semantic concepts signature, class of models – as for basic specifications institution-independent structure – many-sorted, subsorted, … – reduct homomorphisms local environment – visible symbol declarations 45

Semantic functions compositional denotations of complete specifications: – signatures and model-classes denotations of extending parts: – (partial) functions from signatures to extended signatures, and from corr. model classes to model classes 46

Language constructs translation, reduction, union, extension, free extension, local specifications specification definitions generic parameters, instantiation, views, compound identifiers 47

Translation & reduction translation NAT with Natural, succ__ NAT with op __+__ plus, pred __<__ lt TRUTH-VALUES with sort Bool, ops … reduction NAT hide Pos, suc NAT reveal Nat, 0, __+__ , __<__ lt 48

Unions & extensions union (disjoint, conjoint) NAT and STRING MONOID and COMMUTATIVE extension (symbols and/or properties) NAT then sort Nat < Int ; ops __+__ : Int; … BAG then axiom b: Bag • b b = b – conservativeness: use annotations 49

Free specifications initiality free { sort Nat ; ops 0 : Nat ; suc : Nat } free extension sort Elem then free { type Set : : = Ø | {|__|}(Elem) | __ __(Set; Set) op __ __ : Set, assoc, comm, idem, unit Ø } 50

Local specifications implicit hiding of auxiliary symbols sort Nat op 0 : Nat then local op suc : Nat within op __+__ : Nat vars m, n : Nat • m+0 = m • m+suc(n) = suc(m+n) 51

Named specifications only closed specifications can be named intended for inclusion in libraries spec NAT = free { … } spec INT = NAT then free { … } 52

Generic parameters are closed subspecifications spec ELEM = sort Elem spec LIST [ELEM] = free type List : : = nil | cons(Elem; List) instantiation provides fitting arguments LIST [NAT fit Elem Nat] 53

Generic parameters… sharing between parameter symbols preserved by fitting spec PAIR [sort Elem 1] [sort Elem 2] = free type Pair : : = pair(Elem 1; Elem 2) sharing between body and arguments restricted to explicit imports ( pushout) spec LIST [ELEM] given NAT = free type List : : = nil | cons(Elem; List) op length : List Nat 54

Compound identifiers for avoiding unintentional name clashes spec ELEM = sort Elem spec LIST [ELEM] = free type List[Elem] : : = nil | cons(Elem; List[Elem]) declared sorts now List[Nat], List[Char] in: LIST [NAT fit Elem Nat] and LIST [CHAR fit Elem Char] 55

Views named specification morphisms view PO 2 NAT : PARTIAL_ORDER to NAT = Elem Nat, __ __ ORD_LIST[view PO 2 NAT] implicit identity maps implicit unique extension to morphism ORD_LIST[NAT] generic views 56

Structured specification example spec LIST_WITH_ORDER [PARTIAL_ORDER] = free type List[Elem] : : = nil | cons(hd: ? Elem; tl: ? List[Elem]) then local op insert : Elem List[Elem]; vars x, y : Elem; l : List[Elem] axioms insert(x, nil) = cons(x, nil); x y insert(x, cons(y, l)) = cons(x, insert(y, l)); (x y) insert(x, cons(y, l)) = cons(y, insert(x, l)) within op order[__ __] : List[Elem] vars x : Elem; l : List[Elem] axioms order[__ __](nil) = nil; order[__ __](cons(x, l)) = insert(x, order[__ __](l)) end 57

Architectural specifications Design issues Semantic concepts Language constructs 58

Design issues Reusability Interfaces Decomposition of tasks – composition of results 59

Reusability structure of specifications reusable specifications specification of structure reusable design/implementation units – e. g. structure implementation of LIST [NAT] as: » implementation N of NAT and » a function F extending any such N to an implementation of LIST [NAT] and » compose by applying F to N 60

Interfaces explicit assumptions that parts of the implementation make about others explicit guarantees about results under the given assumptions 61

Decomposition/composition architectural specifications specify decomposition of implementation development task into sub-tasks also how to compose results of sub-tasks into result of main task 62

Semantic concepts model of architectural specification: – collection of (named) unit constructors – unit (constructor) resulting from composition unit constructors: – constants – functions from units to units » persistent, extending arguments » arguments must be compatible 63

Language constructs architectural specification definitions unit declarations, unit definitions unit specifications unit expressions 64

Architectural specifications definitions arch spec IMP_NAT_LIST = units N : NAT ; F : NAT LIST[NAT] result F[N] 65

Unit declarations & definitions declarations N : NAT L : LIST[NAT] given N F : NAT LIST[NAT] definitions L = F[N] L = F[N fit …] hide … 66

Unit specifications definition unit spec GEN_LIST = NAT LIST[NAT] use F : GEN_LIST architectural specifications may also be used as unit specifications 67

Unit expressions application (to compatible arguments) F[N], F[N fit…] abstraction N: NAT • …N… translation, reduction U with…, U hide…, … amalgamation (of compatible units) N and C 68

Architectural specification example spec LIST[ELEM] = free type List[Elem] : : = nil cons(Elem; List[Elem]) arch spec CN_LIST = units C : CHAR N : NAT ; F : ELEM LIST[ELEM] result F[C fit Elem Char] and F[N fit Elem Nat] 69

Libraries of specifications Design issues Semantic concepts Language constructs 70

Design issues visibility of symbols between specifications – none visibility of specification names – linear distributed libraries on Internet – indirect links – explicit downloading version control 71

Semantic concepts global environment – mapping specification names to their denotations directory of registered libraries – mapping library names to their registered URLs – giving access to previous versions of libraries state of the universe (Internet, local files) 72

Language constructs Local libraries Distributed libraries 73

Local libraries definition before use library COFI_BEANS spec NAT = … view … arch spec … = …NAT… unit spec … 74

Distributed libraries downloading from Co. FI_BEANS get LIST, NATURAL version library COFI_BEANS version … from COFI_PLANT version … get … – default is current (registered) version 75

Foreground Language design tasks Semantics tasks Tools tasks Methodology tasks Reactive system tasks Overall coordination: – Peter D. Mosses (Aarhus) Sep 95 – Aug 98 – Don Sannella (Edinburgh) Sep 98 – … 76

Language design tasks coordination: – Bernd Krieg-Brückner (Bremen) finalization of CASL design documentation of design sub-languages – total, many-sorted, equational, … extensions – higher-order, state-based, … 77

Semantics tasks coordination: – Andrzej Tarlecki (Warsaw) update of formal semantics to v 0. 99 choice of proof system for CASL 78

Methodology tasks coordination: – Michel Bidoit (Cachan) user’s guide case studies relation of specifications to requirements and code development processes 79

Tools tasks coordination: – Hélène Kirchner (Nancy) parsers – 4 prototypes implemented interoperability of existing tools formatting (LATEX package, HTML filter) static analysis, proof tools – prototype implemented 80

Reactive system tasks coordination: – Egidio Astesiano (Genova) extensions of CASL for reactive system specification combination of CASL with concurrency 81

External relations tasks coordination: – Peter D. Mosses (Aarhus) relation to existing languages – ASF+SDF, CAFEOBJ (so far superficially) – help needed from experts! liaison with IFIP WG 1. 3 web presentation of COFI tutorial 82

Join now! all task groups welcome new participants – contact the coordinators all cofi- mailing lists open to subscription – moderated – administered by Majordomo program – cofi-list@brics. dk: low-volume, announcements only all documents available on the web/ftp 83

References COFI Home Page – http: //www. brics. dk/Projects/Co. FI/ CASL Summary – …/Documents/CASL/Summary/ COFI Rationale – EATCS Bulletin 59, June 1996 – Proc. TAPSOFT’ 97, LNCS 1214, 1997 84