Pointfree expression and calculation: from quantification to temporal ...

Form Methods Syst Des (2010) 37: 95–140 DOI 10.1007/s10703-010-0100-2

Pointfree expression and calculation: from quantification to temporal logic Raymond Boute

Published online: 20 October 2010 © Springer Science+Business Media, LLC 2010

Abstract Pointfree formulation means suppressing domain variables to focus on higherlevel objects (functions, relations). Advantages are algebraic-style calculation and abstraction as formal logics pursue by axiomatization.  Various specific uses are considered, starting with quantification in the wider sense (∀, ∃, , etc.). Pointfree style is achieved by suitable functionals that prove superior to pointwise conventions such as the Eindhoven notation. Pointwise calculations from the literature are reworked in pointfree form. The second use considered is in describing systems, with generic functionals capturing signal flow patterns. An illustration is the mathematics behind a neat magician’s trick, whose implementation allows comparing the pointfree style in Funmath, LabVIEW, TLA+ , Haskell and Maple. The third use is making temporal logic calculational, with a simple generic Functional Temporal Calculus (FTC) for unification. Specific temporal logics are then captured via endosemantic functions. The example is TLA+ . Calculation is illustrated by deriving various theorems, most related to liveness issues, and discovering results by calculation rather than proving them afterwards. To conclude, various ramifications, style and abstraction issues are discussed, in relation to engineering mathematics in general and to categorical formulations. Keywords Concrete category theory · Generic functionals · Pointfree style · Pointwise style · Predicate calculus · Quantifiers · Signal flow · Temporal logic · TLA · Transform methods

1 Introduction and overview The topic of interest is the wide potential of the pointfree style, thereby also providing the larger framework for some earlier results on calculational temporal logic presented at FM 2009 [28] and in the third part of this paper. R. Boute () INTEC, Universiteit Gent, Sint-Pietersnieuwstraat 41, 9000 Gent, Belgium e-mail: [email protected]

96

Form Methods Syst Des (2010) 37: 95–140

1.1 Pointfree expression and calculation 1.1.1 Principle Pointfree formulation means suppressing low-level domain variables (referring to points in the function domain) and retaining only higher level objects such as functions and relations. A pair of simple examples conveys the flavor: the function square can be defined – in pointwise form by square x = x · x; – in pointfree form by square = mul ◦ dup. The domain variable in the pointwise form is x. In the pointfree form, mul is multiplication (on pairs), dup duplicates its argument to form a pair, and ◦ is function composition. A calculation example showing equality starts from the pointfree form, adding a dummy x: square x = (mul ◦ dup) x = mul(dup x) = mul(x, x) = x · x.

(1)

1.1.2 Usage Pointfree formulation is far from new. In functional analysis, it appears frequently but not always systematically. In formal mathematics, lambda terms are the archetype of the pointwise style, and combinator terms of the pointfree style [9]. A pointfree formulation of set theory is presented in [77]. These settings are mostly theoretical. Deliberate use of pointfree formulations in practical settings is more recent. A typical application area is relational calculation, e.g., in the context of algebra of programming [1, 13, 69], and programming language semantics [25, 66]. In functional programming as well, pointfree formulation is often an objective, either characteristic for the language as in APL [55] and Backus’s FP [6], or as a matter of style as in Haskell [14]. It is also very useful in functional declarative formalisms unifying engineering mathematics [23, 24]. 1.1.3 Advantages The advantages of pointfree formulation reside in the algebraic style of expression and calculation, which is more compact and arguably more elegant and clearer due to the absence of (distracting) dummies. By the same token, it supports a higher level of abstraction, allowing to focus on the objects of interest, i.e., sets, functions, relations and so on. As a result, it can achieve the same abstract style of expression that is pursued in formal logics by pure axiomatization, as will be demonstrated later for temporal logic. The difference with the pointwise style has also been likened to the use of transform methods [69]. Apart from these conceptual advantages, the pointfree style has considerable potential in lowering the threshold for practicing formal methods, as discussed in more detail next. 1.2 Potential of the pointfree style in lowering the threshold for formal methods 1.2.1 Diversity versus disparity In [2] and a companion tutorial “Why formal verification remains on the fringes of commercial development”, Arvind stresses that no single model, technique or tool can cover all needs of systems design. Diversity is an evident fact conceptually, but accepting it is hampered by needless disparity in the formulation of models and methods in the literature

Form Methods Syst Des (2010) 37: 95–140

97

and the presentation (notation, paradigm) of tools. Even the underlying theories are often stated as special logics, outside the mainstream of mathematics, and miss the directness and elegance engineers appreciate in algebra and calculus [70]. The more mature fields yield diversity in modeling (e.g., electrical, mechanical) without disparity. In formal methods, mathematics is the most powerful intellectual tool, so “hiding the math” is not as helpful as is often suggested. Habrias et al. rightly warn that use of automated tools without awareness is the ruin of formal specification [48]. In analysis, pitfalls are notorious [79]. Since software is discrete, one might think the pitfalls are less subtle, but even simple programs can be hard to get right, as shown by Bentley’s notes on binary search [11]. Also, “hiding the math” deprives tool users of major opportunities, especially in reasoning about systems requirements and realizations (e.g., programs). For instance, the link between informal and formal description, traditionally the weak one, can be made strong by formalizing various informal views and formally exploring relationships [26]. Even variety in notation can be inspiring if captured by a unifying framework [24] for reasoning (relating, comparing). Again diversity is an asset, which mathematics can offer without disparity. 1.2.2 Improving accessibility for practicians Given the preceding remarks, wide use of formal methods in industry is best served by a constant supply of well-prepared students [26]. Yet, this is still a long-term option, since curriculum design lags behind insights in formal methods [80]. Meanwhile one should work at lowering the threshold formal methods still present in practice, but without sacrificing the safety and effectiveness that only mathematics can provide for users of automated tools. So, rather than “hiding the math”, we aim at making it very accessible. Reconciling this goal with the need for diversity is possible by unifying theories. For programming theories, one unifying approach is due to Hoare and Jifeng [52]. The calculational semantics approach [25] is arguably more accessible as its style is akin to common engineering mathematics and its scope is wider. The main unifying element is a functional predicate calculus [24], allowing engineers to calculate with predicates and quantifiers (∀, ∃) as fluently as taught with derivatives and integrals. As expected, reasoning is calculational, the style also advocated by Dijkstra [37], Gries [46, 47] and others. The other element, generic functionals [23], supports unification with classical signals and systems modeling, together with the pointfree style so convenient in computing science [1, 23, 69]. Of this rather wide program, in this paper we focus on a few specific topics. 1.2.3 Lever: balanced use of the pointfree style In the aforementioned work, we have found that the pointfree style can provide significant leverage in making formal methods more accessible by advancing simplicity and clarity in expression and reasoning. A word of caution is needed, however. APL is a well-known language supporting the pointfree style for arrays, but has a reputation of being too terse because of its famous one-line programs, and even cryptic because programs are not understandable at a glance to the uninitiated. However, these criticisms implicitly assume that the program reader is already familiar with classical pointwise formulations in mathematics and imperative programming languages: arguably, pointwise expressions and imperative programs would seem equally abstruse as APL to the uninitiated. Familiarization is always a prerequisite, and constitutes an investment, as the Dutch saying “oefening baart kunst” (“exercise begets art”) implies. Even so, we found formalisms that exclusively support the pointfree style lacking in expressiveness, flexibility and also clarity.

98

Form Methods Syst Des (2010) 37: 95–140

