DeepAI
Log In Sign Up

Advances of Proof Scores in CafeOBJ

12/20/2021
by   Kokichi Futatsugi, et al.
JAIST
0

Critical flaws continue to exist at the level of domain, requirement, and/or design specification, and specification verification (i.e., to check whether a specification has desirable properties) is still one of the most important challenges in software/system engineering. CafeOBJ is an executable algebraic specification language system and domain/requirement/design engineers can write proof scores for improving quality of specifications by the specification verification. This paper describes advances of the proof scores for the specification verification in CafeOBJ.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

08/26/2019

Introducing H, an institution-based formal specification and verification language

This is a short survey on the development of the formal specification an...
03/06/2018

From SysML/KAOS Domain Models to B System Specifications

In this paper, we use a combination of the SysML/KAOS requirements engin...
07/02/2019

Specifying verified x86 software from scratch

We present a simple framework for specifying and proving facts about the...
08/10/2022

Verification of the busy-forbidden protocol (using an extension of the cones and foci framework)

The busy-forbidden protocol is a new readers-writer lock with no resourc...
01/09/2023

Case studies of development of verified programs with Dafny for accessibility assessment

Formal verification techniques aim at formally proving the correctness o...
03/27/2021

{log}: Applications to Software Specification, Prototyping and Verification

This document shows how Z specifications can be translated into {log} an...
10/28/2020

Specification description and verification of multitask hybrid systems in the OTS/CafeOBJ method

To develop IoT and/or CSP systems, we need consider both continuous data...

1 Introduction

Specification verification is theorem proving where a specification is a set of axioms and desirable properties are theorems. The main goal of a specification verification is not, however, to prove a property holds for the specification but to check the quality of the specification against the property; a specification is supposed to improve via the specification verification. This is quite different from ordinary theorem proving where the set of axioms is fixed and not supposed to change. The improvements of a specification include the addition of necessary axioms, the deletion of unnecessary axioms, and the improvement of the specification’s module structure.

For achieving the improvements, specifications and the machinery of the specification verification are better to be clear and transparent. That is, the followings are better to be clear and precisely defined, and hopefully simple and transparent. (i) Models of a specification (models of a system specified), (ii) inference (deduction, proof) rules used, and (iii) rationale for assumptions used (i.e., why an assumption is justified to be used or not).

CafeOBJ (futatsugiN97, ; rd-kf1998, ; cafesem02, ; cafeobj21, ) is an executable algebraic specification language system based on equational logic and rewriting execution with transparent and precise definition of the models and the inference/execution rules. CafeOBJ’s powerful module system makes it possible to describe the assumption/conclusion relations in a clear and transparent way.

A fully automatic specification verification often fails to convey important structures/properties of the systems specified, and makes it difficult to improve the specification. One should seek to make balanced optimal use of the respective abilities of humans and computers, so that computers do the tedious formal calculations, and humans do the high level planning. Proof scores have been fostered in the OBJ (futatsugiGJM85, ; goguen00iobj, ; goguen06TPA, ; obj3, ), CafeOBJ community, and intend to meet these requirements (futatsugi06, ; futatsugiGO08, ; futatsugi10, ).

A proof score for a specification in CafeOBJ is a piece of code that constructs proof modules and does rewritings/reductions on them with the equations (i.e., axioms) in the specification and the proof modules (futatsugiGo12, ; futatsugi17, ) (see 3, 4 for more details). If all the reductions return the expected results, a proof attempted is achieved. The formal calculations are encapsulated into the reductions with the equations, and the high level planning is encoded into the proof modules and the reduction commands on them.

Major high level planing includes lemma, case-split, and induction. They are supposed to be found by humans and declared as proof modules. Proof modules can be constructed manually with open  close constructs (see 3), and case-split/induction can be described in a liberal way. It involves, however, risks of obscuring the rationale of the high level planning. Proof tree calculus (PTcalc) and well-founded induction (WFI) are incorporated to solve the issue, by declaring a case-split with exhaustive equations and an induction via a well-founded relation (futatsugi17, ; futatsugi20, ).

