3BA31 Formal Methods 31 λ -Calculus: Syntax We have an infinite set Vars , of variables: ∈ u , v , x , y , z , . . . , x 1 , x 2 , . . . Vars We define the set of well-formed λ -calculus expressions LExpr as the smallest set of strings matching the following syntax: M , N , . . . ∈ LExpr ::= v | ( λ x • M ) | ( M N ) Read: a λ -calculus expression is either (i) a variable ( v ); (ii) an abstraction of a variable from an expression ( λ x • M ); or (iii) an application of one expression to another ( ( M N ) ). 3BA31 Formal Methods 32 λ -Calculus: Free/Bound Variables • A variable occurrence is free in an expression if it is not mentioned in an enclosing abstraction . • A variable occurrence is bound in an expression if is mentioned in an enclosing abstraction . • A variable occurrence is binding in an expression if is the variable immediately after a λ . • A variable is free in an expression if it occurs free in that expression. • A variable is bound in an expression if it occurs bound in that expression. A variable can be both free and bound in the same expression (how?)
� 3BA31 Formal Methods 33 λ -Calculus: Computing Free/Bound Vards We can define functions that return the sets of free and bound variables: FV : LExpr → P Var FV ( x ) { x } = � FV ( λ x • M ) = FV ( M ) \ { x } � FV ( M N ) = FV ( M ) ∪ FV ( N ) � BV : LExpr → P Var BV ( x ) = ∅ � BV ( λ x • M ) BV ( M ) ∪ { x } = � BV ( M N ) = BV ( M ) ∪ BV ( N ) � 3BA31 Formal Methods 34 λ -Calculus: α -Renaming We can change a binding variable and its bound instances provided we are careful not to make other free variables become bound. α ( λ x • ( λ y • ( x y ))) �→ ( λ u • λ v • ( u v ))) α ( λ x • ( x y )) �→ ( λ y • ( y y )) formerly free y has been “captured” ! This process is called α -Renaming or α -Substitution, and leaves the meaning of a term unchanged.
� 3BA31 Formal Methods 35 λ -Calculus: Substitution We define the notion of substituting an expression N for all free occurrences of x , in another expression M , written: M [ N / x ] subs ( x ( λ y • ( z y )))[( λ u • u ) / z ] �→ ( x ( λ y • (( λ u • u ) y ))) subs ( x ( λ y • ( z y )))[( λ u • u ) / y ] �→ ( x ( λ y • ( z y ))) y was not free anywhere 3BA31 Formal Methods 36 λ -Calculus: Careful Substitution! When doing (general) substitution M [ N / x ] , we need to avoid variable “capture” of free variables in N , by bindings in M : subs ( x ( λ y • ( z y )))[( y x ) / z ] �→ ( x ( λ y • (( y x ) y ))) If N has free variables which are going to be inside an abstraction on those variables in M , the we need to α -Rename the abstractions to something else first, and the substitute: ( x ( λ y • ( z y )))[( y x ) / z ] α �→ ( x ( λ w • ( z w )))[( y x ) / z ] subs �→ ( x ( λ w • (( y x ) w ))) The Golden Rule: A substitution should never make a free occurrence of a variable become bound, or vice-versa.
3BA31 Formal Methods 37 λ -Calculus: β -Reduction We can now define the most important “move” in the λ -calculus, known as β -Reduction: β ( λ x • M ) N �→ M [ N / x ] We define an expression of the form ( λ x • M ) N as a “( β − )redex” ( red ucible ex pression). 3BA31 Formal Methods 38 λ -Calculus: Normal Form An expression is in “Normal-Form” if it contains no redexes. The object of the exercise is to reduce an expression to its normal-form ( if it exists ). ((( λ x • ( λ y • ( y x ))) u ) v ) β �→ ( λ y • ( y u )) v ) β �→ ( v u ) Not all expressions have a normal form — e.g.: (( λ x • ( x x )) ( λ x • ( x x ))) What about: ( ( ( λ x • ( λ y • y ))) (( λ x • ( x x )) ( λ x • ( x x )) ) w ) ?
3BA31 Formal Methods 39 λ -Calculus: Reduction Order The question is, if we have a choice of redexes, which should we reduce first. Answer: always the leftmost-outermost one (Normal Order Reduction). If an expression has a normal form, then normal order reduction is guaranteed to find it. 3BA31 Formal Methods 40 Scribbles 2 : Binding, Bound and Free! bnd bnd bnd of of bnd bnd free of bnd free x y x y x z z y ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ( λ x • ( λ y • x y )) ( x ( λ z • z y ))
3BA31 Formal Methods 41 Scribbles 2 : Binding, Bound and Free! bnd of free bnd y x y ↓ ↓ ↓ ( λ y • x y ) 3BA31 Formal Methods 42 Scribbles 2 : α -Renaming Consistent changing of bound variables leaves meaning unchanged: ( λ x • xx ) ( u ) = ( u u ) ( λ y • yy ) ( u ) = ( u u ) Analagous to the following definitions of f being equivalent: 1 + x 2 f ( x ) = 1 + y 2 f ( y ) =
3BA31 Formal Methods 43 Scribbles 2 : β -Reduction N M � �� � (( λ x • ( λ y • y )) u ) v ↓ β ( λ y • y ) v ↓ β v 3BA31 Formal Methods 44 Scribbles 2 : Monster ( λ x • x x ) ( λ x • x x ) = monster monster = ( λ x • x x ) ( λ x • x x ) β ↓ β ( monster �→ monster ) ( λ x • x x ) ( λ x • x x ) = monster
3BA31 Formal Methods 45 Scribbles 2 : Reducing Big Expression (1) (( λ x λ y • y ) monster ) w ↓ β (( λ x λ y • y ) monster ) w ↓ β (( λ x λ y • y ) monster ) w ↓ β . . . 3BA31 Formal Methods 46 Scribbles 2 : Reducing Big Expression (2) (( λ x λ y • y ) monster ) w ↓ β ( λ y • y ) w ↓ β w
� � 3BA31 Formal Methods 47 Scribbles 2 : Reduction Order Example (1) f ( x ) = x 2 f (3 + 7) f (3 + 7) = (3 + 7) 2 = f (10) = 10 2 = 10 2 = 100 = 100 3BA31 Formal Methods 48 Scribbles 2 : Reduction Order Example (2) f = λ x • x 2 ( λ x • x 2 )((+3)7) � � � ������������ � � β β � � � � � � � � ((+3)7) 2 ( λ x • x 2 )10 � � ��������� � � β β � � � � � � � 10 2 10 2
3BA31 Formal Methods 49 Sugaring The Pill The lambda calculus rapidly gets unwieldy. ( ( ( λ x • ( λ y • y ))) (( λ x • ( x x )) ( λ x • ( x x )) ) w ) !! It’s worth adding a little syntactic sugar to make it easier to use. 3BA31 Formal Methods 50 Too Many Brackets, etc. 1. We don’t bracket every abstraction or application: we assume the scope of an abstraction goes as far to the right as possible. 2. We change ( M N ) P to M N P , but leave M ( N P ) as is. 3. We drop intermediate λ and dots in nested abstractions 0 ((( λ x • ( λ y • y ))(( λ x • ( x x ))( λ x • ( x x )))) w ) 1 (( λ x • λ y • y )(( λ x • x x )( λ x • x x ))) w 2 ( λ x • λ y • y ) (( λ x • x x )( λ x • x x )) w 3 ( λ x y • y ) (( λ x • x x )( λ x • x x )) w These conventions support concise multiple abstraction/application: β ( λ x y • M ) N �→ λ y • M [ N / x ] β ( λ x y • M ) N P �→ ( M [ N / x ])[ P / y ] M [ N / x ][ P / y ] or
3BA31 Formal Methods 51 Definitions It is convenient to be able to give names to expressions, using a definition notation (Symbol � = means “is defined equal to”): ( λ x • x x )( λ x • x x ) Ω = � = λ z s • z � Z = λ n z s • s ( n z s ) � S = λ x • M ↔ = M We sometimes like to to do the following transformation: N � N x � = � Z s z z = s ( n s z ) � S n s z You can use brackets if it makes you feel more comfortable: Z ( s )( z ) = z S ( n )( s )( z ) = s ( n ( s )( z )) 3BA31 Formal Methods 52 Computable ? Show me Numbers ! Ok. We think of a number as a function of two arguments, the first a function that adds one (successor), the second representing zero: 0 � = λ s z • z 0 s z � = z 1 � = λ s z • s z 1 s z � = s z = λ s z • s ( s z ) 2 � 2 s z � = s ( s z ) 3 � = λ s z • s ( s ( s z )) 3 s z � = s ( s ( s z )) . . . These are the so-called “Church Numerals”
3BA31 Formal Methods 53 Count the s s, Duh ! What about addition, etc? No problem. = λ n s z • s ( n s z ) � SUCC λ m n s z • m s ( n s z ) = � PLUS = λ m n s • n ( m s ) � TIMES = λ m n • n m � EXP We can encode booleans, if-then-else and propositional logic operators (and,or,not) as well. 3BA31 Formal Methods 54 Serious Sugar: infix notation We can now consider adding in some operator symbols written in infix form: M + N = � PLUS M N M · N = � TIMES M N M ˆ N = � EXP M N We will have to adopt some suitable convention regarding operator precedence and bracketing. So now we can write things like: = x ˆ2 + x · ( x + y ) F x y �
3BA31 Formal Methods 55 Mini-Exercise 1 Show that β �→ 2 + 2 4 Hints: 1. Use rightmost-innermost reduction order here. 2. You might want to pull an inner redex out, do the reduction separately, and then plug the result back in. β 3. Try 1 + 1 �→ 2 as a warm-up! Due: at start of 12noon Lecture, Thursday, February 15th, 2007. 3BA31 Formal Methods 56 Motivating Types All the syntactic sugar to date has in principle been convertible back to original λ -calculus expressions. So, ( λ m n s • n ( m s )) ( λ s z • s ( s ( s z ))) ( λ t f • t ) looks innocent enough. But if we interpret λ t f • t as True (“Church Booleans”), then the above, if sugared, is 3 · True The (untype) λ -calculus expression will reduce, but not to a normal form that is a sensible number or boolean. Wouldn’t it be nice to have types?
3BA31 Formal Methods 57 Typed λ -Calculus We define types ( Type ) to be either basic-types ( BType or function types: s , t , . . . ∈ BType σ, τ ∈ Type ::= s | σ → τ We can add type annotations to the variables in the lambda calculus: x : τ We can then give typing rules: • If M : σ , then ( λ x : τ • M ) : τ → σ . • If M : σ → τ and N : σ , then ( M N ) : τ . Typed λ -calculus is different from the un-typed variety — they cannot be inter-converted. 3BA31 Formal Methods 58 Sugared Typed- λ -calculus We can then add in a range of syntactic sugar for types, basic and compound: N , Z , Q , × , ∗ and extend the expression notation: 37 , − 35 , 46 . 13 , (13 , 23) , � 1 , 2 , 3 � We can now write definitions like: Q ∗ → N : length = if null seq then 0 else 1 + ( length ( tail seq )) � length seq Look vaguely familiar? !?!?!! Recursion ! How did that get there ? (Later)
3BA31 Formal Methods 59 Haskell • Pure, lazy functional language i.e. well-sugared typed λ -calculus. • Named for logician Haskell B. Curry • Many multiple-platform implementations: – compilers — GHC, yhc, nbc, . . . – interpreters — Hugs, WinHugs . • www.haskell.org 3BA31 Formal Methods 60 Haskell: Basic Types, Constants and Operators As expected, Haskell supports all the usual basic types: Format Type, Values, Operators, Example Expression. Boolean Bool , True , False , not , && , || , not False && (True || b) Integers Int , 0 , 10 , -34 , + , - , * , / , 3 * (23 - 16 * i) Floating-Point Float , Double , 0.0 , 1.23E+5 , + , - , * , / , 3.14159 * (23E-3 - 1.6 * r) Characters Char , ’a’ , ’B’ , ’\n’ , ’\xd’ , ord , chr , isAlpha , ord c - ord ’0’
3BA31 Formal Methods 61 Haskell: Composite Types Assume s , t and u are pre-existing types. Function Types s -> t , f x = x * x , \ y -> y+3 , . , map , foldl , (f . g) 3 Tuples (s,t) , (s,t,u) , (1,True) , (’a’,42) , fst , snd , (fst(True,999),snd(False,42)) Lists [t] , [] , [1,1,2,3,5,8] , : , length , head , tail , ++ , tail ([1,2,3]++[4,5,6]) Strings String is synonym for [Char] , "" is really [] , while "abc" is syntactic sugar for [’a’,’b’,’c’] . 3BA31 Formal Methods 62 Haskell: Scripts A Haskell programme (or script ) has the following general format: module ModuleName where import Import1 . . . list of definitions A definition is typically of a function, of the form: fname arg1 . . . argn = expression defining function
3BA31 Formal Methods 63 Haskell: Demo 3BA31 Formal Methods 64 Scribbles 3 : Reducing SUCC 2 SUCC 2 = ( λ n s z • s ( n s z )) ( λ s z • s ( s z )) β �→ λ s z • s (( λ s z • s ( s z )) s z ) β �→ λ s z • s (( λ z • s ( s z )) z ) β �→ λ s z • s ( s ( s z )) = 3
3BA31 Formal Methods 65 Scribbles 3 : SUCC 2 , one step in detail ( λ s z • s ( s z )) s β β �→ “using law ( λ x • M ) N �→ M [ N / x ] , where x is s , M is λ z • s ( s z ) and N is s ” ( λ z • s ( s z ))[ s / s ] = “by definition of substitution” λ z • s ( s z ) 3BA31 Formal Methods 66 VDM ♣ “VDM” stands for the Vienna Development Method — Result of work the in the Vienna Research Laboratory of IBM (1960s). VDM is now a standardised formal-method (VDM-SL — Specification Language): • reasoning based on the Logic of Partial Functions (LPF) • based on the notion of specifiying programs via pre- and post-condition predicates. • http://en.wikipedia.org/wiki/Vienna Development Method VDM ♣ is a non-standard dialect of VDM: • based on equational reasoning, rather than LPF. • uses pre-condition predicates, but most specifications give an abstract definition of the computed result (called explicit post-conditions in VDM-SL) • http://www.cs.tcd.ie/Andrew.Butterfield/IrishVDM/ The way in which the mathematics is used to reason about systems is very similar in both VDM-SL and VDM ♣ .
3BA31 Formal Methods 67 The “Method” in VDM ♣ : Requirements • capture the “users” expectations of the behaviour of the system to be built. • model of the environment , or the “World”. • model of the desired interactions between system and environment • This process requires building a model of the problem domain, and is often referred to as Domain Modelling or Domain Capture . 3BA31 Formal Methods 68 The “Method” in VDM ♣ : Specifications • a description of the behaviour the system must have in order to satisfy the requirements. • a model of the system to be built • the process of ensuring that a specification is consistent w.r.t the requirements is called Validation The VDM method says relatively little about validation, as this is very probelm-specific. VDM methodology does ensure that the specification makes sense, (even it if not what the users wanted !). VDM/ VDM ♣ uses its mathematics to model the pertinent parts of the system and environment (as state) and then specifies the safety conditions and operations that the system must maintain and provide. System = State + Operations
3BA31 Formal Methods 69 The “Method” in VDM ♣ In order to produce a formal model according to the Vienna Development Method , we need to: • Determine the System State – State Type – State Invariant – Initial State • Describe the Operations – Operation Pre-Condition – Operation Post-Condition • Discharge all Proof Obligations 3BA31 Formal Methods 70 The “Method” in VDM ♣ : Proof Obligations • Proof obligation is a required property of a VDM model. • Typically capture idea that model “makes sense”. • Method compliance the successful proof of every Proof Obligation. • They don’t guarantee that what a model is realistic, or what the “customer” wanted. Note: In addition to the method proof obligations, we may want to prove that other properties hold, related to our particular application.
3BA31 Formal Methods 71 The “Method” in VDM ♣ : System State System state contains all the relevant values and conditions of the system. We define it by first declaring its components and their structure, using the types and type constructors of VDM ♣ : m Σ ∈ State = ( expression using N , B , . . . , × , P , → , � → , → , . . . , ADTs ) Relationships and conditions of the state that always hold true (often called safety properties) are captured by an invariant: inv- State : State → B inv- State Σ = � . . . Proof Obligation: State Invariant Satisfiability : We must prove that the invariant is satisfiable, i.e there is at least one instance of the state datatype that satisfies it. ∃ Σ : State • inv- State Σ 3BA31 Formal Methods 72 The “Method” in VDM ♣ : Initial State We generally need to introduce the notion of an initial or starting state, at least of any system we are proposing to build: Σ 0 : State Σ 0 = . . . � Proof Obligation: Initial-State Invariant : We must prove that the initial state satisfies the invariant: inv- State Σ 0 = T RUE Note that a proof of this obligation is also a proof of the Invariant Satisfiability obligation (why?)
3BA31 Formal Methods 73 The “Method” in VDM ♣ : Operations • Capture events that change or observe the system state – initiated by the system, or – by the environment. • Have inputs and outputs • cause state changes • Two main classes of operations: – state change: no outputs, but state changes – state enquiry: outputs, but state is unchanged An operation with outputs that changes state as well, can be decomposed into two operations, on of each of the above classes. We shall assume all operators have been so decomposed. 3BA31 Formal Methods 74 The “Method” in VDM ♣ : State Change State change operations take input or control parameters of some type ( c ∈ Control ) and produce a change in state. When specifying such (called StChg, say), we need to identify the circumstances under which we consider the operator to be well-defined — the precondition of the operation . We capture this by a declaration with the following signatures and forms: : Control → State → State StChg StChg [ c ]Σ = � expression defining after-State : Control → State → B pre-StChg pre- StChg [ c ]Σ = � predicate describing pre-condition Proof Obligation: State Change Invariant We must prove that if the state before change satisfies the invariant, and the pre-condition of the operator holds, that then the invariant holds after the operation has run: inv- State Σ ∧ pre- StChg [ c ]Σ ⇒ inv- State ( StChg [ c ]Σ)
3BA31 Formal Methods 75 The “Method” in VDM ♣ : State Query State query operations take input or query parameters of some type ( q ∈ Query ), look at the state, and return an appropriate result value ( r ∈ Result ) . When specifying such (called StQry, say), we need to identify the circumstances under which we consider the operator to be well-defined — the precondition of the operation . We capture this by a declaration with the following signatures and forms: : Query → State → Result StQry StQry [ q ]Σ = � expression defining query-result : Query → State → B pre-StQry pre- StQry [ q ]Σ = � predicate describing pre-condition There is no specific proof obligation associated with queries, other than the general observation that a query’s result need not be defined or make sense if the pre-condition does not hold. 3BA31 Formal Methods 76 Scribbles 4 : Example Model — Orienteering Event We construct a model of an orienteering event, for competitors using the SportIdent (SI) System. We first introduce the Types: s ∈ SI = N SI (Competitor) Numbers c ∈ Control = N Control Numbers r ∈ Course given set of course identifiers A course has a non-empty list of controls: m → CONTROL + κ ∈ Courses = Course A competitor enters a course: m ω ∈ Entries = → Course SI A competitor runs and collects controls in order (hopefully): m → Control ∗ ω ∈ Runs = SI
3BA31 Formal Methods 77 Scribbles 4 : Orienteering State and Invariant System state is comprised of Courses, Entries and Runs: ( κ, ω, ρ ) ∈ OState = Courses × Entries × Runs � Competitors can only enter courses that are offered (1), and when running must be entered (2), and can only find controls that are out there (3): inv- OState ( κ, ω, ρ ) = rng ω ⊆ dom κ � (1) ∧ dom ρ ⊆ dom ω (2) ∧ controlsof ( ρ ) ⊆ controlsof ( κ ) (3) m → P B ) → P B : ( A controlsof ∪ / ( P elems ( rng α )) controlsof ( α ) = � ∪ / ◦ P elems ◦ rng = controlsof 3BA31 Formal Methods 78 Scribbles 4 : Orienteering Initial State Initially everything is empty: : O 0 OState = ( θ, θ, θ ) � O 0 This satisfies the invariant, and so we discharge two proof obligations: inv- OState ( θ, θ, θ ) = rng θ ⊆ dom θ ∧ dom θ ⊆ dom θ ∧ controlsof ( θ ) ⊆ controlsof ( θ ) = ∅ ⊆ ∅ ∧ ∅ ⊆ ∅ ∧ ∅ ⊆ ∅ = T RUE controlsof ( θ ) ∪ / ( P elems ( rng θ )) = ∪ / ( P elems ( ∅ ) ∪ / ( ∅ ) ∅ = = =
3BA31 Formal Methods 79 Scribbles 4 : Planning An Event We now introduce an operation to allow the planner to add a course, and we decide to impose no pre-condition, to allow the planner flexibility to change things: ( Course × Controls + ) → OState → OState : Plan Plan ( r , σ )( κ, ω, ρ ) = ( κ † { r �→ σ } , ω, ρ ) � ( Course × Controls + ) → OState → B : pre- Plan pre- Plan ( r , σ )( κ, ω, ρ ) = � T RUE 3BA31 Formal Methods 80 Scribbles 4 : Plan Proof Obligation We have to show that operation Plan preserves the invariant, when its pre-condition holds: inv- OState ( κ, ω, ρ ) ∧ pre- Plan ( r , σ )( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) As the pre-condition is vacuously true, we can drop it: inv- OState ( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ ))
3BA31 Formal Methods 81 Mini-Exercise 2 Does Plan preserve the invariant ? inv- OState ( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) If you think so, give an informal argument as to why. If you think not, give a counter-example showing what goes wrong Due: at start of 12noon Lecture, Thursday, February 15th, 2007. 3BA31 Formal Methods 82 Mini-Exercise 1 Show that β �→ 2 + 2 4 Hints: 1. Use rightmost-innermost reduction order here. 2. You might want to pull an inner redex out, do the reduction separately, and then plug the result back in. β 3. Try 1 + 1 �→ 2 as a warm-up! Due: at start of 12noon Lecture, Thursday, February 15th, 2007.
3BA31 Formal Methods 83 Mini-Solution 1 2 + 2 = PLUS 2 2 = ( λ m n s z • m s ( n s z )) ( λ s z • s ( s z )) ( λ s z • s ( s z )) β �→ ( λ n s z • ( λ s z • s ( s z )) s ( n s z )) ( λ s z • s ( s z )) β �→ λ s z • ( λ s z • s ( s z )) s (( λ s z • s ( s z )) s z ) β �→ λ s z • ( λ s z • s ( s z )) s (( λ z • s ( s z )) z ) β �→ λ s z • ( λ s z • s ( s z )) s ( s ( s z )) β �→ λ s z • ( λ z • s ( s z )) ( s ( s z )) β �→ λ s z • s ( s ( s ( s z ))) = 4 3BA31 Formal Methods 84 Mini-Exercise 2 Does Plan preserve the invariant ? inv- OState ( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) If you think so, give an informal argument as to why. If you think not, give a counter-example showing what goes wrong Due: at start of 12noon Lecture, Thursday, February 15th, 2007.
3BA31 Formal Methods 85 Mini-Solution 2 We’ll do this backwards: 1. Attempt a Proof 2. Test it using QuickCheck 3. Think about the Issue We should really approach this the other way around! 3BA31 Formal Methods 86 Mini-Solution 2: Proof Attempt (I) To Prove: inv- OState ( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) Strategy: we assume the antecedent : inv- OState ( κ, ω, ρ ) in order to show the truth of the consequent : inv- OState ( Plan ( r , σ )( κ, ω, ρ ))
3BA31 Formal Methods 87 Mini-Solution 2: Proof Attempt (II) We assume ( A 1) – ( A 3 ′ ) , expanding definitions of inv- OState and controlsof : ( A 1) rng ω ⊆ dom κ ( A 2) dom ρ ⊆ dom ω ⊆ ( A 3) controlsof ( ρ ) controlsof ( κ ) ( A 3 ′ ) ∪ / ( P elems ( rng ρ ) ∪ / ( P elems ( rng κ ) ⊆ to show inv- OState ( Plan ( r , σ )( κ, ω, ρ )) 3BA31 Formal Methods 88 Mini-Solution 2: Proof Attempt (III) inv- OState ( Plan ( r , σ )( κ, ω, ρ )) ≡ “ definition of Plan ” inv- OState ( κ † { r �→ σ } , ω, ρ ) ≡ “ definition of inv- OState ” rng ω ⊆ dom ( κ † { r �→ σ } ) ∧ dom ρ ⊆ dom ω ∧ controlsof ( ρ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ property of dom and † ” rng ω ⊆ dom κ ∪ { r } ∧ dom ρ ⊆ dom ω ∧ controlsof ( ρ ) ⊆ controlsof ( κ † { r �→ σ } )
3BA31 Formal Methods 89 Mini-Solution 2: Proof Attempt (IV) rng ω ⊆ dom κ ∪ { r } ∧ dom ρ ⊆ dom ω ∧ controlsof ( ρ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ Assumption A1 and S ⊆ T ⇒ S ⊆ T ∪ U , Assumption A2 ” T RUE ∧ T RUE ∧ controlsof ( ρ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ prop. calc., definition of controlsof ” ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( κ † { r �→ σ } ))) ≡ “ alternative form of override: µ †{ a �→ b } = ⊳ − [ a ] µ ⊔{ a �→ b } ” ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( ⊳ − [ r ] κ ⊔ { r �→ σ } ))) 3BA31 Formal Methods 90 Mini-Solution 2: Proof Attempt (V) ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( ⊳ − [ r ] κ ⊔ { r �→ σ } ))) ≡ “ property of rng ” ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( ⊳ − [ r ] κ ) ∪ { σ } ))) ≡ “ property/definition of P f ” ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( ⊳ − [ r ] κ )) ∪ { elems σ } ) “ property/definition of ∪ / ” ≡ ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( ⊳ − [ r ] κ ))) ∪ { elems σ }
3BA31 Formal Methods 91 Mini-Solution 2: Proof Attempt (VI) ∪ / ( P elems ( rng ρ )) ⊆ ∪ / ( P elems ( rng ( ⊳ − [ r ] κ ))) ∪ { elems σ } Uh-Oh ! From (A3’) we can assume ∪ / ( P elems ( rng ρ ) ∪ / ( P elems ( rng κ ) ⊆ But while we are adding in elems σ , we are also potentially taking away whatever controls were mapped to beforehand by r (in term ⊳ − [ r ] κ ). 3BA31 Formal Methods 92 Mini-Solution 2: QuickCheck Test (I) We can encode the model in QuickCheck and test the property [Show Script]
3BA31 Formal Methods 93 Mini-Solution 2: QuickCheck Test (II) The test fails! Scribbles04> test planInvTest Falsifiable, after 1 tests: G [1] ({G|->[0]},{0|->G},{0|->[0]}) 3BA31 Formal Methods 94 Mini-Solution 2: QuickCheck Test (III) The invariant holds to start: inv- OState ( { G �→ � 0 �} , { 0 �→ G } , { 0 �→ � 0 �} ) rng { 0 �→ G } ⊆ dom { G �→ � 0 �} ∧ dom { 0 �→ � 0 �} ⊆ dom { 0 �→ G } = ∧ controlsof ( { 0 �→ � 0 �} ) ⊆ controlsof ( { G �→ � 0 �} ) = { G } ⊆ { G } ∧ { 0 } ⊆ { 0 } ∧ { 0 } ⊆ { 0 } = T RUE But not when we are done: inv- OState ( Plan ( G , � 1 � )( { G �→ � 0 �} , { 0 �→ G } , { 0 �→ � 0 �} )) inv- OState ( { G �→ � 1 �} , { 0 �→ G } , { 0 �→ � 0 �} ) = = rng { 0 �→ G } ⊆ dom { G �→ � 1 �} ∧ dom { 0 �→ � 0 �} ⊆ dom { 0 �→ G } ∧ controlsof ( { 0 �→ � 0 �} ) ⊆ controlsof ( { G �→ � 1 �} ) { G } ⊆ { G } ∧ { 0 } ⊆ { 0 } ∧ { 0 } ⊆ { 1 } = = T RUE ∧ T RUE ∧ F ALSE
3BA31 Formal Methods 95 Mini-Solution 2: Think About It A little thought should lead to the following conclusion: The planner might change a course mid-event, removing some controls, at a point when a runner has already visited them. Nothing in the model said that the planning had to be complete when the event began running. How might we enforce this ? 3BA31 Formal Methods 96 Scribbles 5 : Properties of Maps µ † ν = − [ dom ν ] µ ⊔ ν ⊳ � dom ( µ † nu ) = ( dom µ ) ∪ ( dom ν ) rng ( µ † nu ) ( rng µ ) ∪ ( rng ν ) � = Counter-example: µ = { a �→ 1 } rng µ = { 1 } ν = { a �→ 2 } rng ν = { 2 } µ † ν = { a �→ 2 } rng ( µ † ν ) = { 2 } rng µ ∪ rng ν = { 1 , 2 } { 2 } � = { 1 , 2 }
3BA31 Formal Methods 97 Scribbles 5 : Fixing Plan The solution is a pre-condition that says that planning can go on as long as no-one has entered: pre- Plan ( r , σ )( κ, ω, ρ ) = ω = θ ∧ ρ = θ � Does this preserve the invariant? inv- OState (Σ) ∧ pre- Plan ( r , σ )(Σ) ⇒ inv- OState ( Plan ( r , σ )(Σ)) Will controlsof ( ρ ) remain a subset of controlsof ( κ ) ? 3BA31 Formal Methods 98 Scribbles 5 : Plan Invariant (Thinking) As the entries and runs maps are empty, by the pre-condition, and planning never adds to them, the stay empty once planning has just finished. So controlsof ( ρ ) is always empty and hence a subset of controlsof ( κ ) , no matter how often the planner comes back and changes his mind. It looks good.
3BA31 Formal Methods 99 Scribbles 5 : Plan Invariant (Testing) We should run this through QuickCheck again [Script]: Scribbles05> test planInvTest OK, passed 100 tests. It passes (eventually). 3BA31 Formal Methods 100 Scribbles 5 : Plan Invariant (Proving–I) We assume ( A 1) – ( A 4) , expanding definitions of inv- OState and controlsof : ( A 1) rng ω ⊆ dom κ ( A 2) dom ρ ⊆ dom ω ( A 3) controlsof ( ρ ) ⊆ controlsof ( κ ) ( A 3 ′ ) ∪ / ( P elems ( rng ρ ) ∪ / ( P elems ( rng κ ) ⊆ ( A 4) ω = θ ∧ ρ = θ to show inv- OState ( Plan ( r , σ )( κ, ω, ρ )) which by (A4) is the same as: inv- OState ( Plan ( r , σ )( κ, θ, θ ))
3BA31 Formal Methods 101 Scribbles 5 : Plan Invariant (Proving–II) inv- OState ( Plan ( r , σ )( κ, θ, θ )) ≡ “ definition of Plan ” inv- OState ( κ † { r �→ σ } , θ, θ ) ≡ “ definition of inv- OState ” rng θ ⊆ dom ( κ † { r �→ σ } ) ∧ dom θ ⊆ dom θ ∧ controlsof ( θ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ A null map has empty domain and range: dom θ = ∅ = rng θ ” ∅ ⊆ dom ( κ † { r �→ σ } ) ∧ ∅ ⊆ ∅ ∧ controlsof ( θ ) ⊆ controlsof ( κ † { r �→ σ } ) 3BA31 Formal Methods 102 Scribbles 5 : Plan Invariant (Proving–III) ∅ ⊆ dom ( κ † { r �→ σ } ) ∧ ∅ ⊆ ∅ ∧ controlsof ( θ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ ∅ ⊆ S , any S , definitions of controlsof ” T RUE ∧ T RUE ∧ ∪ / ( P elems ( rng θ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ prop. calc., rng θ = ∅ ” ∪ / ( P elems ( ∅ ) ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ prop. calc., P f ∅ = ∅ ” ∪ / ( ∅ ) ⊆ controlsof ( κ † { r �→ σ } ) “ ∪ / ∅ = ∅ ” ≡ ∅ ⊆ controlsof ( κ † { r �→ σ } ) ≡ “ ∅ ⊆ S , any S ” � T RUE
3BA31 Formal Methods 103 Scribbles 5 : Other Operations Orienteers can enter for an offered course, and change their mind when not already out running: SI × Course → OState → OState : Register pre- Register ( s , c )( κ, ω, ρ ) = c ∈ dom κ ∧ s / ∈ dom ρ � Register ( s , c )( κ, ω, ρ ) = ( κ, ω † { s �→ c } , ρ ) � An orienteer can run once, once entered: SI × Control ∗ → OState → OState : Run pre- Run ( s , σ )( κ, ω, ρ ) = s ∈ dom ω ∧ s / ∈ dom ρ � ( κ, ω, ρ † { s �→ σ } ) Run ( s , σ )( κ, ω, ρ ) = � A competitor is complete if they got precisely the controls on their course: : SI → OState → B Complete Complete ( s )( κ, ω, ρ ) = κ ( ω ( s )) = ρ ( s ) � 3BA31 Formal Methods 104 Haskell Features We take a brief look at some important Haskell features: • Lists • Type Polymorphism • ADTs (Abstract Data Types) • Namespaces • Function and Operator Fixity
3BA31 Formal Methods 105 Lists (I) Lists are a major datatype in Haskell: Type We use the notation [t] to denote a list whose elements are of type t . Constructing Values There are two basic ways to define a list: • We write the empty list as [] . It has type [t] for any type t . • Given an element x of type t and a list xs of type [t] , we can stick the element on the front (“cons-ing”), written x:xs — the infix colon : is the list constructor. Accessing Values There are two ways to get at the components of a list: • Using functions null , head and tail • Pattern matching on the two ways to build a list. 3BA31 Formal Methods 106 Lists (II) Functions null , head and tail can be defined by pattern matching: null [] = True null (x:xs) = False head (x:xs) = x tail (x:xs) = xs Note that head and tail are partial, being undefined for the empty-list. The list enumeration notation [ x 1 , x 2 , . . . , x n ] is syntactic sugar for x 1 : ( x 2 : ( . . . ( x n : []) . . . )) There are a long list of functions available for list manipulation —see the Haskell “Prelude” http://haskell.org/onlinereport/standard-prelude.html .
3BA31 Formal Methods 107 Type Polymorphism (I) Consider the list length function: length [] = 0 length (x:xs) = 1 + length xs What type does it have? [ D EMO : Taking List Lengths ] 3BA31 Formal Methods 108 Type Polymorphism (II) The function length works with lists of any type, and returns an Integer: length :: [t] -> Int . This works because it does not manipulate the elements in any way, but simply counts them. Polymorphic (“many-shaped”) types are simply types with parts, represented by type variables, that can take on any type (Haskell uses letters a , b , c ,. . . for these). E.g. function reverse :: [t] -> [t] takes a list of any type and reverses it to give a list of the same type.
3BA31 Formal Methods 109 Abstract Data Types (I) We can build our own datatypes by describing them as a collection of Constructors that build a value of the type from other types. General framework: = C 1 t 11 t 12 · · · t 1k 1 data MyType | C 2 t 21 t 22 · · · t 2k 2 . . . | C n t n1 t n2 · · · t nk n Here all the k i , for i ∈ 1 . . . n can be zero or more. This is read as declaring MyType to be either a C 1 built from t 11 through to t 1k 1 , or a C 2 built . . . The names MyType can appear as one of more of the t ij (Recursive types allowed). 3BA31 Formal Methods 110 Abstract Data Types (II) We can define functions on these by pattern-matching: :: MyType − > AnotherType f f ( C 1 p 11 p 12 · · · p 1k 1 ) = what to do with C 1 variant f ( C 2 p 21 p 22 · · · p 2k 2 ) = what to do with C 2 variant . . . f ( C n p n1 p n2 · · · p nk n ) = what to do with C n variant Here p ij is a pattern matching a value of type t ij .
3BA31 Formal Methods 111 Abstract Data Types (III) Example 1 - Days of the Week. All the k i can be zero: data Day = Mon | Tue | Wed | Thu | Fri | Sat | Sun isWeekDay :: Day -> Bool isWeekDay Sat = False isWeekDay Sun = False isWeekDay _ = True The pattern is a wildcard and matches anything. Patterns are tried in the order listed. 3BA31 Formal Methods 112 Abstract Data Types (IV) Example 2 - Binary Tree of Integers data BinTreeInt = LeafI Int | BranchI BinTreeInt Int BinTreeInt btiSize (LeafI _) = 1 btiSize (BranchI left _ right) = 1 + btiSize left + btiSize right So the following is a value of type BinTreeInt BranchI (LeafI 1) 2 (LeafI 3)
3BA31 Formal Methods 113 Abstract Data Types (V) Example 2 - Binary Tree of anything We can put a type parameter (type variable) immediately after the name of our type, which can then be used as on of the t ij . data BinTree t = Leaf t | Branch (BinTree t) t (BinTree t) btSize (Leaf _) = 1 btSize (Branch left _ right) = 1 + btSize left + btSize right So the following is a value of type BinTree Char Branch (Leaf ’a’) ’b’ (Leaf ’c’) 3BA31 Formal Methods 114 Namespaces In Haskell we can classify identifier tokens into two types: • Those starting with lowercase alpha followed by alphanum: a , b1 , idWithCapSepWords , identifier with underscores . These are used for names of functions and variables/values • Those starting with uppercase alpha followed by alphanum: A , B1 , True , Leaf , Branch These are used as names of Types and Type-/Data-Constructors
3BA31 Formal Methods 115 Function and Operator Fixity In Haskell we write function/operators in two ways: • conventional identifiers (lowercase alpha followed by alphanum: a , b1 , idWithCapSepWords , identifier with underscores . These are prefix function names by default. • Symbols (“funny” characters) ++ , <= , : , $!$ , $ , =:::= . These are infix operator names by default. Prefix function names (of arity 2) and infix operators can be converted into each other as follows: Normal Use Converted Use f a b a ‘f‘ b a + b (+) a b 3BA31 Formal Methods 116 Type Classes in Haskell Haskell allows us to define the notion of type classes: • A class defines a number of functions/values over types of that class • A type is an instance of a class if instances of those functions and values are defined for that type • Type-classes support ad-hoc overloading — the use of a single symbol to represent a number of different but related functions.
3BA31 Formal Methods 117 Class Example: Eq uality Assume we have builtin functions defining equality for various basic types: primitive primEqChar :: Char -> Char -> Bool primitive primEqInt :: Int -> Int -> Bool primitive primEqFloat :: Float -> Float -> Bool We define a class Eq (equality) which requires a symbol == to be defined: class Eq a where (==), (/=) :: a -> a -> Bool -- Minimal complete definition: (==) or (/=) x == y = not (x/=y) x /= y = not (x==y) We can now define instances of == for Char , Int and Float : instance Eq Char where (==) = primEqChar instance Eq Int where (==) = primEqInt instance Eq Float where (==) = primEqFLoat We can now use == to denote equality between these different types. 3BA31 Formal Methods 118 More Eq uality We can define class instances which depend on others. For example, given any type of class Eq (i.e. for which == is defined), we can define equality over lists of that type: instance Eq a => Eq [a] where [] == [] = True (x:xs) == (y:ys) = x==y && xs==ys _ == _ = False Given previous definitions, this now means == can be used with arguments of type [Char] , [Int] , [Float] . Indeed we can nest such instances, so equality is now also defined for [[Char]] , [[[Int]]] , etc. In Haskell, == is predefined for all its builtin-types, (except for functions).
3BA31 Formal Methods 119 Class Example: Ord ering A class definition can depend on another — consider the ordering class Ord which defines <= , >= , among others. We have an ordering result type Ordering , and again some builtin comparison operators: data Ordering = LT | EQ | GT primitive primCmpChar :: Char -> Char -> Ordering primitive primCmpInt :: Int -> Int -> Ordering primitive primCmpFloat :: Float -> Float -> Ordering We define the class Ord as follows: class (Eq a) => Ord a where compare :: a -> a -> Ordering (<), (<=), (>=), (>) :: a -> a -> Bool max, min :: a -> a -> a .... details omitted .... The complete definition allows us to define everything in terms of either compare or < . 3BA31 Formal Methods 120 Class Example: Show There is a class Show concerned with converting a value into a printable string: class Show a where showsPrec :: Int -> a -> ShowS show :: a -> String showList :: [a] -> ShowS -- Mimimal complete definition: -- show or showsPrec showsPrec _ x s = show x ++ s A value needs to be of class Show in order for Hugs to show it.
3BA31 Formal Methods 121 Deriving Instances For certain builtin classes ( Eq , Ord , Show ) we can ask the compiler to automatically generate instances for out ADTs: data BinTreeInt = LeafI Int | BranchI BinTreeInt Int BinTreeInt deriving (Eq,Ord,Show) Haskell will define equality in the “obvious” way, and come up with an ordering where a Leaf is less than a Branch . Values of type BinTreeInt will print as we would write them in Haskell. 3BA31 Formal Methods 122 Class Example: Numbers There are a range of classes defining different aspects of numbers. The most prevalent is Num : class (Eq a, Show a) => Num a where (+), (-), (*) :: a -> a -> a negate :: a -> a abs, signum :: a -> a fromInteger :: Integer -> a -- Minimal complete definition: -- All, except negate or (-) x - y = x + negate y negate x = 0 - x
3BA31 Formal Methods 123 VDM ♣ in Haskell We can encode VDM ♣ expressions (Sets, Maps, etc) in Haskell • IVDM Haskell Module, importing: – IVDM Set , defining (finite) sets in Haskell; – IVDM Map , defining (finite) maps in Haskell; – IVDM Rel , defining (finite) relations in Haskell. We can use Haskell to evaluate such expressions Haskell acts as an VDM ♣ “Calculator”. We cannot use Haskell to prove properties, but we will be able to use it to test them (using a package called QuickCheck ). The Haskell implementation makes use of the class system, in particular requiring set and map elements to belong to the Eq and Ord classes. 3BA31 Formal Methods 124 VDM ♣ Types in Haskell Let A , B and C denote VDM ♣ types, and a , b and c be the corresponding Haskell types. The following VDM ♣ types have the following direct counterparts in Haskell: VDM ♣ Type Haskell B Bool Boolean N Integer , Int (non-negative) Naturals Z Integer , Int Integers Q Float , Double Rationals R Float , Double (finite approximations) Reals A Char Characters ∗ [a] Sequences A A × B (a,b) Pairs A × · · · × C (a,..,c) Tuples A → B Functions a -> b
3BA31 Formal Methods 125 Sets in Haskell Module: IVDM Set Defines sets and operations for any Haskell instances of the Ord class. VDM ♣ type P A represented by Haskell type Set a . The resulting sets are themselves instances of Ord , so we can define sets of sets, etc. Many set operators have Haskell counterparts: VDM ♣ VDM ♣ VDM ♣ Haskell Haskell Haskell ∅ { x } ∈ nullSet iSet x mOf ∪ ∩ △ union intersect symdiff op / # P f card sreduce (op,id) smap f 3BA31 Formal Methods 126 Set Examples Let S 1 , S 2 , . . . denote VDM ♣ sets while s1 , s2 , . . . denote their Haskell counterparts. VDM ♣ Haskell S 1 ∪ S 2 ∩ S 3 s1 ‘union‘ s2 ‘intersect‘ s3 x ∈ S 1 x ‘mOf‘ s1 − [ S 1 ] S 2 ⊳ sremove s1 s2 ( + / ◦ P #) S 1 (sreduce ((+),0) . smap card) s1 { 1 , 3 , 5 } iSet 1 ‘union‘ iSet 3 ‘union‘ iSet 5 elems [1,3,5] Functional composition ( ◦ ) is denoted in Haskell by . [ D EMO : Sets in Haskell ]
3BA31 Formal Methods 127 Maps in Haskell Module: IVDM Map Defines maps and operations for any Haskell instances of the Ord class. VDM ♣ type A m → B represented by Haskell type Map a b . The resulting maps are themselves instances of Ord , so we can define maps of maps, etc. Many map operators have Haskell counterparts: VDM ♣ VDM ♣ VDM ♣ Haskell Haskell Haskell θ { x �→ y } ⊔ nullMap iMap x y mextend † − [ S ] override ⊳ mremove s ⊳ [ S ] mrestrict m → g dom rng rng mmap f g dom f 3BA31 Formal Methods 128 Map Examples Let µ 1 , µ 2 , . . . denote VDM ♣ maps while m1 , m2 , . . . denote their Haskell counterparts. VDM ♣ Haskell µ 1 † µ 2 ⊔ µ 3 m1 ‘override‘ m2 ‘mextend‘ m3 x ∈ dom µ 1 x ‘mOf‘ (dom m1) − [ S 1 ] µ 2 ⊳ mremove s1 m2 m ( f → g ) µ 1 mmap f g m1 { 1 �→ ‘a’ , 5 �→ ‘e’ } iMap 1 ’a’ ‘mextend‘ iMap 5 ’e’ mkMap [(1,’a’),(5,’e’)] Functional composition ( ◦ ) is denoted in Haskell by . [ D EMO : Maps in Haskell ]
3BA31 Formal Methods 129 Modelling Example (1) Consider a simple model of a spell-checking Dictionary: D ∈ Dict = P Word : D 0 Dict = ∅ � D 0 We can model this in Haskell as type Wrd = String type Dict = Set Wrd d0 :: Dict d0 = nullSet 3BA31 Formal Methods 130 Modelling Example (2) We define an operation to insert a word into the dictionary as: : Word → Dict → Dict Ins Ins ( w ) D = D ∪ { w } � The Haskell version: ins :: Wrd -> Dict -> Dict ins w d = d ‘union‘ iSet w
� 3BA31 Formal Methods 131 Modelling Example (3) We can define word lookup: : Word → Dict → B Lkp w ∈ D Lkp ( w ) D = � and the Haskell equivalent: lkp :: Wrd -> Dict -> Bool lkp w d = w ‘mOf‘ d 3BA31 Formal Methods 132 Scribbles 6 : A Binary Tree The binary tree BranchI (LeafI 1) 2 (LeafI 3) can be viewed as BranchI 2 � � �������������� � � � � � � � � � � � � � 1 3 Leaf Leaf
3BA31 Formal Methods 133 How To Build ( VDM ♣ ) Models We are now going to explore how to go about building good formal models of systems of interest. The key notions are: Entities things, concepts, individuals, . . . Collections groups, birds of a feather, . . . Relationships connections, interactions, constraints, “knock-on effects” . . . Adequacy Have we captured all relevant aspects of problem ? 3BA31 Formal Methods 134 Entities • Basic elements of model • What are key attributes: equality ? ordering ? numeric, or identifiers ?
3BA31 Formal Methods 135 Collections • What’s in a collection? • Does order or multiplicity matter ? – Membership ? – Ordering, Priority, Queueing ? – Counting ? Measuring ? • Collections of collections ? 3BA31 Formal Methods 136 Relationships • Multiplicity again — many/one-to-many/one ? • Uniqueness ? • “Intentional” vs “Inherent” ! • Experiment
3BA31 Formal Methods 137 Scribbles 7 : Entity Examples Consider a Birthday Book Example: entities are Persons and Birthdays A Person simply needs a unique identifier, for which the only operation need be an equality check: p ∈ Person = � Id The basic type Id is simply an unbounded set of values to be used as identifiers. For a Birthday, we could give it structure (Day/Month/Year), or simply record the day number (1 . . . 366): b ∈ Birthday = � N Ordering might be useful, to establish which birthday is next. etc. 3BA31 Formal Methods 138 Scribbles 7 : Collection Examples Ordering Multiplicity Example Math. X X Set ( P A ) Class Attendance X Bag/Multiset ( A � → N 1 ) � Balls on Pool Table Unique Sequences ( A ∗ � X Queue ! ) Sequences ( A ∗ ) � � Text String
3BA31 Formal Methods 139 Scribbles 7 : Relationship Examples Multiplicity Examples Math. P ( P × H ) , Many-to-Many Persons to Holiday Dest. P 1 ... m ↔ 1 ... n H P → P H H → P P relation inverse switches between these two P → B many-to-one Person to Birthday P 1 ... n ↔ 1 B S N (here denotes injective fn.) One-to-One Student to Id-No S 1 ↔ 1 N N S An injective function maps different inputs to different outputs: f : A B ∧ f ( a 1 ) = f ( a 2 ) ⇒ a 1 = a 2 3BA31 Formal Methods 140 Mini-Solution 3 Some samples of actual answers will be put here at some point.
3BA31 Formal Methods 141 Formal Model: Reminder of Goals State Type Invariant Initial-State Operations State-Change Build vs. Run State-Query 3BA31 Formal Methods 142 Developing/Determining Relationships • “Intentional” vs “Inherent” ! Intentional: Relationships we want as modellers Inherent: Relationships we obtain from the mathematics • Experiment
3BA31 Formal Methods 143 Experimentation • Pick a structure • Write down examples • Ask — does it make sense ? • If not, figure out how to “stop it happening” Key idea here: “Initialise & Build”. 3BA31 Formal Methods 144 Operations • How does system change? • How do users interact with system? • What do we want to observe about the system? • Under what conditions do certain actions make sense?
3BA31 Formal Methods 145 Adequacy • Have we covered the problem space? • Can we represent all relevant entities? • Can we describe the key collections ? • Have we captured all relationships ? • Do we have descriptions (as Operations) of everything relevant that can happen ? 3BA31 Formal Methods 146 State Construction What do we do if it is not possible to build a safe (invariant preserving) state bit-by-bit ? Issue: can we start with a blank-slate or does the initial system have to be fully formed ?
3BA31 Formal Methods 147 Real Life: BASE Trusted Gateway Goal — Trusted Gateway for transferring messages between different security levels, for British Aerospace Systems & Equipment. Approach — Two teams, one conventional, the other using formal methods. Method — Formal team employed VDM-SL, using IFAD Toolkit. Who — T.M.Brookes, J.S.Fitzgerald & P .G.Larsen, “Formal and Informal Specifications of a Secure System Component” in FME’96: Industrial Benefit and Advances in Formal Methods , Springer-Verlag, LNCS 1051, pp214–227, 1996. 3BA31 Formal Methods 148 BASE: Key Results (1) • Formal approach spent more time up front in System Design (43% as against 34%). • Formal approach uncovered an implicit special condition from requirements. Informal code had to be re-written at late stage to cope. • Formal code was less complex (“McCabe Complexity”) • Formal code one-fifth the size of informal code.
3BA31 Formal Methods 149 BASE: Key Results (2) Formal system started up slower (4 times) 1. Formal System Invariant better understood, so more care was taken by resulting initialisation code. 2. Not a big issue as the system is meant to stay up and running. 3BA31 Formal Methods 150 BASE: Key Results (3) Formal system throughput higher (almost 14 times !) 1. The informal system had to have a last-minute fix, so the code speed got worse. 2. If code is formally verified, then you don’t need so many run-time checks (array bounds, etc.)
3BA31 Formal Methods 151 Scribbles 8 : Modelling the “World Cup” Initial Q&A: • Which countries ? Only those in tournament • Whole tournament,or just knock-out phase? Stick with knock-out phase These choices all impact on initial state and invariant 3BA31 Formal Methods 152 Scribbles 8 : Main Concepts Entities Countries Events Playing a Match Relationships Contest Draw A first stab: c ∈ Country = Id = P Country × . . . � State The state mentions only those countries still in the contest.
3BA31 Formal Methods 153 Scribbles 8 : Modelling the Draw A draw looks like: England Ireland Brazil Samoa � � � ��������� ��������� � � � � � � � � � � � � � � � England Ireland � � ������������������ � � � � � � � � � � � � � � � ? The green entries shows how the contest might evolve ! We see we have a binary tree of slots, where a slot can be empty or contain a country. 3BA31 Formal Methods 154 Scribbles 8 : Badly Drawn An invalid draw might be England Ireland Brazil Brazil � � � �������� � ��������� � � � � � � � � � � � � � Japan � � ������������������ � � � � � � � � � � � � � � � The picture above violates a number of well-formedness conditions: • the winner of a match must be one or other contestant (i.e. not Japan) • a country can only occur once in the draw at a level (Brazil can’t occur twice). We need to find a way to capture this mathematically as an invariant.
3BA31 Formal Methods 155 Scribbles 8 : Attempt 1 — A Binary Tree • The leaf slots (1st round) have countries, while intermediate nodes in the tree may be empty. • We use a tree built from leaf-nodes with a country, and match-nodes with left and right sub-trees, and a slot. • A leaf node is either empty, or identifies the Winning country = L EAF Country | M ATCH Draw Slot Draw � Draw = E MPTY | W INNER Country � Slot 3BA31 Formal Methods 156 Scribbles 8 : Attempt 1 Example M ATCH ( L EAF Ireland ) E MPTY ( L EAF Brazil ) Ireland Brazil � � ��������� � � � � � � � M ATCH ( L EAF Ireland ) ( W INNER Ireland ) ( L EAF Brazil ) Ireland Brazil � � �������� � � � � � � � Ireland . . . which might then be reduced to . . . L EAF Ireland Ireland
3BA31 Formal Methods 157 Scribbles 8 : Attempt 1 Invariant We need to define an invariant that looks (semi-formally) like: invariant ( L EAF ) = T RUE invariant ( M ATCH d 1 slot d 2 ) = invariant d 1 ∧ invariant d 2 slot = E MPTY ∧ ∨ slot = W INNER p where p won d 1 ∨ p won d 2 ∧ countriesof d 1 ∩ countriesof d 2 = ∅ This is a complex invariant. Can it be simplified? One idea is that once a match is decided, we simply replace it by a leaf with the winner, so no slots are required. 3BA31 Formal Methods 158 Scribbles 8 : Attempt 2 — A different Binary Tree • The leaf slots have countries. • We use a tree built from leaf-nodes with a country, and match-nodes with left and right sub-trees. = L EAF Country | M ATCH Draw Draw � Draw
3BA31 Formal Methods 159 Scribbles 8 : Attempt 2 Example M ATCH ( L EAF Ireland ) ( L EAF Brazil ) Ireland Brazil � � � � � � � � � � � � � � � � • . . . which then reduces to . . . L EAF Ireland Ireland 3BA31 Formal Methods 160 Scribbles 8 : Attempt 2 Invariant We need to define an invariant that looks (semi-formally) like: invariant ( L EAF ) = T RUE invariant ( M ATCH d 1 d 2 ) = invariant d 1 ∧ invariant d 2 ∧ countriesof d 1 ∩ countriesof d 2 = ∅ This is a much less complex invariant. The red stuff about slots has disappeared.
3BA31 Formal Methods 161 Scribbles 8 : Countries in Tournament We can easily define the countries involved: : Draw → P Country countriesof countriesof ( LEAF c ) = { c } � ( countriesof d 1 ) ∪ ( countriesof d 2 ) countriesof ( M ATCH d 1 d 2 ) = � We now have to consider the initial state, which should be a tree of uniform depth with distinct countries at leaves. We need to consider a partial operation Play : Draw � → Draw . We can say what it does when a Match has two leaves: Play ( M ATCH ( L EAF c 1 ) ( L EAF c 2 )) = winner ( c 1 , c 2 ) � Here winner is a function that determines the victor (somehow) ! The trick now is to determine which match gets played when. 3BA31 Formal Methods 162 QuickCheck Haskell module for testing properties of Haskell Programs Properties are defined as functions of one or more variables, returning a value of type Bool QuickCheck tests a property (using function test !) by generating random test values for each of its arguments, and then evaluating the property. It repeats this 100 times, or until a False result is returned. In the event of a False result, it prints out the test values that caused the test to fail, otherwise it states that the test was Ok . See http://www.cs.chalmers.se/ ∼ rjmh/QuickCheck/ Simply import QuickCheck to use it.
3BA31 Formal Methods 163 Monomorphism Type Restriction QuickCheck cannot work with functions of polymorphic type (e.g. [a] ), but instead must have a fully specified type (monomorphic), (e.g. [Int] ). This is required because QuickCheck needs to know how to generate and print test values, so it needs a concrete type to work with. 3BA31 Formal Methods 164 Example: Testing List reversal The function reverse :: [a] -> [a] reverses its list argument. If we reverse the list twice, we should get the original back: reverse (reverse xs) == xs We can define such a property for lists as: prop RevRev xs = reverse (reverse xs) == xs This is just a standard Haskell function definition, so it has type prop RevRev :: [a] -> Bool . This is polymorphic, so when we test it we need to give it a concrete type: test (prop RevRev :: [Int] -> Bool) [ D EMO : Testing the Double Reverse Property ]
3BA31 Formal Methods 165 List Reversal, continued If we reverse a list once, we do not get the original back. Let’s test this: prop Rev xs = reverse xs == xs test (prop Rev :: [Int] -> Bool) [ D EMO : Testing the Single Reverse Property ] We see that the failure is indicated by an example of a list which is not equal to its reverse. Properties with a name beginning prop... can be checked automatically by a script called quickCheck (on Unix systems). 3BA31 Formal Methods 166 Generic Properties (I) Sometimes we want a property that we can use with a variety of operators. Consider the property of commutativity - an operator ∗ is commutative if x ∗ y y ∗ x = We can define the property as a function of the operator: pOpComm op x y = x ‘op‘ y == y ‘op‘ x To test it we need to supply the operator, and type information: test (pOpComm (+) :: Int -> Int -> Bool) [ D EMO : Testing commutativity of + ]
3BA31 Formal Methods 167 Generic Properties (II) Consider operator associativity: pOpAssoc op x y z = x ‘op‘ (y ‘op‘ z) == (x ‘op‘ y) ‘op‘ z To test if list concatention is associative ( (++) :: [a] -> [a] -> [a] ) we need to type the following: test (pOpAssoc (++) :: [Int] -> [Int] -> [Int] -> Bool) It is useful to have shorthands defined commonly used property signatures, e.g. type LC3B = [Char] -> [Char] -> [Char] -> Bool Then our test could use character sequences instead: test (pOpAssoc (++) :: LC3B) [ D EMO : Testing associativity of ++ ] 3BA31 Formal Methods 168 Commonly used test types We use the following shorthands: B Bool C Char I Int F Float Lx [x] Sx Set x Mxy Map x y A function Bool->Char->Char->Bool is then given by BCCB . A function with repeated list, set or map types uses a digit to indicate how many, so [Char]->[Char]->[Char]->Bool is denoted by LC3B See IVDM Check for list of types so defined.
3BA31 Formal Methods 169 Using QuickCheck with VDM ♣ Two modules have been defined to integrate QuickCheck with IVDM : • IVDM Check This module describes – how to generate test sets and maps – useful shorthands for commonly used test types – useful generic properties • IVDM Test Use this module to import both QuickCheck and IVDM — it resolves a name-clash ( forAll ) between the modules, by renaming the IVDM version to be for all 3BA31 Formal Methods 170 Common Generic Properties The following generic properties have been defined Name Property x ∗ y = y ∗ x pOpComm x ∗ ( y ∗ z ) = ( x ∗ y ) ∗ z pOpAssoc x ∗ x = x pOpIdem i ∗ x = x = x ∗ i pOpId x ∗ z = z = z ∗ x pOpZero See IVDM Check for a complete list. [ D EMO : Testing properties using IVDM Test ]
3BA31 Formal Methods 171 QuickCheck: Class Arbitrary QuickCheck defines a class called Arbitrary that defines two operators for generating random values of a type: class Arbitrary a where arbitrary :: Gen a coarbitrary :: a -> Gen b -> Gen b The type Gen a denotes something capable of generating random values of a given type — by a mechanism we shall ignore for now. We shall also ignore the coarbitrary function, whose role is quite technical. 3BA31 Formal Methods 172 Type Constructor Gen While the details of how a generator works are complex, there are functions supplied to build generators: choose :: Random a => (a,a) -> Gen a Given type a an instance of the standard Random class, return a random value within bound of first argument elements :: [a] -> Gen a Pick a value at random from a list vector :: Arbitrary a => Int -> Gen [a] Generate a list of arbitrary elements of given length oneof :: [Gen a] -> Gen a Pick a generator at random from a list, and use that sized :: (Int -> Gen a) -> Gen a Takes a generator depending on an integer and generates that integer internally (starts small and gets larger over time).
3BA31 Formal Methods 173 Some Arbitrary Instances We can now show some simple instances of Arbitrary : instance Arbitrary Bool where arbitrary = elements [True, False] instance Arbitrary Int where arbitrary = sized $ \n -> choose (-n,n) instance Arbitrary a => Arbitrary [a] where arbitrary = sized (\n -> choose (0,n) >>= vector) 3BA31 Formal Methods 174 Function test Function test :: Testable a => a -> IO() allow us to run tests on any type belonging to the Testable class. class Testable a where property :: a -> Property We have instances of Testable for Bool , Property , and for a -> b where b is an instance of Testable , and a is an instance of Arbitrary and Show . This latter case means we automatically get testable instances of functions of type a1 -> a2 -> .... -> ab -> Bool , as long as the ai can be generated arbitrarily.
3BA31 Formal Methods 175 What is type Property ? A problem arises when testing implications: P ⇒ Q This is always true when P is false, so benefit arises from test-cases where P does not hold. We have a variation of implication that does not count case where antecedent fails: (==>) :: Testable a => Bool -> a -> Property The Property type is best viewed as a special form of Bool . QuickCheck testing of Property looks for 100 cases where antecedent is true, but gives up after 10,000 attempts. [ D EMO : Testing n = m 2 ⇒ n · m = m 3 ] 3BA31 Formal Methods 176 Exercise (Optional) Read http://www.cs.chalmers.se/ ∼ rjmh/QuickCheck/manual.html
3BA31 Formal Methods 177 Scribbles 9 : Generator Examples choose (1,10) :: Gen Int generate a random integer between 1 and 10 elements [1..10] :: Gen Int as above vector 5 :: Gen [a] generate list of length 5 of arbitrary elements sized vector :: Gen [a] generate list of arbitrary elements of some length, the length chosen starts small and gets larger as this generator is repeatedly used. 3BA31 Formal Methods 178 Scribbles 9 : What is $ for ? The infix operator $ has a simple definition: ($) :: (a -> b) -> a -> b f $ x = f x Its main use is to reduce the need for brackets: sized $ \ n -> choose (-n,n) = sized ( \ n -> choose (-n,n) ) = sized nchoose where nchoose n = choose (-n,n)
3BA31 Formal Methods 179 Scribbles 9 : Testable Instances • Bool is an instance of Testable , • Int is an instance of Arbitrary and Show , • . . . so Int -> Bool is an instance of Testable . • Char is an instance of Arbitrary and Show , • . . . so Char -> Int -> Bool is an instance of Testable . • Also Char -> Char -> Int -> Bool is an instance of Testable , • and Int -> Char -> Char -> Int -> Bool , • and . . . 3BA31 Formal Methods 180 Formal Logic We are now going to present Logic as a Formal System: Symbols Those used for expressions and logic, including ∃ , ∀ . Well-Formedness Well structured expressions whose type is Boolean. Manipulation Rules Known in formal systems for logic as Axioms and Inference Rules .
3BA31 Formal Methods 181 Types We make use of a rich variety of given types and type constructors: S , T ∈ Type ::= 1 | B | A | N | Z | Q | R | C | ∗ | S → T | . . . P T | T 1 × · · · × T n | T • Basic Types: – “Unit” or “Void” type: 1 = { ∗ } – Booleans: B = { F ALSE , T RUE } – Number Types naturals, integers, rationals, real and complex: N , Z , Q , R , C – Characters: A • Type Constructors: – Set of T : P T – Tuples over T 1 . . . T n : T 1 × · · · × T n ∗ – Sequence of T : T – Function from S to T : S → T 3BA31 Formal Methods 182 Expressions We build expressions denoting values of given type, out of constants of appropriate types ( k ∈ Const ), variables, ( v ∈ Var ), tuples, functions and operators applied in various ways: prefix, infix, post-fix, as well as lambda abstractions: e ∈ Expr k | v | ( e 1 . . . , e n ) | e 1 e 2 . . . e n | e 1 ⊕ e 2 | λ v · e ::= ⊕ ∈ { ∧ , ∨ , ≡ , ⇒ , + , − , ∗ , /, = , <, >, ≤ , ≥ , . . . } We often write function application without brackets, so f ( x ) and f x are equivalent. Applying a function to many argument brackets to the left, so f x y z should be interpreted as (( f x ) y ) z . Usually we let expression types be determined from context, but if necessary we can annotate (sub-)expressions with types, i.e. ( x : Q ) 2 = 2 x 2 = 2 instead of
3BA31 Formal Methods 183 Value of Expressions The value of an expression is determined by the values we associate with its free variables. We call the association of values with variables an Interpretation or Environment , and is usually modelled as a finite map ( Env ) from variables to values: ρ ∈ Env = Var → Value Here the ‘type’ Value should considered as the union of all possible types. Given an environment, it is possible to determine the value for an expression in a systematic way. This is captured by a “meaning function” ( E [ [ − ] ] ) which describes how an expression should be evaluated given an environment: E [ [ − ] ] : Env → Expr → Value Another way of thinking about this is to consider an expression (with free variables) as a function from an environment to a value. 3BA31 Formal Methods 184 Expression Meaning Example Consider the expression: ( x < 3 ∨ y 2 > z ) : B . Its value depends on the values of x , y and z (which is why it makes sense to think of the expression as having type Env → Value ). Assume the environment is ρ = { x �→ 4 , y �→ − 3 , z �→ 100 } . We can evaluate the expression in a number of ways: by applying E [ [ − ] ] (left), or by using ρ as a substitution (right): [ x < 3 ∨ y 2 > z ] ( x < 3 ∨ y 2 > z ) ρ E ρ [ ] [ y 2 > z ] ( x < 3 ∨ y 2 > z )[4 / x , − 3 / y , 100 / z ] E ρ [ ] ∨ E ρ [ [ x < 3] ] (4 < 3 ∨ ( − 3) 2 > 100) [ y 2 ] E ρ [ [ x ] ] < E ρ [ [3] ] ∨ E ρ [ ] > E ρ [ [ z ] ] ] > ρ ( z ) ] E ρ [ [2] ρ ( x ) < 3 ∨ E ρ [ [ y ] ( F ALSE ∨ 9 > 100) 4 < 3 ∨ ρ ( y ) 2 > 100 ( F ALSE ∨ F ALSE ) F ALSE ∨ ( − 3) 2 > 100 F ALSE F ALSE
3BA31 Formal Methods 185 Atomic Predicates An Atomic Predicate is simply an expression whose overall type is Boolean. P ∈ Pred e : B | . . . ::= As such, a predicate can be viewed as a function from an environment to the the values true or false . Env → B : Pred The previous expression example was in fact that of a predicate. We have two special predicates: true and false which always return T RUE and F ALSE respectively, regardless of the environment. So, while the expression T RUE , can be interpreted as the predicate true , but we do need to remember the type-distinction between T RUE : B and true : Env → B 3BA31 Formal Methods 186 Identities Predicate Expressions of the form: = e 1 e 2 where e 1 and e 2 have the same type, are known as Identities . Identities play a major role in what is to come.
3BA31 Formal Methods 187 Predicate Logic Syntax Given atomic predicates we can build a richer language of predicates: Well-founded formulas ( P ) of predicate calculus: P ∈ Pred ::= true | false | e : B — the atomic predicates | ¬ P | P 1 op P 2 , op ∈ { ∨ , ∧ , ⇒ , ≡ } | Q x : T • P , Q ∈ { ∀ , ∃ , ∃ ! } We can give a meaning to predicates in much the same way as we did for expressions. 3BA31 Formal Methods 188 Predicate Meanings The predicate meaning function, given an environment, maps a predicate to true or false: P [ [ − ] ] : Env → Pred → B For everything except the quantifiers, its definition is straightforward: P ρ [ [ true ] ] = � T RUE P ρ [ [ false ] ] = � F ALSE P ρ [ [ e ] ] = E ρ [ [ e ] ] � P ρ [ [ ¬ P ] ] = not P ρ [ [ P ] ] � P ρ [ [ P 1 ∧ P 2 ] P ρ [ ] and P ρ [ ] = [ P 1 ] [ P 2 ] ] � P ρ [ [ P 1 ∨ P 2 ] ] = P ρ [ [ P 1 ] ] or P ρ [ [ P 2 ] ] � P ρ [ [ P 1 ⇒ P 2 ] ] = P ρ [ [ P 1 ] ] implies P ρ [ [ P 2 ] ] � P ρ [ [ P 1 ≡ P 2 ] P ρ [ ] equivales P ρ [ ] = � [ P 1 ] [ P 2 ] ]
3BA31 Formal Methods 189 Manipulating Environments We define the domain of an environment (dom ρ ) as the set of all variables mentioned in ρ . We can use one environment ( ρ ′ ) to override part or all of another ( ρ ), indicating this by ρ † ρ ′ . The bindings in the second map, extend and take precedence of those in the first map — e.g.: { a �→ 1 , b �→ 2 , c �→ 3 } † { c �→ 33 , d �→ 44 } { a �→ 1 , b �→ 2 , c �→ 33 , d �→ 44 } = 3BA31 Formal Methods 190 Meaning for Quantifiers We can now give the meaning for the quantifiers as: for all ρ ′ such that dom ρ ′ = { x } we have P ρ † ρ ′ [ P ρ [ [ ∀ x : T • P ] ] = � [ P ] ] = T RUE for at least one ρ ′ such that dom ρ ′ = { x } we have P ρ † ρ ′ [ P ρ [ [ ∃ x : T • P ] ] = [ P ] ] = T RUE � for exactly one ρ ′ such that dom ρ ′ = { x } we have P ρ † ρ ′ [ P ρ [ [ ∃ ! x : T • P ] ] = [ P ] ] = T RUE � To evaluate a quantifier, we need to generate all possible environments ρ ′ involving the bound variable. Note that if T is infinite, then the first and last cases above cannot be computed at all, and we would only get an answer to the middle case if the answer was actually true. In general, in order to reason about quantifiers we need to use Axioms and Inference Rules .
3BA31 Formal Methods 191 Inference Rules Inference rules describe how we may deduce the truth of one or more predicates (the consequents ) from the truth of a collection of other predicates (the antecedents ): antecedent 1 . . . antecedent n [ side condition ] consequent 1 . . . consequent m 3BA31 Formal Methods 192 Inference Examples The modus ponens law: p p ⇒ q q The ∧ -introduction law: p q p ∧ q
3BA31 Formal Methods 193 Inference Examples (revisited) Sometimes the antecedents are listed on one line, with a large gap inbetween The modus ponens law revisited: p ⇒ q p q The ∧ -introduction law revisited: p q p ∧ q 3BA31 Formal Methods 194 Axioms Axioms are predicates which are true in their own right, and are simply shown by inference rules with no antecedents: axiom For example. the law of the excluded middle : p ∨ ¬ p Often axioms are simply written without any line: p ∨ ¬ p
3BA31 Formal Methods 195 Reading Inference Rules One way to read a rule like A 1 A 2 C is as saying that in order to prove C we must prove both A 1 and A 2 . Another way is to read it as stating that A 1 and A 2 imply the truth of C . 3BA31 Formal Methods 196 Using Inference Rules with Predicates There are a number of different ways in which inference rules can be used to define laws of reasoning for predicates. We shall adopt a particular form that is suitable for us, based on the notion of Sequents . A Sequent has the syntax: P 1 , P 2 , . . . P n ⊢ Q and is interpreted as asserting that from predicates P 1 , P 2 , through P n that we can deduce Q . Sequents can be thought of as an inference rules themselves, but we are instead going to treat them as meta-predicates which our inference rules allow us to manipulate. A meta-predicate is a predicate about predicates — they are not a part of our predicate language, but stand apart, as a means of talking about our predicates. In general we use Γ to denote lists of predicates, so shorthand for a sequent is Γ ⊢ Q
3BA31 Formal Methods 197 Hypotheses The predicates to the left of ⊢ are called the hypotheses , and sometimes we give the numbers of the form Hn where n ranges from 1 upwards. A sequent with the n th hypothesis A singled out will be written as Γ , Hn: A ⊢ B A sequent may have no hypotheses, in which case we write it simply as ⊢ Q 3BA31 Formal Methods 198 Where do hypotheses come from? Typically the hypotheses at the start of a proof are based on the definitions of the entities referred to in the consequent: = ( n + 1) ∗ f ( n ) (say), then we can start any proof using this definition with If we define f ( n + 1) � the hypothesis f ( n + 1) = ( n + 1) ∗ f ( n ) ⊢ . . . Note that in principle there could be very many of these, as there may well be definitions and laws associated with every mathematical operator mentioned.
3BA31 Formal Methods 199 Goals The predicate to the right of ⊢ is called the goal . The proof process will usually result in the proof of a goal turning into one or more proofs of sub-goals. The exception is when an axiom is found that immediately proves the goal. 3BA31 Formal Methods 200 Scribbles 10 : Truth Depends on Types Can x 2 = 2 be true for some value of x ? It depends on its type. ( x : Q ) 2 = 2 is always false as there is no rational square-root of 2. √ ( x : R ) 2 = 2 evaluates to true if x = 2 .
Recommend
More recommend