First, even pointfree formalisms often use (meta)variables in their axioms. For instance, the basic combinator terms [9] K and S are defined by KP Q = P and SP QR = P R(QR) where P , Q and R are (meta)variables standing for arbitrary combinator terms. In reasoning about combinator terms as well, dummies may be needed to make the axioms or derived rules applicable. For instance, calculating the “effect” of SK requires two dummies to start (since the axiom for S involves three arguments), leading to the calculation SKQR = KR(QR) = R (recall in passing that this makes I := SKK an identity combinator). Even for pointfree formulations where the axioms do not involve (meta)variables, relating them to pointwise formulations requires dummies, such as x in the calculation (1). Second, in some cases using variables may enhance clarity. The data flow in an expression containing function operators can in principle be captured by basic combinators, but the result rapidly becomes complex. Examples are provided by converting certain simplelooking lambda terms into combinator terms; for instance, the combinator term obtained from λxyz.yzx is S(K(SS))(S(KK)K). Ad hoc combinators can capture arbitrary patterns, but that is beside the point. Of course, practical calculi do not look like combinator calculus, but qualitatively the latter illustrates many similar phenomena. An example in more practical settings is the following. The dot product (sometimes also called inner product or scalar product) a • b of two number sequences a and b of length n is defined in common pointwise mathematical notation by a•b =

n−1 

a i · bi .

(2)

i=0

In FP [6], the inner product operator is defined on a pair of sequences as follows: Def Innerproduct ≡ (Insert +) ◦ (ApplyToAll×) ◦ Transpose or Def IP ≡ (/+) ◦ (α×) ◦ Trans

(abbreviated form).

We briefly explain, here (but not in the rest of this paper) following [6] in writing f :x for applying function f to argument x and enclosing sequences in chevrons . First, ◦ is function composition: (f ◦g):x = f :(g:x). For “Insert”, (/+) : a, b, c = a + b + c and, for “ApplyToAll”, (αf ) : a, b, c = f :a, f :b, f :c. “Trans” maps a pair of sequences to a sequence of pairs: quoting [6], Trans : 1, 2, 3, 6, 5, 4 = 1, 6, 2, 5, 3, 4. Although it is not done even in many functional programming languages (including FP and Haskell), it is always advantageous to define sequences as functions, more specifically (for length n): functions whose domain is an index set  n, the set of the first n natural numbers. The reasons are discussed in Sect. 8.2. This convention is assumed in the sequel. Aside: a safe overloading principle. Using identical or similar symbols for different functions is unambiguous if the function can be inferred from the argument types. This helps the reader to distinguish  n and a • b (as above) from P and X • e (defined later). For the sake of comparison, let us consider partially and totally pointfree versions of (2). It is convenient calling i the first order variable (dummy), denoting points in the domains of a and b; likewise a and b are called second-order variables. We can rewrite (2)  – in partially pointfree form by suppressing i as in a • b = (a · b);  – in totally pointfree form by further suppressing a and b as in — • — = ◦( · ).

Form Methods Syst Des (2010) 37: 95–140

99

 Here is a functional summation operator defined over number-valued functions with arbitrary finite domain (formalized later). The “hat” () functional extends infix operators defined over some domain D to D-valued functions (formalized later), for instance, (1, 2, 3) · (6, 5, 4) = 6, 10, 12. Dashes (—) indicate affix conventions, here making • infix. Parenthesizing an infix operator makes itsprefix (the default); in this case: ( · )(a, b) = a · b.   (a · b) or ◦( · ) is preferable? This depends Which of the forms n−1 i=0 ai · bi or on many factors: clarity (as said, relative to the intended readership), context (in which the expression appears as a subexpression), style and convenience in calculation etc. Especially in the interest of clarity, a balanced style is important. The main conclusion is that declarative formalisms should be conceived such that the pointwise and pointfree styles are supported in a flexible way, including intermediate forms and smooth transformations between them. This distinguishes our approach from the numerous axiomatizations in which, as one reviewer observed, “reasoning is done at the abstract level without even being able to use the pointwise notions” [within the formalism]. 1.3 Overview Section 2 paves the way for the pointfree style by recalling the design of generic functionals and elastic operators for quantification in the wide sense. In Sect. 3, representative calculations that other formalisms can only do pointwise [5] are done in pointfree style. Section 4 illustrates this style in systems description and compares various formalisms. Section 5 shows how the pointfree style leads to a generic temporal calculus (FTC) as a basis for making temporal logic calculational. Section 6 captures TLA+ [59] calculationally and derives some basic theorems for illustration. Section 7 exemplifies calculational temporal reasoning by application to patterns about liveness issues, discovering strengthening of known results by calculation. Section 8 discusses ramifications and possible further research.

2 Paving the way for the pointfree style: generic functionals and elastic operators To make this paper self-contained, we recall some earlier material supporting the pointfree style, namely generic functionals [23] and elastic operators [24], and outline the advantages of the latter over strictly pointwise conventions such as the Eindhoven notation [4, 35]. 2.1 Notational conventions in a functional declarative framework With functions as the unifying concept, just four language constructs suffice to capture “all” common mathematical notation and for the pointfree style: identifier, function application, function abstraction, and tupling, jointly constituting the language Funmath [20, 21]. a. Identifiers may be predefined constants (the usual mathematical symbols for numbers, function operators, sets etc.) or introduced by a binding. A binding has the form i : S ∧. p where i is an identifier (or tuple of identifiers), S a set and p a proposition for further filtering; ∧. p is optional and may be written with p. Examples: n : N and n : Z ∧. n ≥ 0. Identifiers introduced by spec binding or def binding are constants and have global scope. b. Function application may use any affix convention (infix, suffix, prefix—the default) as specified in the definition by means of dashes (the exact conventions are unimportant). c. Function abstraction has the form binding . expression. It is lambda abstraction [9] augmented with domain specification (through S and p in the binding) and without λ. Identifiers introduced by the binding are variables (or dummies) and are local to the abstraction.

100

Form Methods Syst Des (2010) 37: 95–140

In binding . expression, the part binding . is the abstractor and expression the abstrahend. Examples: x : R . x 2 − 1 and f ◦ g = x : D g ∧. g x ∈ D f . f (g x) (observe only the form). d. Tupling consists in separating expressions by comma’s, denoting a function such that (e, e , e ) 0 = e and (e, e , e ) 1 = e and (e, e , e ) 2 = e (any finite length). 2.2 Functions A function is fully characterized by its domain (D f for function f ) and its mapping. A codomain is avoided, for reasons given in Sect. 8.1. In this setting, (i) a function definition must specify domain and mapping; (ii) functions are equal iff they have the same domain and the same mapping. A compact formalization of equality derived in [24] (from a lengthier one without quantifiers, using Leibniz’s principle and extensionality) is: for functions f , g, f = g ≡ D f = D g ∧ ∀x : D f ∩ D g . f x = g x.

(3)