Transition system is the primary modeling scheme for software related dynamic systems. A proof score method making use of CafeOBJ’s built-in search predicates is developed for proving leads-to properties of transition systems (futatsugi15, ). The leads-to properties cover fairly large part of important properties of dynamic systems, and their proof scores can be built with PTcalc+WFI.

This paper is intended to be a comprehensive and self-contained account on the recent advances of the proof scores in CafeOBJ with a nice harmony of theories and cases. Many papers have been published on CafeOBJ and/or proof scores. Majority of them, however, are on theories/methods or examples/case-studies intensively, and few treat the both in valance and describe how theories justify cases in CafeOBJ in a concrete fashion.

For achieving the intention, (1) theories are described so as to justify cases in CafeOBJ as directly as possible, (2) CafeOBJ’s cases are presented to explain the meaning/intention of theories in concrete ways. As a result, the paper clarifies the following two things in a fairly simple and transparent way, because the logics the CafeOBJ’s proof scores based are the simplest among ones on which other theorem proving systems based. (a) A minimum cohesive collection of theories that makes proof scores work. (b) Typical cases of proof scores in CafeOBJ that are justified by the theories.

The following sections are organized as follows:111This paper is based on futatsugi21 . Section 6 is totally new. All of the other sections are significantly revised and extended. Section 2 describes theories that are necessary for justifying proof scores. Section 3 explains how to construct basic proof scores with open ... close constructs. Section 4 explains how to construct advanced proof scores with proof tree calculus (PTcalc) and well-founded induction (WFI). Section 5 describes theories and methods for constructing proof scores for transition systems. Section 6 demonstrates the constructions of the PTcalc+WFI proof scores for a simple example of transition system. Section 7 discusses related works, distinctive features of the proof scores, and concludes the paper.

2 Fundamental Theories

CafeOBJ supports several kinds of specifications such as equational specifications, rewriting specifications, and behavioral specifications. This paper focuses on equational specifications and transition specifications (a restricted class of rewriting specifications) on which our proof score method has been mainly developed. We will proceed with the following items for CafeOBJ following the style of (rd-kf1998, ; futatsugiGo12, ).

  • a set of signatures.

  • for each signature a class of -models.

  • for each signature a set of -sentences.

  • for each signature a satisfaction relation between -models and -sentences, i.e., .

2.1 Signatures

2.1.1 Sorts

A sort is a name for entities of the same kind/sort/type, and interpreted as the set of the entities. A subsort relation can be declared among sorts and is interpreted as a subset relation. If [s < s’] is declared, it is interpreted as two sets with the subset relation. Some abbreviations like [s1 s2 < s], which stands for [s1 < s] and [s2 < s], are available.

The subsort declarations define the partially ordered set (poset) where is the set of sorts involved and is the minimum partial order relation including the subsort relations declared. Given a poset of sorts, let denote the equivalence relation generated by the partial order . The quotient of by the equivalence relation is denoted as , and an element of is called a connected component.

2.1.2 Operators

An operator (or function) is declared as “op  :  ->  .” where is its arity and is its sort (or co-arity) of the operator. The string is called the rank of the operator. A constant is an operator whose arity is empty (i.e., op  : - .). Let denotes the set of all operators of rank , then the whole collection of operators can be represented as the family of the sets of operators sorted by (or indexed by) ranks as . Note that “op  :  ->  .” iff (if and only if) . Operators can be overloaded, that is the same name can be used for two opertors of different ranks. In other words, and can have a common element for different and .

2.1.3 Built-in Bool and Predicates

CafeOBJ has a built-in module BOOL realizing the Boolean algebra with the sort Bool and the following operator: true, false, not_, _and_, _or_, _xor_, _implies_, _iff_, where _ indicates the position of argument. An operator with the rank Bool is called predicate, which can be declared as “pred  :  .”.

There is an important built-in equality predicate “pred _=_ : *Cosmos* *Cosmos* -> Bool .” with equations “eq (CUX:*Cosmos* = CUX) = true .” and “eq (true = false) = false .”, where *Cosmos* is a built-in sort with [ < *Cosmos*] for any sort .

The built-in module BOOL is used in a significant way as follows.

  • The condition of an equation (see 2.3.1) is a Boolean term.

  • A property of interest on a specification is expressed with the predicates.

2.1.4 Operator Attributes

