3.4 Deduction and Evaluation: Tools Conditional-Equational Logic

Transcription

1 3.4 Deduction and Evaluation: Tools Conditional-Equational Logic The general definition of a formal specification from above was based on the existence of a precisely defined semantics for the syntax of a specification language. At this point, it should be clear that algebraic specifications fulfil this criterion: The semantic domain is constituted by heterogeneous algebras, and it can be defined precisely which of these algebras are accepted as models for a given by a specification (those which are of the right signature, fulfil the import constraints and in which all axioms are valid). However, similar to the notion of a formal system in mathematical logic, the most interesting use of a formal specification is when some transformations are applied on the syntactic documents that can be proven to preserve the semantics. This is the core idea of most support tools for algebraic specifications. The following diagram depicts the general approach where a fixed specification is assumed (and therefore the models are fixed as well). In the framework of algebraic specifications, any term is given a value in a model by the interpretation of the term. What are now allowed syntactic transformations such that the semantic value of the term remains unchanged? Syntax Term 1 Term 2 Semantics Value The following (shortened) example dialog with the CafeOBJ system shows that the tool support of this system is based on the idea from above. Input is shown boldface. % unix> cafeobj -- loading standard prelude -- CafeOBJ system Version 1.3.1(Roman) -- CafeOBJ> input vector.mod -- processing input : /home/hh14/cafeexs/vector.mod File: fss3 Page: 39

2 -- defining module DATA. done. -- defining module VECTOR. done. -- defining module NATVECTOR. done. CafeOBJ> select NATVECTOR NATVECTOR> reduce size(addelement(addelement(initvector,1),2)). 2 : Nat NATVECTOR> This means that the system tried to provide another term (2) for a given term (size(addelement(addelement(initvector,1),2))). The semantics are identical in each chosen model, but the simpler term is much easier to understand and is a commonly accepted normal form for natural numbers. A formally based transformation of syntactic units makes it possible to "lift" many questions about the semantics of the specification from the level of models to a level of syntactic transformation of terms. In the CafeOBJ tool and similar tools, the specification itself is used to provide answers for questions about its meaning. This can also be seen as a very early step of prototyping (logical prototyping). Equational logic is the calculus of replacing terms by equal terms. It can be easily extended to conditional equations. This calculus derives (proves) a term equation from a conditional-equational axiom set. The deduction rules in this calculus are: Reflexivity: Any term is provably equal to itself (t = t). Transitivity: If t1 is provably equal to t2 and t2 is provably equal to t3, then t1 is provably equal to t3. Symmetry: If t1 is provably equal to t2, then t2 is provably equal to t1. Congruence: If t1 is provably equal to t2, then any two terms are provably equal which consist of some context built around t1 and t2. (More formally: Take an arbitrary term t and choose a subterm of it. The two terms obtained by replacing the term with t1 and t2, respectively, are provably equal.) Axiom: Let l = r if c be an axiom of the axiom set. For any substitution of terms for the variables in l, r and c (giving terms l, c and r ), the terms l and r are provably equal if the condition c is provably equal to true. These rules provide a way how one can establish new equations based on the axiom set of a conditional-equational axiomatic specification. File: fss3 Page: 40

3 Sometimes the notation S - t1 = t2 is used to denote the fact that the terms t1 and t2 are provably equal based on the axioms of a specification S. Please note that the rules of the calculus are based on a purely syntactic transformation, which can in principle be executed by a computer. The obvious question is how the "provable equality" corresponds to the equality of terms induced by the semantic construction of heterogeneous algebras (models). For this purpose, the notion of "validity" from above is helpful. Of course, for a given specification all axioms are valid in all models (that is the definition of the model). But there are many other equations which are valid in all models of a given specification. So we slightly extend the notion of validity. Definition For a given specification S, an equation "t1 = t2" is valid in S iff for all models M of S and for all environments e in M holds: I M (t1, e) = I M (t1, e). Sometimes the notion S = t1 = t2 is used to denote that fact that an equation is valid in a specification (i.e. in all its models). The classical relationships between calculus-based and semantics-based facts are soundness and completeness. Definition A calculus is sound for some kind of axiomatic specifications and some kind of semantics iff all provable formulae in a specification are also valid in the specification. In the case of conditional-equational algebraic specifications discussed here, the only relevant formulae are equations. Definition A calculus is complete for some kind of axiomatic specifications and some kind of semantics iff all valid formulae in a specification are also provable in the specification. In the case of conditional-equational algebraic specifications discussed here, the only relevant formulae are equations. The most important result in our context is the following: Theorem Conditional-equational logic is sound and complete for the (loose) model semantics introduced above. The proof is relatively trivial for soundness. For completeness, it relies on the construction of a special term model which uses terms as elements of its carrier sets and is based on the deduction calculus. File: fss3 Page: 41