The quantification used here mimics common notation but will be formalized later and  g). In fact, this part ∀x : D f ∩ D g . f x = g x will be seen to have pointfree form ∀(f = ∩ g (“equality on the domain inof formula (3) expresses function compatibility, written f = ∩ tersection”). Note: = is reflexive; therefore this symmetric symbol replaces the older compatibility operator © [23–25, 28] at the suggestion of a reviewer. An operator is a function symbol (e.g., square, D , +, ∧, ∈). The usual precedence is assumed: prefix has precedence over infix, arithmetic over relational, relational over logical, and f x y = (f x) y. For an infix operator , partial applications (a) and (b) are defined by (a) b = (b) a = a  b. This is similar to sections in Haskell [14] but not identical: since our scope is general engineering mathematics, not just programming, we resist the “currying reflex” (see also [13, p. 3]), and infix operators are defined on pairs, so a  b = ()(a, b). 2.3 Generic functionals Generic functionals [23] are general-purpose higher-order functions whose arguments and/or results may be arbitrary functions. Generic design means not imposing any restrictions on the argument functions, but specifying the domain of the result function such that the expression defining the mapping of the result function has no out-of-domain applications. The definitions below use the following metavariables: f and g for arbitrary functions, F for an arbitrary function-valued function,  for an arbitrary infix operator, P for an arbitrary predicate (boolean-valued function) and S, X and Y for arbitrary sets. The infix set operators ∩, ∪ are the usual ones but × is “functional”: A × B is a set of functions with f ∈ A × B ≡ D f = {0, 1} ∧ f 0 ∈ A ∧ f 1 ∈ B. Elastic variants are defined later. We start with some auxiliary “housekeeping” functionals. – Set filtering (↓): x ∈ S ↓ P ≡ x ∈ S ∩ D P ∧ P x. Shorthand: SP for S ↓ P , e.g., R≥0 . – The parametrized identity function (id— ): idS = x : S . x and idP = x : D P ↓ P . x. – The constant function definer (• ): S • e = v : S . e, assuming v not free in expression e. This is similar to the K combinator, but with domain specification. Here are two variants: – The empty function (ε): ε = ∅ • e (with arbitrary e). – The one-point function definer (→): d → e = ι d • e (where ι d = singleton set with d). Next follow the definitions of proper generic functionals, some with both a pointfree and a pointwise form, which can be seen as pointfree/pointwise transforms.

Form Methods Syst Des (2010) 37: 95–140

101

– Function composition (◦): g ◦f = x : D f ∧. f x ∈ D g . g (f x). The variant ; is convenient for postfix operators: x (f ; g) = (x f ) g, as exploited in [29]. – Domain filtering (↓): f ↓ P = f ◦ idP = x : D f ∩ D P ∧. P x . f x. Shorthand: fP = f ↓ P . Also ↓ for restriction: f ↓ S = f ◦ idS = x : D f ∩ S . f x (formerly [23–25] written ).  y (this is just one variant). – Function transposition (T ): F T = y : (D ◦ F ) . x : D F . F x  Legend: T is defined for any set-valued function T by x ∈ T ≡ ∀i : D T . x ∈ T i. – Function currying (C ): f C = x : D f  0 . y : D f  1 ∧. (x, y) ∈ D f . f (x, y) assuming D f is a set of pairs. Note: R  i = {r i | r : R} for any set R of tuples of length at least i + 1. – Monadic direct extension ( ): g f = g ◦ f . – Dyadic direct extension (): f   g = x : D f ∩ D g ∧. (f x, g x) ∈ D () . f x  g x. Note: since we define pairs as functions (with domain {0, 1}), we have f   g = (  ) (f, g)T .     • – Half direct extension ( and ): f  e = f   (D f e) and e  f = (D f • e) f. ): f  > g = x : D f ∪ D g . (x ∈ D f ) ? f x g x. Note: c ? e1 e0 = ec . – Function override (> > g) x. – Function merge (∪·): f ∪· g = x : D f ∪ D g ∧. x ∈ D f ∩ D g ⇒ f x = g x . (f  – Functions in parallel (): f  g = (x, y) : D f × D g . (f x, g y) 2.4 Elastic operators for quantification in the wide sense 2.4.1 Principle and definitions Elastic operators are functionals designed as pointfree replacements for the many ad hoc notations where a dummy is bound via a universal or existential quantifier (∀, ∃), set notation { | }, a summation sign ( ), a limit notation (lim) etc., as in ∀x(p) ∃x(p) {x ∈ S | p}

n  x=m

e

lim e.

x→a

(4)

The ps are propositions (boolean-valued expressions), the es are arithmetic expressions. The parts ∀x, ∃x, {x ∈ S|}, nx=m and limx→a introducing the dummy x are ad hoc abstractors. Designing pointfree variants proceeds as follows: instead of expressions taking values in some domain D, consider D-valued functions (e.g., predicates instead of propositions), on which suitable functionals (called elastic operators) are defined. Elastic operators support pointfree expression. Here are some definitions. Note that the “range” of the quantification is the domain of the argument function (domain modulation). – The universal quantifier (∀) and the existential quantifier (∃) are predicates over predicates: ∀P ≡ P = D P • 1 and ∃P ≡ P = D P • 0 for any predicate P .  – The range operator (R) is defined for any function f by y ∈ R f ≡ ∃ (f = y). Derived operators: the total function arrow (→): f ∈ X → Y ≡ D f = X ∧ R f ⊆ Y and the / / partial function arrow  (→): f ∈ X → Y ≡ D f ⊆ X ∧ R f ⊆ Y (see  also Sect. 8). – The sum operator ( ) is defined by three axioms: the empty rule ε = 0,   the one-point  rule (d → e) = e (any d, numeric e) and the merge rule (f ∪· g) = f + g for any number-valued functions f and g with nonintersecting finite domains. Extension to infinite sequences of numbers can be done in the classical way but is less relevant here. – The lim operator [24] is not defined here for the   sake of continuity, but in Appendix B. – The elastic (set) intersection ( ) and union ( ) are defined for any set-valued function     T by x ∈ T ≡ ∀(x ∈ T ) and x ∈ T ≡ ∃ (x ∈ T ).

102

Form Methods Syst Des (2010) 37: 95–140

– The generalized functional Cartesian product (×) is defined for any set-valued function ∈ T ). The wide versatility, ranging from analog filter T by f ∈ × T ≡ D f = D T ∧ ∀(f  specification to dependent types in programming is illustrated in [23]. – Two-argument generic functionals have elastic counterparts; for instance, for the parallel operator:  F f = x : D F ∩ D f ∧. f x ∈ D (F x) . F x (f x) for function-valued F . Since the argument of an elastic operator is a function, it can be denoted by any of the constructs listed in Sect. 2.1. Two of them capture common conventions in a uniform way. a. Abstractions yielding pointwise expression An elastic operator applied to an abstraction captures the common pointwise notations in shape and in meaning. Here are some examples. – For universal and existential quantifiers: ∀v : S . p and ∃ v : S . p. Examples from earlier  expressions: ∀(f =  g) ≡ ∀x : D f ∩ D g . f x = g x and ∃ (f = y) ≡ ∃ x : D f . f x = y. – For the range operator R, a synonymous operator is { }. Together with two variants for function abstraction, v : S | p standing for v : S ∧. p.v and e | v : S standing for v : S.e, this mimics common notations while avoiding the usual defects (see note below). An example is defining n.  m .. n = {i : Z | m ≤ i ≤ n}for integer m and ) = (x n − 1)/(x − 1). We capture – For the operator, an example is (i : 0 .. n − 1 . x i  the common notation by defining nx=m e to stand for (x : m .. n . e). Remark: common notations often overload the set membership symbol ∈ for binding. As some authors observed [20, 59], this makes the common patterns {v ∈ S | p} and {e | v ∈ S} ambiguous, since {v ∈ S | v ∈ T } matches both. In [59], the ambiguity is resolved by arbitration, at the cost of expressiveness. Without overloading [20, 21, 24], the patterns are {v : S | p} and {e | v : S}; hence {v : S | v ∈ T } and {v ∈ S | v : T } are different. An illustration: {v : S | v ∈ T } = S ∩ T whereas {v ∈ S | v : T } ⊆ B (the set of booleans). b. Tuples unifying variadic application Since sequences are functions, sequences of elements of the proper type are valid arguments to most elastic operators. Some illustrative properties: ∀(p, q) = p ∧ q, ∃ (p, q) = p ∨ q, R (a, b) = {a, b} = ι a ∪  ι b (any a, b), (x, y) = x + y (numbers x, y), × (S, T ) = S × T (sets S, T ). This leads to the following convention. For practically every infix operator , it is possible to define a useful elastic operator E with property E (a, b) = a  b. We call such E an elastic extension of . Moreover, we define operand/operator alternations of the form a  b  c (any length, hence called variadic application) to stand for E (a, b, c). This is a uniform convention, in contrast with the usual conventions invoking different properties such as associativity (for a + b + c), conjunctivity (for a = b = c), etc. Note also that S × T × U = × (S, T , U ), illustrating an elastic extension of a non-associative, non-commutative operator, namely, ×. An infix operator has several elastic extensions, since the property E (a, b) = a  b obviously does not uniquely define E. The “most useful” one is chosen for defining variadic application. Such design alternatives and sensible decisions will be illustrated for equality and inequality in general (= and =) and for booleans (≡ and ≡ / ) in Sect. 3. Remark: with these conventions, {e, e , e } has familiar shape and meaning. However, in the literature one often also finds {e} for singleton sets, violating Leibniz’s principle. Hence for singleton sets Frege’s notation ι e (with axiom x ∈ ι e ≡ x = e) is preferable, also for other reasons [44]. Still, to avoid confusing the uninitiated, we recommend writing {f } only if f is an abstraction or tupling, and writing R f otherwise. More generally, our conventions support a “conservative” writing style that avoids puzzling the reader.

Form Methods Syst Des (2010) 37: 95–140

103

Table 1 Definition patterns for elastic extensions Prop. 

Empty

One-point

Combine

Restriction on functions f , g

A

Eε=u

E (0 → e) = e

E (f ++ g) = E f  E g

Lists

A, C

Eε=u

E (d → e) = e

E (f ∪· g) = E f  E g

Domains finite, nonintersecting

A, C, I

Eε=u

E (d → e) = e

E (f ∪· g) = E f  E g

∩ g Domains finite and f =

Finally, for flexibility (especially in systems description, see Sect. 4.1), direct extension < is also defined for higher-order prefix operators, including elastic ones, by an operator —
0 . Arguably this is the so we define an I-bag of items of type X as a function of type X → “natural” definition, since equality of I-bags (as functions) directly reflects the idea of two bags being equal iff every element appears equally often in both bags. This is not the case for L-bags, since differently ordered lists still represent the same conceptual bag. Conceptual

Form Methods Syst Des (2010) 37: 95–140

107

equality of L-bags and  is equality of the corresponding I-bags, written bag = bag  ,   / N>0 ) with bag = x : R . ( = x) (how often x appears in ). where bag : X ∗ → (X → These observations justify saying simply “bags” for I-bags. For a finite bag of integers, the domain is a finite set of integers. The total of such a bag (id · b), where id = idZ and · is multiplication. b is given by tot b = 3.2.3 Pointfree formulations Below we assume the following auxiliary definitions. Predicates Even and Odd are defined on integers by Even n ≡ ¬ (n † 2) and Odd n ≡ n † 2. The problem statements in pointfree form are then the following: given a predicate P with finite domain and a finite bag b of integers, ≡ ≡ / P ≡ Odd |D P |.  b. Even ( P ) ≡ ≡ P ≡ Even |D P |.  c. Even (tot b) ≡ Even ( bOdd ).

a.

≡P

(9) (10) (11)

3.2.4 Pointfree calculations Auxiliary properties In the function  remainder of this section, let  f be any number-valued  f with finite domain. For the trading rule suffices: (P  · f )= fP for any predicate • P . Finally, P . Also, Odd ◦ P = P and Even  ◦ P = ¬ ◦  |D f | =  (D f 1).   From modulo arithmetic, (f ⊕ g) = f ⊕ g and ( ((†d) ◦ f )) † d = f † d for nonzero d. With d := 2 and Odd = (†2) we get a generalization of (8) in pointfree form: 

Odd (

   f ) ≡ Odd ( (Odd ◦ f )) and, equivalently, Even ( f ) ≡ Odd ( (Even ◦ f )). (12)

This proves the considered property for L-bags; later on we derive (11). Convention When using properties of direct extensions of operators in a justification, we write the corresponding property of the underlying operator. For instance, simply writing the  (D P • 1). boolean equality ¬ p ≡ p ⊕ 1 indicates using the functional equality ¬ P = P ⊕ Deriving (9):

≡P

≡

/P ≡

≡ Odd |D P |

≡P

 ≡ Def. ≡, ≡ /  ¬ ( (¬ P ))   (D P • 1)) ≡ ¬ p ≡ p ⊕ 1 ¬ ( (P ⊕      ¬ ( P ⊕ (D P • 1)) ≡ Distr. /⊕  / P ≡/ (D P • 1)) ≡ ≡ / is bool ⊕ ¬ (≡   ≡ Def. ≡ /,  ≡ / P ≡ (D P • 1) † 2  ≡ Odd = (†2) ≡ / P ≡ Odd ( (D P • 1))  ≡  to |—| ≡ / P ≡ Odd |D P |

108

Deriving (10):

Form Methods Syst Des (2010) 37: 95–140

 equivalently, Odd ( P ) ≡ ≡ P ≡ Odd |D P |   Odd ( P ) ≡ Odd = (†2) P †2  /≡ /P ≡ Def. , ≡

≡ P ≡ Odd |D P |.  A first derivation of (11): Even (tot b) ≡ Even ( bOdd ), using  modulo arithmetic. In fact, we shall prove the equivalent Odd (tot b) ≡ Odd ( bOdd ).  Odd (tot b) ≡ Defin. tot Odd ( (id · b))  (id · b) † 2 ≡ Odd = (†2)    · b)) † 2 ≡  f † 2 = ((†2) ◦ f ) † 2 ((†2) ◦ (id  · ((†2) ◦ b)) † 2 ≡ (m · n) † 2 = (m † 2) · (n † 2) (((†2) ◦ id)  ((†2) · ((†2) ◦ b)) † 2 ≡ f ◦ id = f   (Odd · ((†2) ◦ b)) † 2 ≡ (†2) = Odd   ≡ Trading sub  ((†2) ◦ b)Odd † 2  ((†2) ◦ bOdd ) † 2 ≡ (f ◦ g)P = f ◦ gP     ≡  ((†2) ◦ f ) † 2 = f † 2 bOdd † 2  Odd ( bOdd ) ≡ (†2) = Odd ≡

Prop. (9)

Although this derivation is very direct, it relies nearly totally on modulo arithmetic and hence is not a good example of quantifier manipulation. Therefore, as a style exercise, a different derivation follows later, after deriving the trading rules for ≡ / and ≡. Trading rules for ≡ / , ≡. / is ≡ / QP ≡ ≡ / (P  ∧ Q). Here is a derivation. The trading rule for ≡   / QP ≡ Def. ≡ /,  (QP ) † 2 ≡   ≡ Trading sub  (P  · Q) † 2   ≡ Defin.  (P  · Q)  ≡ p · q ≡ p ∧ q (P  ∧ Q) ≡

/ Defin. ≡

/ (P  ∧ Q) ≡

The trading rule for ≡ is ≡ QP ≡ ≡ (P ⇒  Q). Here is a derivation.

≡ QP

≡

Defin. ≡

¬ (≡ / (¬ ◦ QP ))

/ (¬ ◦ Q)P ) ≡ f ◦ gP = (f ◦ g)P  ¬ (≡ ≡

/  ¬ (≡ / (P  ∧ (¬ ◦ Q))) Trading sub ≡

≡

Defin. ≡

≡

De Morgan

≡

∨ to ⇒

≡ (¬ (P ∧ ¬ Q)) ≡ (¬ P ∨ Q)  Q) ≡ (P ⇒

Form Methods Syst Des (2010) 37: 95–140

109

 A second derivation of (11): Even (tot b) ≡ Even ( bOdd ), using properties of ≡ and ≡ /. We proceed top-down, factoring out a repetitive part as “Property A” proven afterwards. Even (tot b) ≡

≡ ≡ ≡ ≡ ≡ ≡

Defin. tot



Even (

(id · b))

≡ (Even ◦ (id· b)) ∨ (Even ◦ b)) Even (m · n) = Even n ∨ Even m ≡ ((Even ◦ id)  f ◦ id = f  ≡ (Even ∨ (Even ◦ b))  (Even ◦ b)) p ∨ q ≡ ¬ p ⇒ q ≡ (Odd ⇒ Trading sub ≡ ≡ (Even ◦ b)Odd (f ◦ g)P = f ◦ gP  ≡ (Even ◦ bOdd ) Property A

≡

Property A

 Property A is Even ( f ) ≡ Proof: 

Odd (



Even (

bOdd ) 

≡ (Even ◦ f ), equivalently Odd (

f) ≡

/ (Odd ◦ f ). ≡

 f ) ≡ Prop. (12)  Odd ( (Odd ◦ f ))  (Odd ◦ f ) † 2 ≡ Odd = (†2)  /≡ / (Odd ◦ f ). ≡ Def. , ≡

4 The pointfree style in systems description 4.1 A brief reminder of generic functionals and elastic operators in systems description Generic functionals and elastic operators were originally motivated by formal systems description. For the sake of completeness, we briefly recall some facts from [23]. – Direct extension extends operators defined for instantaneous values to operators on signals, defined as functions of time. For instance, for R- or C-valued signals x and y,  y adds x and y, and c · x multiplies x by a constant c. square x squares x, x + – Composition has many uses: (a) cascade connection of subsystems with behaviors f and g as in f ◦g; (b) defining monadic direct extension; (c) expressing replication as in f ◦s = f s0 , f s1 for a signal pair s and hence (d) “map” as in functional programming [14]: f ◦ (x, y, z) = f x, f y, f z (provided {x, y, z} ⊆ D f ). – Transposition is in some sense the dual of composition, since (f, g, h)T s = f s, g s, h s (provided s ∈ D f ∩ D g ∩ D h), hence its use for expressing fanout. Other uses are transforming a tuple of signals into a signal of tuples, and subsuming “zip” as in functional programming. Aside: the duality is even more apparent in the following pun (it is a pun / free e on the free occurrences): because of the different restrictions x ∈ / free f and x ∈ f ◦ (x : X . e) = x : X . f e

provided x ∈ / free f and ∀x : X . e ∈ D f,

(13)

(x : X . f )T e = x : X . f e

provided x ∈ / free e and ∀x : X . e ∈ D f.

(14)

– Elastic operators generalize the so-called resolution functions in VHDL [86].

110

Form Methods Syst Des (2010) 37: 95–140

Systems description also prompted generalizing direct extension to higher-order prefix oper
[[a]] -> [[a]]

n :: Int

n = 2ˆm

prfx (y:ys) [] = [y]:(prfx ys [])

prfx [] xs = []

prfx (y:ys) (x:xs) = (y:x):(prfx ys xs)

trsp :: [[a]] -> [[a]]

trsp [] = []

(-:) :: Int -> Int -> Int

x -: y = div x y

(|-) :: Int -> Int -> Int

x |- y = mod x y

lsto :: Int -> [Int]

lsto 0 = []

scpr :: [Int] -> [Int] -> Int

scpr v w = sum (zipWith (*) v w)

trsp (x:xs) = prfx x (trsp xs)

lsto k = (k - 1) : (lsto (k - 1)) digits :: Int -> Int -> Int -> [Int] digits b c k = map ((|- b) . (k-:) . (b ˆ )) (lsto c) number :: Int -> Int -> [Int] -> Int

number b c = scpr (map (b ˆ ) (lsto c))

bits :: Int -> [Int]

bits = digits 2 m

nmbr :: [Int] -> Int

nmbr = number 2 m

brep :: [[Int]]

brep = map bits (lsto n)

synd :: [Int] -> [Int] synd w = map (|- 2) (map (scpr w) (trsp brep)) bval :: Bool -> Int

bval b = if b then 1 else 0

indx :: [Int] -> Int -> Int indx w = nmbr . (map (|-2)) . (zipWith (+) (synd w)) . bits iseq :: Int -> [Int]

iseq k = map bval (map (k==) (lsto n))

turn :: [Int] -> Int -> [Int] turn w k = map (|-2) (zipWith (+) w (iseq k)) asst :: [Int] -> Int -> [Int]

asst w = turn w . indx w

magi :: [Int] -> Int

magi = nmbr . synd

Fig. 5 Implementation of the magician’s trick in Haskell

the pointfree style this index is suppressed except for lowest-level auxiliary definitions. We do not give the Haskell code, as its essence is similar to the Maple implementation below. c. One of the reviewers suggested implementing domain restriction of the form f N (which equals f ◦ id  N ) by composition with take N [0..]!! (which is id  N ). As (s)he demonstrated with a worked-out example, this allows implementing the image definitions of (17, 18, 19) with minimal style distortion in Haskell. Of course, the type definitions cannot be rendered in Haskell, but newer languages like Agda [68] might provide a solution. 4.3.4 Implementation in Maple Maple is not seen as a functional language, yet supports higher order functions. Using this option seems to reduce execution speed, which is not a direct concern here. Very unfortunate is the absence of explicit types, since for higher order functions types are a crucial form of documentation lest descriptions become rather cryptic. An implementation with sequences as functions is shown in Fig. 6. For a good understanding, the reader may want to write down the types. As an example, Fig. 7 shows the corresponding code for a few functions from similar a Haskell implementation.

Form Methods Syst Des (2010) 37: 95–140

117

> restart; > m := 3; > n := 2 ˆ m; > cmps := f -> g -> x -> f(g(x)); > trsp := f -> y -> x -> f(x)(y); > fdiv := D -> d -> floor(D/d); > fmod := D -> d -> D - d * floor(D/d); > dexsumod2 := f -> g -> i -> trsp(fmod)(2)(f(i) + g(i)); > fsum := f -> k -> if (k = 0) then RETURN (0) else RETURN (f(k-1) + fsum(f)(k-1)) fi; > scpr := f -> g -> fsum(i -> f(i)*g(i)); > powr := b -> i -> b ˆ i; > digits := b -> j -> cmps(trsp(fmod)(b))(cmps(fdiv(j))(powr(b))); > number := b -> scpr(powr(b)); > bits := digits(2); > nmbr := trsp(number(2))(m); > synd := w -> cmps(trsp(fmod)(2))(cmps(trsp(scpr(w))(n))(trsp(bits))); > indx := w -> j -> nmbr (dexsumod2(synd(w))(bits(j))); > iseq := i -> j -> if (i = j) then 1 else 0 fi; > turn := w -> j -> dexsumod2(w)(iseq(j)); > asst := w -> cmps(turn(w))(indx(w)); > magi := cmps(nmbr)(synd);

Fig. 6 Implementation of the magician’s trick in Maple

fsum :: (Int -> Int) -> Int -> Int fsum f k = if (k == 0) then 0 else f (k - 1) + fsum f (k - 1) scpr :: (Int -> Int) -> (Int -> Int) -> Int -> Int scpr f g = fsum (ı-> f i * g i) digits :: Int -> Int -> Int -> Int digits b j = (|- b) . (j -:) . (b ˆ ) number :: Int -> (Int -> Int) -> Int -> Int number b = scpr (b ˆ )

Fig. 7 Haskell code of some representative functions (for documenting the Maple code with types)

5 The pointfree style in unifying temporal calculi 5.1 Motivation: promoting awareness in model checking and facilitating calculational reasoning Model checking [7, 32, 53, 59] is a convenient method for verifying systems with automated tools. Apparently, it makes the task easy for the user: given a formal system description and a condition to be satisfied, the tool either confirms that the condition is met or yields a counterexample. This has made model checking one of the most popular formal methods. This simplicity of use is deceptive. Formalizing the description and the condition requires essentially mathematical aptitudes. Indeed, the conditions are mostly expressed by temporal formulas, which are not very intuitive, as noted by Lamport [59]. This can be alleviated by

118

Form Methods Syst Des (2010) 37: 95–140

patterns [41–43], i.e. given temporal formulas “known” to express some property of interest. An example is the Bandera project [8, 43] for concurrent Java software. However, no predefined collection of patterns is complete for practical application, and the tool user must be able to design new ones. Clarifying the intuitive meaning of patterns, exploring the relationship between them and designing new ones, is again most conveniently done using basic mathematics [22]. Arguably the calculational style makes derivations easier to follow [46]. However, Lamport observes [59, p. 99] that, in temporal logic, proof by calculation beyond simple cases becomes challenging. We will reverse the situation by making temporal logic amenable to the calculational style, thus turning it into a (mental) tool for unification and discovery. 5.2 From temporal logics to temporal calculi Most formulations of temporal logic [65] follow the usual style of formal logic in presenting it as a separate language with axioms, and they define models via semantic functions in a metalanguage. This is suitable to study metamathematical issues. For introducing temporal logics to the practicing engineer, it is helpful casting them into a calculus with the smooth algebraic flavor so appreciated in classical mathematics, as just another theory in the common larger framework. A simple approach is viewing temporal operators as an algebra of functions on sequences. This assumes linear time. Branching time has slightly different rules, derivable similarly via trees instead of sequences [7, 73]. Let us briefly refer to some other literature on unifying frameworks for temporal logics. An abstract algebra approach based on Galois connections is Temporal Algebra [83], whereas correspondence theory takes a modal logics viewpoint [82]. A predicative semantics approach using generic composition is found in [31]. Our approach differs by its more concrete basis. Starting from the model rather than pure axioms reflects the systems view (model given, various aspects requiring various formalisms) as opposed to the pure formal logic view (single formalism, perhaps various models), as further discussed in [17, 18]. In the analysis and design of patterns, the model is the domain of discourse anyway. Moreover, pointfree formulation allows casting the usual temporal logic axioms [65] into textually identical theorems [12, 17], so calculations can have the same abstract flavor. Different styles are possible, also depending on other desiderata. Indeed, to support awareness when using a model checking tool, the calculus should match the tool’s language. We illustrate later how to do this for TLA+ . Yet, it is also conceptually helpful to start with a very elementary form of temporal calculus that captures the common concepts independently of tools. The derived results are easily ‘re-used’ in designing calculi for specific tools. 5.3 A purely functional ‘bare bones’ temporal calculus (FTC) 5.3.1 Principle and operator definitions A very basic temporal calculus is obtained by defining temporal operators as predicate transformers [12, 17], the predicates of interest pertaining to system behaviors (infinite sequences of system states). Formally, let S be the state space (instantaneous values). Behaviors (infinite sequences) are functions of type N → S, also written S∞ . The predicates of interest are Boolean-valued functions over S∞ , hence of type BP := S∞ → B (“behavior predicates”). (i) Logical operators of FTC are just direct extensions of the usual propositional operators: for any infix operator  (say, ∧, ∨, ⇒, ≡) and any β in S∞ ,

Form Methods Syst Des (2010) 37: 95–140

119

(P   Q) β ≡ P β  Q β.

(20)

Propositional operators of type B2 → B (for ∧, ∨, ⇒, ≡) or B → B (for ¬) are thereby ex may tended to type BP2 → BP or BP → BP (“predicate transformers”). In this context,  be written  by way of overloading, without danger for ambiguity, as seen earlier with LabVIEW polymorphism. Sometimes, we keep  for emphasis. In what follows we shall need the shift operator (σ ) defined for any nonempty sequence x (hence any β in S∞ ) by σ x = x ◦ ν , where ν, for “next”, is the successor function on N. In pointwise form: σ x m = x (m + 1) for any m in D (x ◦ ν). Informally: σ drops the first symbol, e.g., σ (a, b, c, d) = b, c, d. To avoid some distracting technicalities, we assume in FTC that σ stands for σ S∞ and Ds (prefixing s) for (Ds )S∞ (for any s in S). The n-th power of a function is n-fold composition: f 0 x = x and f n+1 x = f (f n x) inductively. (ii) Temporal operators of FTC are predicate transformers of type BP → BP, e.g.,



(“next”)

defined by

P = P ◦ σ
0 [75], although 0 is the “most natural number” [36]. In applied mathematics, recognition as functions is more recent, even in signal processing [63] where sequences are the central objects. In mathematics, pairs (tuples) are usually defined as entities of the form (a, b) separate from functions and are the basis for defining Cartesian products. Many texts [51, 74] consider the notation (a, b) self-explanatory, others [49, 77] define (a, b) = {a, {a, b}}. In Funmath, pairs (tuples) are functions and Cartesian products are function spaces in the sense that f ∈ A × B ≡ D f = {0, 1} ∧ f 0 ∈ A ∧ f 1 ∈ B, so A × B = × (A, B) by the definition of × in Sect. 2.4. This functional view is rare, yet not isolated: after some searching we found in specialized texts [78, p. 22] a (pointwise) definition of an operator  similar to × in the sense that i∈I Ai = × A for an I -indexed family A of sets. A widespread notation is An for the n-fold Cartesian product of a set A with itself. Examples are Rn in analysis [75], An for very diverse A and n in signal processing [63], and Bool2 in category theory [13], generally not function spaces. In Funmath, however, the n-fold Cartesian product is × ( n • A), which equals the function space  n → A. Also, in language and automata theory, A∗ is the set of finite lists of elements in A. We  ∗ define A = n : N . An and Aω = A∞ ∪ A∗ , so lists are functions [20, 23]. The module Sequences in TLA+ is ”functional” in the same manner, except for starting indexing at 1. Lists defined as functions have various advantages: (i) inheriting all rights and privileges of functions, such as generic functionals [23, 24]; (ii) closer affinity with classical applied mathematics (indexing being basic);

132

Form Methods Syst Des (2010) 37: 95–140

(iii) a higher level of abstraction than recursively defined lists, which are in fact concrete representations of the abstract concept of a list. This is shown by the difference between a cons list and a snoc list [13, 14], and mechanisms to hide it [81]. In Alloy, indexing is also considered “better than a recursive list because it introduces less extraneous structure” [56]. Of course, in languages with recursive lists, an indexing operator is easily defined, or predefined like !! in Haskell [14]. Still, in engineering (e.g., DSP) this is quite cumbersome. Lists as functions have no drawback. They also support recursion and inductive proofs as usual in functional programming [14]. Let the prefix operator (>−) be defined [23] by a >− x = i :  (# x + 1) . (i = 0) ? a x (i − 1)

where # = − ◦ D

(length). (40)

The postfix and concatenation operators are defined similarly. These operators support recursive definitions of the familiar form, for example, f ε = c and f (a >− x) = k (a, f x). This looks like pattern matching [14], a programming concept. Yet, in the wider scope of interest here, it is seen mathematically as indirect function definition, whereby f : X → Y is defined via g : W → X (surjective on X) and h : W → Y by f (g w) = h w or f ◦ g = h. Well-definedness requires g w = g w ⇒ h w = h w . Injectivity of g is a sufficient condition, satisfied by >−. In the example, we can write f z = k (a, f x) where (a, x) = ( >− )− z. To appreciate the wider scope, note how indirect definition formalizes a widely spread notational convention in DSP that has caused some controversy [62] and is considered “somewhat odd” even by those who use it [72], namely the appearance of ej ω in X(ej ω ) on the left hand side in the  definition of the Discrete Time Fourier Transform [72]: given −j ωn for all ω : R. Formally, this indirectly defines x : Z → C, define X(ej ω ) = ∞ n=−∞ xn · e X for every point of the unit circle C := {ej ω | ω : R}, so a fitting type for X is C → C. Returning to lists, for >− one can prove the following induction principle: for any list predicate P : A∗ → B, one has ∀P ≡ P ε ∧ ∀x : A∗ . P x ⇒ ∀a : A . P (a >− x). To conclude, defining lists as functions constitutes a “win-win” strategy in terms of expressiveness and calculation in classical engineering mathematics and in CS. Expressiveness is exploited, for instance, in [69] where the absence of duplicates in a list is formulated as function injectivity. In programming, the efficiency depends on the implementation. 8.3 Abstraction issues and further research Our motivation is unifying engineering- and CS-related mathematics and lowering the threshold. A corollary of the latter is paving the way to more advanced (abstract) theories. Generic functionals and functional predicate calculus, if introduced gradually and with examples, require only high school background. Generic functionals, as a “concrete category theory”, are an ideal preparation for the abstract variant [10, 13, 33, 71]. Calculational reasoning with quantifiers facilitates dealing with the logical aspects of category theory. In the following reflections, abstraction is not a goal by itself: the “miles” of unification, expressiveness and calculational power per “gallon” of abstraction are what really counts! a. Cartesian products, function spaces and currying in concrete and in categorical settings. First, a notational issue. Writing B A for function spaces is misleading, as its roots show [10], namely, encoding n by  n as in set theory [49], so B 2 = B {0,1} = {0, 1} → B. In category theory [13], B 2 is B × B, a different object. With numbers encoded as sets, 23 ∼ 8 is not equality, hence not good enough! Worse is using 2X (set of predicates) for the powerset P X (which is clearly distinct [49, p. 33]), as many model checking texts do. As a

Form Methods Syst Des (2010) 37: 95–140

133

conclusion, B A is better replaced by A → B and, in category theory, by [A → B] as in [10] or by A ⇒ B as in [33], using [ ] or ⇒ distinguish such objects from arrows. More important issues are conceptual. In category theory, A × B generalizes to i∈I Ai [71] (not a function space). Hence the question: how do we unify in category theory Cartesian products and function spaces as general as × T , where D T may even equal R? A related topic is generic currying: f C = x : D f  0 . y : D f  1 ∧. (x, y) ∈ D f . f (x, y) as in Sect. 2.3. The domain of f may  be any set of pairs. Generic design for uncurrying yields F C = (x, y) : D F × (D ◦ F ) ∧. y ∈ D (F x) . F x y for any functionvalued F . A typical F has dependent type X  x → Yx  y → Zx,y (syntactic sugar for × x : X . × y : Yx . Zx,y ). In many applications, other generalizations arise, such as variadic currying [27]: for / B (alternatively, any f : × T → B) and any x and y satisfying x ++ y ∈ D f , any f : A∗ →   define f C x y = f (x ++ y); in pointfree form f C = (f ◦ (++))C . Other variants might C be multi-stage currying f x y z = f (x ++ y ++ z) and continuous currying (with function merge). How are such generalizations best handled in category theory, and what do we gain? b. Generic functional design and category theory We just mention two issues. (i) Generic design is easily extended to (concrete) relations, e.g., given R : A × B → B and S : C × D → B, define R ◦ S on A × D by a (R ◦ S) d ≡ ∃ c : B ∩ C . a R c ∧ c S d. How is the case B = C best handled in category theory? (Possibility: embed B and C in B ∪ C). (ii) Many generic functionals involve fine-grain domain control. An example is function inversion [23]. The bijective domain is Bdom f = {x : D f | ∀y : D f . f y = f x ⇒ y = x} and the bijective range is Bran f = {f x | x : Bdom f }. The inverse f − is then a function in Bran f → Bdom f with ∀x : Bdom f . f − (f x) = x. Defining the elastic function merge [23] by   y ∈ D ( · F ) ≡ y ∈ (D ◦ f ) ∧ ∀x, x  : (D F )2 . y ∈ D (F x) ∩ D (F x  ) ⇒ F x y = F x  y   y ∈ D ( · F ) ⇒ ∀x : D F . y ∈ D (F x) ⇒ · F y = F x y, the generic function inverse gives rise to the following equations with pleasing symmetry:   f ) and f − = · (f → idD f ). f = · (idD f →

(41)

Such equations are pointfree, but were derived pointwise in view of the fine-grain domain control involved. Hence it would be interesting to make the derivations fully pointfree starting with the definition, both in a concrete setting (maybe easy) and in a categorical one.

9 Conclusions Systems design requires diversity without the conceptual distraction and overhead of disparity. This is best achieved by offering the designer unified mathematical theories, with suitably lowered threshold to improve accessibility in practice. The pointfree style contributes towards this goal in several respects. In general, it supports a convenient algebraic style and a level of abstraction that allows concentrating on higherlevel objects without extraneous metamathematics or burdensome nomenclature. This has been demonstrated in three areas of sufficient diversity for appreciating the scope.

134

Form Methods Syst Des (2010) 37: 95–140

First, by designing suitable operators for quantification in the wide sense in pointfree and pointwise style, thereby making calculations in logic, arithmetic and other areas similar in approach and convenient for practical use. Second, the pointfree style helps describing signals and systems in a way that is easy to visualize pictorially without sacrificing formality. Elastic operators are useful in expressing (sub)system behavior, generic functionals in expressing signal flow between (sub)systems. Both provide conceptual help in structuring systems descriptions in specific formalisms. Third, via a temporal calculus with pointfree formulation, the “user-friendliness” of the calculational style is made available in temporal reasoning. Lamport’s Specifying Systems [59] is about specifications, with proofs in one chapter only; otherwise the size of the book would have doubled. Not surprisingly, the proofs given concern patterns. Calculational reasoning about patterns keeps the complexity of temporal specifications manageable and within the grasp of intuition, and even supports discovery by newcomers in the field. An educational concern of this paper is that the approach may be helpful in lowering the threshold sufficiently to present formerly advanced material at a more basic level. Acknowledgements The author wishes to thank the reviewers for their many useful comments and suggestions, which yielded significant improvements in the final version of this paper. In particular, one reviewer prompted the author to rewrite several derivations that were still partially pointwise in [28] in fully pointfree form and also provided extensive worked-out examples of alternative formulations in a categorical style as represented in the Algebra of Programming [1, 13, 69].

Appendix A: On formulating binary algebra as a simple number arithmetic We formulate binary algebra and logic as elementary arithmetic restricted to the numbers 0 and 1 [20]. By this very restriction, it is inherently simpler than grade school arithmetic. The choice of propositional constants affects predicate calculus [24] very little, but discrete mathematics very much (Sect. 3). Since the discussion also often comes up in the literature, it deserves some closer scrutiny. a. Motivation In the logic literature, the choice appears to be random; in switching algebra and model checking, {0, 1} prevails; Hehner [50] also uses numbers but takes {⊥, &} for binary values; the computing literature, with some exceptions [30], favors {F, T}, often to make boolean a distinct type for fear of “confusion”. Yet, numbers are advantageous. (i) Philosophically, danger of confusion resides only in preconceived distinctions. Numbers are conceptually more neutral than truth values. Even in “logic” circuits, 2-valued state variables are most often not meant as truth values. Hence switching algebra and logic are just interpretations of binary algebra. With this view, the notion of confusion is vacuous. (ii) More important are the mathematical and practical considerations, where the {0, 1}choice establishes a direct relationship with other theories or calculi. We list a few cases. – Fuzzy logic [85] is usually defined on the interval [0, 1]. Letting fuzzy predicates on a set X be functions of type X → [0, 1], ordinary predicates, as functions of type X → {0, 1}, are simply a limiting case. Similar observations hold for multi-valued algebras. – Binary number representation: {0, 1} is more generalizable than other conventions.

Form Methods Syst Des (2010) 37: 95–140

135

– Ordinary arithmetic, where the usual arithmetic operators obviously accept 0 and 1. This proves useful in many domains, ranging from logical puzzles involving counting to software specification. In general,  for any predicate with finite domain, the number of items satisfying P is simply P . For instance, in specifying sorting, the   function bag with bag = x : R . ( = x) from Sect. 3.2 can express that sorting (sort ) = bag (simpler than does not change the inventory of a list by writing bag via permutations). Another example is (f  · P ) = fP for any predicate P and number-valued f . – Combinatorics, where a characteristic function or indicator function IP is introduced by “IP (x) = 1 if P x holds, 0 otherwise” (admitting a regrettable design decision?) when calculations threaten to become unwieldy. The choice {0, 1} obviates this. By the same token, Iverson’s convention [55] (by which, for instance, (a > 0) is 0,1valued) can be used without special brackets (e.g., [a > 0] as in [45, 58]). Special symbols such as the Kronecker delta are obviated by writing simply i = j instead of δij , as also discussed in [45, 58]. A nice example is sign = x : R . (x > 0) − (x < 0). – Modulo 2 arithmetic (as a Boolean ring or Galois field), as in coding theory. Understanding the associativity of ≡ is counterintuitive for “logical equivalence” with truth values, but is directly clear from the equality (a ≡ b) = (a ⊕ b) ⊕ 1 linking it to modulo-2 arithmetic, where associativity of ⊕ is quite intuitive. These considerations are also relevant to programming language design and mathematical software. Existing languages gives the impression that the designers were insufficiently aware of the advantages of integrating logic in arithmetic. Further discussion on calculational advantages of embedding binary algebra in ordinary arithmetic can be found in the reports by the author [20] and Hehner [50]. Hehner’s use of ⊥ and & has the appeal of symmetry (w.r.t. 0), but has narrower scope in unifying theories, since it does not yield the advantages (listed above) that lead to a preference for numbers in the first place. b. Binary algebra Here is an overview of the principles, summarized from [20]. Consider the numeric set R := R ∪ {−∞, +∞}, i.e., the set R of real numbers extended with infinity, on which greatest lower bound (∧) and least upper bound (∨) are defined by z ≤ x ∧y ≡ z ≤ x ∧ z ≤ y

and

x ∨ y ≤ z ≡ x ≤ z ∧ y ≤ z.

(42)

The associated concrete algebra will be called minimax algebra. Deriving the many laws for ∨ and ∧ , by themselves or in combination with other arithmetic operators, is a simple exercise in high school algebra. Some representative laws are derived in [4, Chap. 8]. We define binary algebra as the restriction of minimax algebra to the binary (2-valued) set B := {0, 1} and note that (42) can be rewritten as arithmetic equalities: (z ≤ x ∧ y) = (z ≤ x) ∧ (z ≤ y) and

(x ∨ y ≤ z) = (x ≤ z) ∧ (y ≤ z).

In fact, now the logical operators can be seen as restrictions of operators on R to B. More specifically: ∧, ∨, ≡ and ⇒ are restrictions of ∧, ∨, = and ≤ respectively to B. All laws of minimax algebra thereby particularize to laws over B, for instance z ⇒ x ∧ y ≡ (z ⇒ x) ∧ (z ⇒ y) and

x ∨ y ⇒ z ≡ (x ⇒ z) ∧ (y ⇒ z).

136

Form Methods Syst Des (2010) 37: 95–140

Table 3 Truth tables for the sixteen dyadic binary functions x, y

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0,0

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0,1

0

0

1

1

0

0

1

1

0

0

1

1

0

0

1

1

1,0

0

0

0

0

1

1

1

1

0

0

0

0

1

1

1

1

1,1

0

0 − ∨

0

0

0

0

0

0 − ∧

1

1

1

1

1

1

1

1

∧

≡



⇒



⇐

∨

∧

=



≤



≥

∨

B

R




≡ /




=

The truth tables in Table 3 summarize this particularization for the 16 dyadic functions fi : B2 → B for i : 0 .. 15. The value of fi (x, y) appears in column i and row (x, y). Note in passing that “binary” obviously is not a good synonym for “dyadic” (argument pair). We conclude with two educational remarks. (a) By its simplicity, binary algebra can be presented in grade school even before arithmetic. Of course, then one does not start with R but with 0 and 1 via truth tables similar to the addition and multiplication tables taught later. (b) The symbolic formulation of the algebraic laws are an exercise in high school algebra.

Appendix B: The elastic limit operator This appendix provides just excerpts from the expositions in [24, 27]. The terminology is derived from [60]. An auxiliary definition is adherence, defined as a set transformer. def Ad : P R → P R with Ad S = {v : R | ∀ : R>0 . ∃ x : S . |x − v| < }. The concept of a limit is captured by the relation islim defined by / R)  f → R × Ad (D f ) → B def —islim—0 — : (R →

with L islimf a ≡ ∀ : R>0 . ∃ δ : R>0 . ∀x : D f . |x − a| < δ ⇒ |f x − L| < . Legend [23]: S  v → Tv is syntactic sugar for × v : S . Tv . It can be shown that ! (islimf a), where the uniqueness operator is defined by ! P ≡ ∀(x, y) : (D P )2 . P x ∧ P y ⇒ x = y. On this basis, we define the elastic limit operator by / R)  f → {a : Ad (D f ) | ∃ b : R . b islimf a} → R def lim : (R →

with ∀f : D lim . ∀a : D (lim f ).(lim f a) islimf a.