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, ; rdkf1998, ; 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, casesplit, 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 casesplit/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 wellfounded induction (WFI) are incorporated to solve the issue, by declaring a casesplit with exhaustive equations and an induction via a wellfounded relation (futatsugi17, ; futatsugi20, ).
Transition system is the primary modeling scheme for software related dynamic systems. A proof score method making use of CafeOBJ’s builtin search predicates is developed for proving leadsto properties of transition systems (futatsugi15, ). The leadsto 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 selfcontained 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/casestudies 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:^{1}^{1}1This 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 wellfounded 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 (rdkf1998, ; 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 coarity) 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 Builtin Bool and Predicates
CafeOBJ has a builtin 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 builtin equality predicate “pred _=_ : *Cosmos* *Cosmos* > Bool .” with equations “eq (CUX:*Cosmos* = CUX) = true .” and “eq (true = false) = false .”, where *Cosmos* is a builtin sort with [ < *Cosmos*] for any sort .
The builtin 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/commutative equations are implemented with the matching modulo associativity/ commutativity (see 2.6.3).
2.1.5 OrderSorted Signature
An ordersorted 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 ordersorted 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 ordersorted 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 ConstructorBased OrderSorted Signature
A constructorbased ordersorted signature is an ordersorted signature with constructor declarations and is represented by a tuple where is an ordersorted 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 ordersorted signature. An algebra (or an ordersorted 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 ordersorted 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 builtin 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 (rdkf1998, ; 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 builtin 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
subterms 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 builtin equality predicate (2.1.3) and and do not contain the equality predicate _=_ ().
Given a set of conjunctive equations in ordersorted 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 algebramorphism .
2.5.2 The Initial Algebra of
Let be a constructorbased ordersorted 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 constructorbased ordersorted specification. If the specification is sufficiently complete, for any algebra there exists a unique algebramorphism .
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) onestep deduction relation and (ii) its reflexive and transitive closure called deduction relation.
Inference rules for is given as follows for .

.

If , .

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

,

.

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) onestep 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

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.

terminating iff there is no infinite reduction sequence , (i.e., is wellfounded),

confluent (or ChurchRosser) iff
, 
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 builtin 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 onestep 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
Fact 10
(PR1)
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.
@^{2}^{2}2All the CafeOBJ codes explained in
this paper are posted at the following web page:
https://cafeobj.org/~futatsugi/misc/apsco211214/
A footnote on @ shows in which files the following
CafeOBJ code exits.
01:17: is in the file
listappend.cafe
on the Web.
01:  generic collection of objects 02:  mod* TRIV {[Elt]}  TRIV is a builtin 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 builtin 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 builtin 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:).
@^{3}^{3}301:10: is in the file listappend.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 CaseSplit 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 casesplit, and/or an induction. Specification may need some improvements also.
3.3.1 CaseSplit 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
(CaseSplit with Exhaustive Equations)
(PR2)
Casesplit 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.
@^{4}^{4}401:09: is in the file listappend.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.101: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:
,
,
,
,
,
,
,
,
.
@^{5}^{5}501:07: is in the file listappend.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.101: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, casesplit is realized through commands of the proof tree calculus (PTcalc), and induction is realized through wellfounded induction (WFI) on arguments (parameters) tuples of a goal property predicate. As a result, advanced proof scores are (i) succinct and transparent for casesplit, (ii) effective for noninitial and multiargument 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)