4 3.4.2 Term Rewriting It has turned out that many useful specifications can be written in a style in which the axioms are always applied from left to right. This usage of the axioms in (conditional-)equational logic is called (conditional) term rewriting. Definition A rewriting step for a term t and an axiom l = r if c is carried out as follows: A matching substitution is determined such that the substituted term l is a subterm of t. The condition c is tested whether c can be reduced to true. If this is the case, the rewritten term is t, where the matching subterm is replaced by r. A reduction for a term is a sequence of consecutive rewrite steps. A term is in normal form if no further rewrite steps are possible. Examples: see lecture. Term rewriting is an algorithmic version of the conditional-equational calculus: The two terms of an equation are reduced to normal form. If the normal forms are literally equal, the equation of the original terms has been derived from the axiom set. Term rewriting is by definition sound for our semantics (since it is a special case of conditional-equational logic) and under special conditions it is also complete. Definition A system of term rewriting rules is confluent if the following diamond condition holds: Whenever a term t can be reduced to two terms t1 and t2, then t1 and t2 can both be further reduced to some term t3. A system of term rewriting rules is terminating if all reductions starting from a term are finite (i.e. end in a normal form). For confluent and terminating axiom systems, the term rewriting algorithm is a decision procedure for conditional-equational logic. This means that if the axioms of an algebraic specification form a confluent and terminating term rewriting system, then term rewriting is sound and complete wrt. our (loose) semantics. The axioms of the VECTOR example are confluent since there are no overlaps between rewrite rules. This is in general a sufficient condition for confluence that is also easy to check. Moreover, they are terminating, which is easy to see intuitively, but difficult to prove formally. File: fss3 Page: 42

5 (However, the theory of term rewriting provides a number of powerful tools that are able to fully automatically prove termination in many cases.) The CafeOBJ system supports term rewriting (but unfortunately no checks of criteria for confluence and/or termination) 1. The system has a line-oriented user interface which supports, among many others, the following commands: input <file> Read a file containing specifications and/or commands (i.e. a script file in the latter case). select <spec> Interpret all following commands in the context of the given specification. reduce <term> Reduce a term to normal form. let <variable> = <term> Define an abbreviation for a term. match it to <pattern> Check whether the result of the last evaluation is of a specific form. Many additional features of the system help in debugging, e.g. a trace mode for term rewriting and an interactive stepper mode. These commands can be used interactively, but also for writing scripts which are interpreted by the system line by line. A useful script giving some more confidence in the VECTOR specification is the following: input vector.mod select NATVECTOR let v0 = initvector. let v1 = addelement(initvector,0). let v2 = addelement(v1,1). let v3 = addelement(v2,2). let v4 = addelement(v3,3). reduce v4. reduce isempty(v0). match it to true. reduce isempty(v4). match it to false. reduce size(v4). match it to 4. reduce contains(v1,4). match it to false. reduce contains(v4,1). match it to true. 1 There exist systems incorporating powerful tests for constructor-completeness, confluence and termination, including an implementation done by the author of these notes. Unfortunately, there is currently no single stable software system incorporating the full state of the art of tool support for algebraic specifications. File: fss3 Page: 43

6 reduce firstelement(v4). match it to 0. reduce firstelement(v0). --> error case reduce lastelement(v4). match it to 3. reduce elementat(v4,2). match it to 2. reduce indexof(v4,2). match it to 2. reduce insertelementat(v4,100,2). match it to addelement(addelement(addelement(addelement (addelement(initvector,0),1),100),2),3). Note: The sign --> is a special form of a comment which makes the text following the > appear in the output of the system. The system output for this script is (after removal of some noise): reduce v4 addelement(addelement(addelement(addelement( initvector,0),1),2),3) : Vector reduce isempty(v0). true : Bool match it to true. reduce isempty(v4). false : Bool match it to false. reduce size(v4). 4 : Nat match it to 4. reduce contains(v1,4). false : Bool match it to false. reduce contains(v4,1). true : Bool match it to true. reduce firstelement(v4). 0 : Nat match it to 0. reduce firstelement(v0). firstelement(initvector) : Nat --> error case reduce lastelement(v4). 3 : Nat match it to 3. reduce elementat(v4,2). 2 : Nat match it to 2. reduce indexof(v4,2). File: fss3 Page: 44