CafeOBJ supports the following three attributes for a binary operator .

  • associativity {assoc}:

  • commutativity {comm}:

  • identity {id: }:   ( is an identity constant)

Identity equations are implemented with rewrite rules, and associative/com-mutative equations are implemented with the matching modulo associativity/ commutativity (see 2.6.3).

2.1.5 Order-Sorted Signature

An order-sorted signature is defined by a tuple . For making construction of symbolic presentations of models (i.e., term algebras, see 2.2.3) possible, the following sensibility condition is the most general sufficient condition for avoiding ambiguity found until now (meseguer97mel, ). An order-sorted signature is defined to be sensible iff for any operator where means that (i) and are of the same length and (ii) any element of is in the same connected component with corresponding element of . Note that for the empty arity . An order-sorted signature is defined to be regular iff there is a unique least element in the set { } for each and each . The regular signature guarantees that any term has a unique minimum parse ((goguenM92OSA, ; goguen06TPA, )).

Example 1

(i) {[Bool Nat] op 0 : -> Bool . op 0 : ->  Nat .} defines a non sensible signature, and 0 cannot be identified with any entity of any sort.
(ii) { [Zero < Nat EvenInt] op 2 : -> Nat . op 2 : -> EvenInt .} defines a sensible but non regular signature, and 2 is identified with an entity that belongs to Nat and EvenInt but it has no minimum parse.
(iii) { [EvenNat < Nat EvenInt] op 2 : -> EvenNat . op 2 : -> Nat . op 2 : -> EvenInt .} defines a sensible and regular signature, and 2 is identified with the entity that belongs to EvenNat, Nat, and EvenInt with the minimum parse 2:EvenNat.

2.1.6 Constructor-Based Order-Sorted Signature

A constructor-based order-sorted signature is an order-sorted signature with constructor declarations and is represented by a tuple where is an order-sorted signature and is distinguished subfamily of sets of operators, called constructors. An operator or for some subsort of () is called a constructor of sort . A sort is called constrained if there exists a constructor of . Let denote the set of all constrained sorts. An element of is called a loose sort.

2.2 Models

A CafeOBJ’s signature determines the set of models called -algebras.

2.2.1 -Algebras

Let be an order-sorted signature. An -algebra (or an order-sorted algebra of signature ) interprets (i) each sort as a carrier set , (ii) each subsort relation as an inclusion , and (iii) each operator as a function such that any two functions of the same name return the same value if applied to the same argument, i.e., if and and and then .

2.2.2 -Algebra Morphism

Let , be -algebras. An -algebra morphism (or model morphism) is an -sorted family of functions between the carrier sets of and , , such that

  • for all , and for , and

  • if and then .

2.2.3 Terms and Term Algebras

Let be an order-sorted signature, and be an -sorted set of variables called a -variable set.

-term is defined inductively as follows.

  • Each constant is a (X)-term of sort .

  • Each variable is a (X)-term of sort .

  • is a term of sort if is a term of sort and .

  • is a term of sort for each operation and terms of sort for .

The -sorted set of -terms is denoted as . For the -sorted empty sets of variables , a -term is called -term or -ground term. denotes the -sorted set of -ground terms. The can be organized as a -algebra by using the above inductive definition of -terms. as a -algebra is the initial algebra of -algebras as stated as follows.

Fact 1

(goguenM92OSA, ; goguen06TPA, ) For any -algebras there exists a unique -algebra morphism .

2.2.4 Valuations and Term Interpretation

A valuation (or substitution) assigns values to variables, that is, instantiates each variable with a value in a given model. Let be -signature. Given a -model and an -sorted set of variables, a valuation is an -sorted family of maps . Each (X)-term can be interpreted as a value in the model for each valuation in the following inductive manner. That is, can extend to .

  • if is a constant .

  • if is a variable .

  • if is of the form for some and terms of sort .

Note that can be seen as a -algebra morphism by interpreting as a signature with fresh constants .

2.2.5 -Algebras

An -algebra is an -algebra with the carrier sets for the constrained sorts consisting of interpretations of terms formed with constructors and elements of loose sorts. That is, the following holds for . There exists an -sorted sets of loose variables = and a valuation = such that is surjective for each constrained sort (i.e., is a surjection for ).

