1 / 42

The Larch Shared Language

The Larch Shared Language. Based on: John V. Guttag and James J. Horning, Report on the Larch Shared Language, Science of Computer Programming , 6:103-134, North-Holland,1986. John V. Guttag and James J. Horning, Larch: Languages and Tools for Formal Specification, Springer-Verlag, 1993. 1.

duaa
Download Presentation

The Larch Shared Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Larch Shared Language Based on: John V. Guttag and James J. Horning, Report on the Larch Shared Language, Science of Computer Programming, 6:103-134, North-Holland,1986. John V. Guttag and James J. Horning, Larch: Languages and Tools for Formal Specification, Springer-Verlag, 1993. 1 1 1

  2. Outline • Background • LSL basics • Equational specifications • Stronger theories • Other features • Modularization: combining traits and renaming • Stating intended consequences • Recording assumptions • Built-in operators and overloading • Shorthand notations 2 2 2

  3. Model vs. Property-Oriented Specification Model-oriented Behavior directly by constructing a model of the system Use of math structures such as sets, sequences, relations, and functions E.g., Z data and operation schemas Z, VDM, and OCL Property-oriented Behavior indirectly by stating a set of properties Axiomatic vs. algebraic First-order predicate logic vs. equations Theory vs. (heterogeneous) algebra Larch and OJB vs. Clear and ACT ONE 3 3 3

  4. Larch Family of specification languages to specify interfaces of program modules Two tiered Different languages for different programming languages to specify interfaces of program modules One language for specifying shareable concepts and abstract models, called the Larch Shared Language (LSL) Larch/CLU LCL LM3 Larch/Smalltalk Larch/C++ LSL 4 4 4

  5. Example: Symbol Table Larch/CLU LSL 5

  6. Outline Background LSL basics Equational specifications Stronger theories Other features Modularization: combining traits and renaming Stating intended consequences Recording assumptions Built-in operators and overloading Shorthand notations 6 6 6

  7. First LSL Specification (v. 2.3 syntax) Table: trait introduces new:  Tab add: Tab, Ind, Val  Tab __  __: Ind, Tab  Bool lookup: Tab, Ind  Val isEmpty: Tab  Bool size: Tab  Int 0,1:  Int __+ __: Int, Int  Int asserts i, i1: Ind, val: Val, t: Tab (i  new); i  add(t, i1, val) == i = i1  i  t; lookup(add(t, i, val), i1) == if i = i1 then val else lookup(t, i1); size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1; isEmpty(t) == size(t) = 0 7 7 7

  8. Trait Table: trait introduces new:  Tab add: Tab, Ind, Val  Tab __  __: Ind, Tab  Bool lookup: Tab, Ind  Val isEmpty: Tab  Bool size: Tab  Int 0,1:  Int __+ __: Int, Int  Int asserts i, i1: Ind, val: Val, t: Tab (i  new); i  add(t, i1, val) == i = i1  i  t; lookup(add(t, i, val), i1) == if i = i1 then val else lookup(t, i1); size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1; isEmpty(t) == size(t) = 0 • Unit of LSL specification • Different from data abstraction (e.g., sort Tab) • Denotes a theory (a set of theorems) in multi-sorted first-order logic with equality 8 8 8

  9. Operations Table: trait introduces new:  Tab add: Tab, Ind, Val  Tab __  __: Ind, Tab  Bool lookup: Tab, Ind  Val isEmpty: Tab  Bool size: Tab  Int 0,1:  Int __+ __: Int, Int  Int asserts i, i1: Ind, val: Val, t: Tab (i  new); i  add(t, i1, val) == i = i1  i  t; lookup(add(t, i, val), i1) == if i = i1 then val else lookup(t, i1); size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1; isEmpty(t) == size(t) = 0 • Declare a set of operators with signatures (domain and range sorts) • Signatures for sort checking; sort implicitly introduced • Operators denote total functions • Prefix, infix, postfix, distributed operators (use of _ _) • Use of symbols, e.g.,  (\in) 9 9 9

  10. Constraints Table: trait introduces new:  Tab add: Tab, Ind, Val  Tab __  __: Ind, Tab  Bool lookup: Tab, Ind  Val isEmpty: Tab  Bool size: Tab  Int 0,1:  Int __+ __: Int, Int  Int asserts i, i1: Ind, val: Val, t: Tab (i  new); i  add(t, i1, val) == i = i1  i  t; lookup(add(t, i, val), i1) == if i = i1 then val else lookup(t, i1); size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1; isEmpty(t) == size(t) = 0 • Constrain operations by means of equations (t1 == t2 or t1 = t2) • Often t, short for t == true • Restrict theory denoted by trait • Trait’s assertions • Axioms of first-order logic • Everything that follows • Nothing else. • Q: Value of lookup(new, i)? 10 10 10

  11. Exercise • What values do the following terms denote? • isEmpty(new) • isEmpty(add(new,i,v)) • lookup(add(add(new,i,v1), i, v2), i) • lookup(add(add(new,I,v1), I, v2), j) asserts i, i1: Ind, val: Val, t: Tab (i  new); i  add(t, i1, val) == i = i1  i  t; lookup(add(t, i, val), i1) == if i = i1 then val else lookup(t, i1); size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1; isEmpty(t) == size(t) = 0

  12. Exercise • Define remove(Tab, Ind) and index(Tab, Val) operators. Table: trait introduces new:  Tab add: Tab, Ind, Val  Tab __  __: Ind, Tab  Bool lookup: Tab, Ind  Val isEmpty: Tab  Bool size: Tab  Int 0,1:  Int __+ __: Int, Int  Int asserts i, i1: Ind, val: Val, t: Tab (i  new); i  add(t, i1, val) == i = i1  i  t; lookup(add(t, i, val), i1) == if i = i1 then val else lookup(t, i1); size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1; isEmpty(t) == size(t) = 0

  13. Exercise • Formulate the notion of stack (LIFO) in LSL.

  14. Outline Background LSL basics Equational specifications Stronger theories Other features Modularization: combining traits and renaming Stating intended consequences Recording assumptions Built-in operators and overloading Shorthand notations 14 14 14

  15. Stronger Theories • Equational theories by trait assertions • Often stronger theories needed for specifying ADT, e.g., • How to prove a property of an ADT?  t: Tab, i: Ind  i t  size(t) > 0 • Generated by clause • Partitioned by clause

  16. Generated by Clause • A complete set of generators for a sort • Each value is equal to one written in terms of the generators. • Provides an induction rule, i.e., an axiom for • E.g., • 0 and succ for natural numbers Nat generated by 0, succ • 0, succ and pred for integers • Int generated by 0, succ, pred

  17. Proof by Induction • How to prove the following?  t: Tab, i: Ind  i t  size(t) > 0 Table: trait introduces new:  Tab add: Tab, Ind, Val  Tab % rest of definition asserts Tab generated by new, add  i, i1: Ind, val: Val, t: Tab % rest of definition

  18. Proof by Induction • How to prove the following? • t: Tab, i: Ind  i t  size(t) > 0 • Basis step:  i: Ind  inew size(new) > 0 • Induction step:  t: Tab, i1: Ind, v1: Val  ( i: Ind  i t  size(t) > 0)  ( i: Ind  iadd(t, i1, v1)  size(add(t, i1, v1)) > 0)

  19. Proof by Induction • How to prove the following? • t: Tab, i: Ind  i t  size(t) > 0 • Basis step:  i: Ind  inew size(new) > 0 • Induction step:  t: Tab, i1: Ind, v1: Val  ( i: Ind  i t  size(t) > 0)  ( i: Ind  iadd(t, i1, v1)  size(add(t, i1, v1)) > 0) Proof? Axiom: (i new) Proof? (i  new); i  add(t, i1, val) == i = i1  i  t; size(new) == 0; size(add(t, i, val)) == if i  t then size(t) else size(t) + 1;

  20. Partitioned by Clause • A complete set of observers for a sort • All distinct values can be distinguished by the observers. • Terms are equal if not distinguishable by the observers. • Provides a deduction rule, i.e., axiom for. • E.g., • Sets are partitioned by  (i.e., no duplicate) S partitioned by

  21. Proof by Deduction  i: Ind  i t1 = i  t2  i: Ind  lookup(t1, i) = lookup(t2, i) t1 = t2 Table1: trait introduces new:  Tab add: Tab, Ind, Val  Tab % rest of definition asserts Tab generated by new, add Tab partitionedby , lookup  i, i1: Ind, val: Val, t: Tab % rest of definition

  22. Example • Can derive theorems that do not follow from the equations alone. • Q: Prove the commutativity of “add” of the same value. • t: Tab, i, j: Ind, v: Val  add(add(t, i, v), j, v) = add(add(t, j, v), i, v)

  23. Exercise • Define “generated by” and “partitioned by” clauses for stacks.

  24. Specifying ADT • Identify a distinguished sort, often called a type of interest or data sort, that denotes the ADT. • Categorize operators • Generators (also called basic constructors) • Produce all the values of the distinguished sort • Observers • Operators with the distinguished (and other) sorts as the domain and some other sort as the range • Extensions • Remaining operators with the distinguished sort as the range • Often have axioms sufficient to concert the observers and extensions. • Usually “partition” the distinguished sort by at least one subset of the observers and extensions.

  25. Good Heuristic for Writing Enough Equations for ADT • Write an equations defining the result of applying each observer and extension to each generator. • Example: Set • Generators*: {} (or ), insert • Observers:  • Extensions: delete *Generators can also be {}, {__}, and .

  26. Exercise • Specify sets by defining the following operators. • Generators: , insert • Observers:  • Extensions: delete

  27. Outline Background LSL basics Equational specifications Stronger theories Other features Modularization: combining traits and renaming Stating intended consequences Recording assumptions Built-in operators and overloading Shorthand notations 27 27 27

  28. Combining Traits • Modularization of trait specifications • Traits can “includes” other traits • “imports” for a conservative extension in older version. • Theory of including trait • Theory associated with its introduces and asserts clauses • Those of its included traits • E.g., can factor out 0, 1, and + from Table. Table: trait includes Integer % defines 0, 1, and + % imports in older version

  29. Example: Equivalence Reflective: trait introduces __  __: T, T  Bool asserts x: T x  x Symmetric: trait introduces __  __: T, T  Bool asserts x, y: T x  y = y  x Transitive: trait introduces __  __: T, T  Bool asserts x, y, z: T x  y  y  z  x  z Equivalence: trait includes Reflective, Symmetric, Transitive EquivalenceExpanded: trait introduces __  __: T, T  Bool asserts x, y, z: T x  x; x  y = y  x; x  y  y  z  x  z

  30. Renaming • Potential problem of including traits • Relies heavily on the use of same names (sorts and operators), e.g., T and . • Thus, often renaming needed • Renaming sorts changes signatures of operators • Can also be done based on positions SparseArray (Val, Arr): trait includesTable (Arr for Tab, defined for, assign for add, __[__] for lookup, Int for Ind) IntegerArray: trait includesSparseArray(Int, IntArr)

  31. Exercise • Extend the set specification to introduce additional operators. (Assume Set(S,E) with operators {}, insert, , and delete.) • Observers: |__|,  • Extensions: delete, {__}, , , - • Define a choose operator, choose: S  E.

  32. Exercise • Write a specification for binary trees by defining the following operators • [__]: E  T • [__, __]: T, T  T • content: T  E • first, second: T  T • isLeaf: T  Bool

  33. Stating Intended Consequences • Redundancy information or checkable claims for • Error detection (e.g., proof obligations) • Confirming reader’s understanding • Providing useful lemmas that will simplify reasoning about specifications

  34. Implies Clause • Make claims about theory containment • Example: In SparseArray, no array with a defined element is empty. implies a: Arr, i: Int defined(i, a) isEmpty(a) SparseArray (Val, Arr): trait includes Table (Arr for Tab, defined for, assign for add, _ _[_ _] for lookup, Int for Ind)

  35. Converts Clause • State completeness of theory • If the interpretation of all other operations are fixed, there is only one interpretation of the listed operations that satisfies the axioms. • I.e., the operations are completely defined. • Example: impliesconverts isEmpty impliesconverts isEmpty, lookup exempting  i: Ind lookup(new, i)

  36. Recording Assumptions • Often traits are suitable for use only in certain contexts. • Such contexts can be explicitly specified as assumptions. • Assumptions impose a proof obligation on the client, and may be presumed within the trait containing them. • Whenever a trait with assumptions is included or assumed, its assumptions must be discharged. • Use the assumes clause.

  37. Example BasicBag (E): trait introduces {}:  B insert: E, B  B % rest of definition Bag (E): trait assumes TotalOrder(E) includes BasicBag(E), Integer introduces rangeCount: E, E, B  Int asserts e1, e2, e3: E, b: B rangeCount(e1, e2, {}) == 0; rangeCount(e1, e2, insert(e3, b)) == rangeCount(e1, e2, b) + (if e1 < e3  e3 < e2 then 1 else 0) implies  e1, e2, e3: E, b: B e1  e2  rangeCount(e3, e1, b)  rangeCount(e3, e2, b) IntegerBag: trait includes Integer, Bag (Int) *TotalOrder defines operators like < and . Q: How does IntegerBag discharge the assumption?

  38. Built-in Operators and Overloading • Built-in operators • Logical connectives • if__then__else__ • = and  • Decimal numbers such as 0, 25, 2013 • … • Operator overloading • User-defined operators • Disambiguating overloaded operators a: S = b % subterm qualified by its sort implies converts <: Str, Str  Boolean %signature

  39. Shorthand: Enumeration • Shorthand notations for enumeration, tuple, and union • Enumeration • A finite ordered set of distinct constants • An operator to enumerate them Temp enumeration of cold, warm, hot introduces cold, warm, hot: Temp succ: Temp  Temp asserts Temp generated by cold, warm, hot equations cold  warm; cold  hot; warm  hot; succ(cold) = warm; succ(warm) = hot

  40. asserts C generated by [__, __] C partitioned by .head, .tail  h, h1: H, t, t1: T ([h, t]).head = h; ([h, t]).tail = t; setHead([h, t], h1) == [h1, t]; setTail([h, t], t1) == [h, t1] introduces [__, __]: H, T  C __.head: C  H __.tail: C  T __.setHead: C, H  C __.setTail: C, T  C Shorthand: Tuple • Introduce fixed-length tuples, similar to records in many programming languages. C tuple of head: H, tail: T

  41. Utag enumeration of atom, cell introduces atom: A  U cell: C  U __.atom: U  A __.cell: U  C tag: U  Utag asserts U generated by atom, cell U partitioned by .atom, .cell, tag  a: A, c: C atom(a).atom == a; cell(c).cell == c; tag(atom(a)) == atom; tag(cell(c)) == cell Shorthand: Union • Tagged unions found in programming languages U union of atom: A, cell: C

  42. Exercise Specify in LSL a software system that automates test taking by allowing an instructor to prepare test questions and students to take tests. The system shall: R1: Maintain a pool of potential test questions that are classified by topics, difficulty levels, and similarity (of questions). Each question is a multiple choice question consisting of a stem---that presents the problem to be solved or the question to be answered---and a set of options---that are possible answers. The system shall allow an instructor to add a new test question to the pool. R2: Allow an instructor to create a test on specific topics by suggesting a set of questions from the pool that meets the instructor's request (e.g., number of questions and their distributions among different topics and difficulty levels). R3: Allow students to take tests prepared by the instructor. R4: Grade tests taken by students to calculate test scores. R5: Allow both the instructor and the students view test scores. However, students are allowed to view only their test scores. 42

More Related