7 2 : Nat match it to 2. reduce insertelementat(v4,100,2). addelement(addelement(addelement(addelement (addelement(initvector,0),1),100),2),3). match it to addelement(addelement(addelement(addelement (addelement(initvector,0),1),100),2),3). The style of the script and the features offered by the interpreter are very similar to software testing environments. However, here we are testing specifications Term Models By reducing terms, we have somehow constructed a prototype, i.e. a model of the specification. This is a software realisation of a technique that is frequently used in mathematical logic: the construction of a term model. In a term model, sets of terms are used as the carrier sets and term manipulations like reduction to normal form are taken to define the operations. A very important consequence of the term model construction is a method to prove consistency. In an algebraic specification approach, consistency can be easily defined as follows. Definition An algebraic specification is consistent if there is at least one model for the specification. Consistency is difficult to test for arbitrary axiomatic theories, as is known from mathematical logic. Nevertheless, there exist systematic ways to write a specification which ensure consistency or make consistency decidable. Theorem Every basic specification the axioms of which form a confluent and terminating term rewriting system is consistent. For specifications with extending or protecting import, additional conditions are necessary. For the no confusion principle (required by extending import), it is a sufficient condition that the left hand sides of all axioms contain at least one operation symbol which is not in the imported signature. For the no junk principle (required by protecting import), it has to be ensured that for any term of imported sort its normal form is completely in the imported signature. The error completion File: fss3 Page: 45

8 techniques explained above always give axiom sets with this property. Another interesting observation on term models is that it is easy, and also natural, to construct a term model in which the terms in the carrier sets are variable-free. Terms without variables are often called ground terms, and therefore such a model is called a ground term model. In the ground term model, equations are valid which are not valid in the non-ground term model. The ground term model of a conditional-equational specification is unique, it is often also called the initial model. In many algebraic specification languages, the semantics of a specification is defined by this single model. 2 Example The terms firstelement(v) and elementat(v,0) are interpreted differently in the non-ground model (consider the assignment of value v to the variable v). In the ground term model, these terms are interpreted identically, since the only possible assignments for v are ground terms of sort Vector. Definition A model A of a specification S is term-generated if any element of its carrier sets is the interpretation of a ground term of S. All practically relevant models are term-generated. A complete calculus for this model class involves induction principles (and therefore does not conform to the meaning of a formal system in mathematical logic) Constructor-Completeness When considering the specification VECTOR, it is pretty clear that the term model uses only a subset of the signature for its carriers. Results of term reductions are always built either from primitive data values or from the Vector operations initvector or addelement. Therefore, these two 2 In CafeOBJ, this tight semantics can be indicated by writing module! instead of just module. 3 For readers interested in mathematical logic: Please note that it is possible to specify natural numbers in algebraic specifications with term-generated models. Therefore, Goedel s incompleteness result implies that there cannot be a complete formal calculus for this specification. File: fss3 Page: 46

9 algebraic operations are called constructor operations for Vector (in slight contradiction to the terminology used in object-oriented programming). Definition A specification is constructor-complete wrt. a subset of constructor operations of its signature, if each ground term over the full signature either is intended to be undefined or can be reduced to a ground term in the constructor signature. The completeness of a set of axioms wrt. a set of constructor operations can be guaranteed by syntactic conditions. The basic idea is that all axioms have to be of the form f(c 1,, c n ) = r where f is a nonconstructor operation and all c i are constructor terms. Under this condition, the set of constructor arguments provided for each nonconstructor operation f has to form a complete case analysis over constructor terms. The implicit error completion discussed above always ensures constructor-completeness, whereas explicit error specification makes it necessary to check the completeness of the case analyses. There are straightforward algorithms for this check. File: fss3 Page: 47