2.3 Sentences and Specifications

2.3.1 -Equations

A -equation is a main sentence of CafeOBJ and is declared as follows; cq stands for conditional equation.
      cq = if .
is a finite -variable set, and for some sort .

If is true (a built-in constant of the sort Bool) the equation is unconditional and written as follows.
      eq = .

2.3.2 Equational Specifications

An equational specification is defined to be a pair of signature and a set of -equations , and denoted as .

2.3.3 Structured Specifications

A specification SP can be structured by importing other already defined specification like . If then .

It is a casual definition of structured specifications. More formal treatments can be found in (rd-kf1998, ; futatsugiGo12, ).

2.4 Satisfaction

2.4.1 Equation Satisfaction

An equation cq = if .” is satisfied by a -algebra , in symbols , iff whenever for any valuation . That is, an equation is satisfied by an algebra iff all possible ways to assign values to variables evaluate both sides of the equation as the same value whenever the condition is satisfied.

Fact 2

Let _=_ and _implies_ be Boolean operators of the CafeOBJ’s built-in module BOOL, and , .
    (i)  “eq = .  “eq = true .
   (ii)  “cq = if .
          “ = true .

2.4.2 and Loose/Tight Denotoations

The set of models of a specification is defined as . An element of is called an -algebra (or -model).

A specification in CafeOBJ (i.e., a module) can have loose or tight denotation that are indicated by two keywords mod* or mod!, respectively. The loose denotation intends to denote , and the tight denotation intends to denote the initial algebra of assuming its existence.

2.4.3 and Theorem of Constants

A Boolean term , which is supposed to express a property of interest for a specification , is defined to be satisfied by (in symbols ) iff (eq  = true .”).

Let be a specification, and be disjoint -variable sets, be a signature obtained by adding to as fresh constants. Let , and obtained from by considering each as a fresh constant. Let be a -algebra, be a valuation, then there is a one to one correspondence between a pair A and a -algebra . Hence the following Fact 3 that extends the original one in Theorem 3.3.11 of (goguen06TPA, ) and will be used to obtain Facts 12, 14.

Fact 3

(Theorem of Constants)
           

Fact 4

Let , , and be the term gotten by substituting non overlapping proper sub-terms of with variables in .
             (i)
             (ii) 
            (iii) 
            (iv) 

2.5 Initial Algebras

A congruence on an -algebra is an -sorted equivalence on (i.e., ) such that (i) if () then for each , and (ii) if () and then iff .

An equation “cq = if .” is called conjunctive if is true or “( = ) and and ( = )” () where _=_ is the built-in equality predicate (2.1.3) and and do not contain the equality predicate _=_ ().

Given a set of conjunctive equations in order-sorted signature , then the algebra is constructed as follows:

  • for each let be the set of equivalence classes of -terms in under the congruence defined as ( iff ). That is, .

  • each operation is interpreted as
          
    for all () by using the congruence property of on .

2.5.1 The Initial Algebra of

Fact 5

(goguenM92OSA, ; goguen06TPA, ) Let , with no constructors. For any algebra there exists a unique -algebra-morphism .

2.5.2 The Initial Algebra of

Let be a constructor-based order-sorted specification and be the set of constrained sorts and be the set of loose sorts (2.1.6), and , and , and , and be any sorted set of variables. A specification is defined to be sufficiently complete if for any term there exits a term such that .

Fact 6

(gainaF15, ) Let be a constructor-based order-sorted specification. If the specification is sufficiently complete, for any algebra there exists a unique -algebra-morphism .

2.6 Deduction, Reduction, CafeOBJ Execution

Let , be an equational specification. Let be a special fresh constant of a sort , be a ground term composed of operators in with one , and be the -term obtained by substituting with a term . The term is called an -term (or a context). Let (i.e., a Boolean ground -term).

2.6.1 Equational Deduction

A specification defines (i) one-step deduction relation and (ii) its reflexive and transitive closure called deduction relation.

Inference rules for is given as follows for .

  1. .

  2. If , .

  3. For an equation “cq  =  if  .” , a valuation , and an -term ,

    1. ,

    2. .

Let denote .

Fact 7

(goguen06TPA, )                              

2.6.2 Rewriting Reduction

For a term let var()  denote the set of variables in . An equation “cq  =  if  .” with var()  var()  var() is called a rewrite rule. If each equation is a rewrite rule, is called a reduction specification (or term rewriting system (TRS)) and defines (i) one-step reduction relation and (ii) its reflexive and transitive closure , called reduction relation.

Inference rules for is the same as for in 2.6.1 by replacing with and with except for the rule (c2) because rewriting is only from left to right direction.

Let denote .

Fact 8

A TRS is defined to be

  1. operationally terminating LucasMM05 iff there is no infinite applications of the rules (a),(b),(c1) to the left most open goal (i.e., unproven or ). That is, if the rules (a),(b),(c1) always apply to the left most open goal, a proof succeeds or fails in finite steps.

  2. terminating iff there is no infinite reduction sequence , (i.e., is well-founded),

  3. confluent (or Church-Rosser) iff
    ,

  4. sufficiently complete iff for and in 2.5.2 and being considered to be the set of fresh constants.

Example 2

If a TRS has only an equation “cq b = true if b .” for a Boolean constant b, the system is terminating because (i) the built-in module BOOL without b is terminating, and (ii) b does not hold for any .

The system is, however, not operationally terminating because infinite applications of the rules to the left most open goal happen as follows:
   (b true) (b)
   (b true true true) (c1)
   (b true true true) .

2.6.3 CafeOBJ Execution

For a CafeOBJ specification (i.e., a module) , each equation in without :nonexec attribute (see Example 3) is a rewrite rule and SP is a reduction specification (or TRS). A reduction command “reduce in  :  .” for a ground term computes using the inference rules (a),(b),(c1) of 2.6.2.

More precisely, if the reduction command terminates, it returns a term such that (i) and (ii) there is no term such that except a term gotten by one-step reduction with AC (or associative/commutative) equations (see 2.1.4). It is because AC equations are not used as rewrite rules (note that an AC equation for comm attribute causes infinite reductions). Instead, the AC equality is implemented as the matching modulo AC equations for deciding equality of terms (i.e., whether holds or not) in applying inference rules (a),(b),(c1). For example, matching with a subterm of for deciding in applying the inference rule (c1). is called a reduced (or normal) form of modulo AC.

Example 3

An equation with :nonexec attribute, which is not used for the application of the rule (c1), can be declared like
      cq [:nonexec]: X = Z if (X = Y and Y = Z) .
where X,Y,Z are variables of some sort. This equation is valid because of transitivity of equality, but is not a rewrite rule because [var(Z)  var((X = Y and Y = Z)) var(X)] does not hold. This equation can become a rewrite rule by instantiating its variables with ground terms.

Let denote that “reduce in : .” returnes true.

Fact 9

The following is obtained via Facts 7, 8, 9.

Fact 10

(PR1)     

Note that the above Facts 9, 10 hold even if has not the initial model, or is not operationally terminating, terminating, confluent, or sufficiently complete.

3 Basic Proof Scores

Basic techniques for constructing specifications and proof scores are presented, and justified by the facts shown in 2.

3.1 Specifying Systems

The following CafeOBJ code 01:-12:(i.e., a piece of text in CafeOBJ code) specify a generic list data structure. Numbers in 1st to 3rd columns like 01:, 10: are for explanation, and CafeOBJ code starts from the 7th column. CafeOBJ code starting -- or --> followed by a blank, like in 01: or 08:, is a comment until the end of a line. A comment with “-- ” or “--> ” can start at any point of a line.

@222All the CafeOBJ codes explained in this paper are posted at the following web page:
       https://cafeobj.org/~futatsugi/misc/apsco-211214/
A footnote on @ shows in which files the following CafeOBJ code exits. 01:-17: is in the file list-append.cafe on the Web.

01:   -- generic collection of objects
02:   -- mod* TRIV {[Elt]} -- TRIV is a built-in module

03:   --> generic list
04:   mod! LIST (X :: TRIV) {
05:   [NnList < List]
06:   op nil : -> List {constr} .
07:   op _|_ : Elt List -> NnList {constr} . }

08:   --> generic list with enhanced _=_
09:   mod! LIST= (X :: TRIV) {
10:   pr(LIST(X))
11:   eq (nil = E:Elt | L:List) = false .
12:   eq (E:Elt | L1:List = E | L2:List) = (L1 = L2) . }

The key word mod* (02:) declares, with loose denotation (2.4.2), a module with name TRIV and its body {[Elt]} that just declares the sort (2.1.1) Elt with no constrains. The key word mod! (04:) declares, with tight denotation (2.4.2), a module with name LIST, its parameter list (...) (04:), and its body {...} (04:-07:). The parameter list (X :: TRIV) declares that this module has a parameter module X, and that can be replaced by a module that satisfies the module TRIV. The body declares, (i) two sorts NnList and List with the former being a subsort (2.1.1) of the latter (05:), (ii) constructor operator (2.1.6) nil with rank (2.1.6) List (06:) and constructor operator _|_ with rank Elt List NnList (07:).

The module LIST= declares two equations 11:-12: for enhancing the built-in equality _=_ on the sort List. pr(LIST(X)) declares that the module (LIST(X)) is imported in protecting mode, i.e., with no changes on its models.

Because the module LIST has the tight denotation and its model is the initial algebra of (2.4.2), the equality of the initial model does not change with the addition of the two equations. It is sometimes necessary to add equations to refine the definition of the equality on the initial algebra, for only one equation: “eq (L:List = L) = true .” is built-in originally.

The following module APPEND (14:-18:) specifies the append operator _#_ of rank List List List with the two equations app1 and app2.

13:   --> append operation _#_ on List
14:   mod! APPEND (X :: TRIV, Y :: LIST(X)) {
15:   op _#_ : List List -> List .
16:   eq[app1]: nil # L2:List = L2 .
17:   eq[app2]: (E:Elt | L1:List) # L2:List = E | (L1 # L2) . }

The parameter declaration (X :: TRIV,Y :: LIST(X)) (01:) includes the 2nd parameter Y :: LIST(X) and also indicates that the module LIST(X) is imported in protecting mode. The 2nd parameter is prepared for instantiating it with a more elaborated module LIST=(X). That is, we need
      APPEND(X,LIST=(X)) instead of APPEND(X,LIST(X))
in some occasion (see 3.2 10:07:02:).

3.2 Specifying Properties of Interest

Assume that we want to construct a proof score for proving that the operator _#_ of the module APPEND is associative. For expressing the proof goal, the following module APPENDassoc (01:) defines the predicate appendAssoc and the module APPENDassoc@ (06:) introducing the three fresh constants l1@,l2@,l3@ of the sort List (08:).

@33301:-10: is in the file list-append.cafe on the Web.

01:   mod APPENDassoc (X :: TRIV,Y :: LIST(X)) {
02:   ex(APPEND(X,Y))
03:   pred appendAssoc : List List List .
04:   eq appendAssoc(L1:List,L2:List,L3:List) =
05:      ((L1 # L2) # L3 = L1 # (L2 # L3)) .     }

06:   mod APPENDassoc@(X :: TRIV,Y :: LIST(X)){
07:   ex(APPENDassoc(X,Y))
08:   ops l1@ l2@ l3@ : -> List . }

09:   mod APPENDassoc@= (X :: TRIV) {
10:   pr(APPENDassoc@(X,LIST=(X)))  }

The keyword mod (01:,06:,09:) indicates no specific intention of the loose or tight denotation of the module. The declaration ex(...) (02:,07:) indicates the importation of a module in extending mode. That is, no change except the addition of new elements like l1@,l2@,l3@, appendAssoc(...). The module APPENDassoc@= is using the module LIST= instead of LIST.

The associativity of the operator _#_ is formalized as
      
and by Fact 10
      
is sufficient for the proof. However, the CafeOBJ reduction:
      red in APPENDassoc@= : appendAssoc(l1@,l2@,l3@) .
does not return true where red is the abbreviation of reduce.

3.3 Case-Split and Induction

Let be a module (a specification) in CafeOBJ. If does not hold, the universal strategy for proving is making use of a lemma (including for discharging a contradictory case), a case-split, and/or an induction. Specification may need some improvements also.

3.3.1 Case-Split with Exhaustive Equations

-equations are defined to be exhaustive for iff
                   .

Let where is the set of newly introduced fresh -constants in , then and the following proof rule Fact 11-(PR2) is obtained.

Fact 11

(Case-Split with Exhaustive Equations)
(PR2)             

Case-split in CafeOBJ is based on (PR2). Because the sort List is constrained (2.1.6) with the two constructors nil and _|_, two equations “eq[e1]: l1@ = nil .”, “eq[e2]: l1@ = e$| l1$.” with fresh constants e$, l1$ are exhaustive for the module APPENDassoc@= (see 2.2.5). Let and then holds by (PR2), and following CafeOBJ code 01:-08: can serve to check whether holds, 01:-04: for +e1 and 05:-09: for +e2.

@44401:-09: is in the file list-append.cafe on the Web.

01:   open APPENDassoc@= .
02:   eq l1@ = nil .
03:   red appendAssoc(l1@,l2@,l3@) .
04:   close

05:   open APPENDassoc@= .
06:   op e$ : -> Elt . op l1$ : -> List .
07:   eq l1@ = e$ | l1$ .
08:   red appendAssoc(l1@,l2@,l3@) .
09:   close

The “open .” command creates a new tentative module where all the ’s contents are imported, new sorts/operators/equations can be declared, and reduce commands can be executed. red is a shorthand for reduce, and if is opened, “red .” stands for “red in : .” where the module includes ’s contents plus the contents delcared in the opened tentative module before the red command. The command close deletes the created module.

If the red commands 03: and 08: return true, is proved, and by Fact 10-(PR1) is proved. 03: returns true but 08: does not, and induction should be necessary.

3.3.2 Structural Induction

The standard way of induction for algebraic specifications is structural induction (burstall69, ) formulated as follows (Theorem 6.5.9 and its Corollary of (goguen06TPA, )).

Let , and be a Boolean term with finite variables that describes a property of interest for a module (specification) . The induction should be applied to a varialble of a constrained sort (2.1.6), and assume that the sort of is and is a constrained sort (i.e., ) without loss of generality. Let be the set of constructors for the sort (see 2.1.6), i.e., is the sorted sets . The principle of structural induction is formulated as follows, where (i) is a fresh constant of the sort , (ii) means  “eq  = true .” for the initial model .

By and Fact 4-(iv), in the premise can be rewritten as follows.

Let be a fresh constant for the variable , and . By applying Fact 3 to the above the following is obtained.

Fact 12

(Structural Induction)

3.3.1-01:-04: is a proof score for the premise’s 1st conjunct of Fact 12. The following 01:-07: is a proof score for the premise’s 2nd conjunct of Fact 12 with the following correspondences:
      , , , ,
      , , ,
      , .

@55501:-07: is in the file list-append.cafe on the Web.

01:   open APPENDassoc@= .
02:   op e$ : -> Elt . op l1$ : -> List .
03:   eq l1@ = e$ | l1$ .
04:   eq ((l1$ # L2:List) # L3:List =
05:        l1$ # (L2:List # L3:List)) = true .
06:   red appendAssoc(l1@,l2@,l3@) .
07:   close

The left hand side of the equation 04:-05: is the reduced form of
      appendAssoc(l1$,l2@,l3@),
because left hand sides should be reduced for being effective as reduction rules. The red command 06: returns true and the proof score (3.3.1-01:-04:)+01:- 07: is effective for proving
      .
A proof score is called effective if the score constructs an effective proof tree (see 4.1).

Because the structural induction of Fact 12 is used,
      
is proved but not
      ,
and the latter implies the former but not vice versa.

4 Advanced Proof Scores

In advanced proof scores, case-split is realized through commands of the proof tree calculus (PTcalc), and induction is realized through well-founded induction (WFI) on arguments (parameters) tuples of a goal property predicate. As a result, advanced proof scores are (i) succinct and transparent for case-split, (ii) effective for non-initial and multi-argument induction.

4.1 Proof Tree Calculus (PTcalc) ptcalc21

PTcalc is a refined version of a CafeOBJ version of CITP (gainaZCA13, ), and helps to prove for a module .

We already have the following proof rule (Fact 10).
         (PR1)