comparison src/GeneralRec.v @ 465:4320c1a967c2

Spell check
author Adam Chlipala <adam@chlipala.net>
date Wed, 29 Aug 2012 18:26:26 -0400
parents e3fa35c750ac
children b36876d4611e
comparison
equal deleted inserted replaced
464:e53d051681b0 465:4320c1a967c2
242 (forall (y : A) (p : R y x), f y p = g y p) -> F x f = F x g) -> 242 (forall (y : A) (p : R y x), f y p = g y p) -> F x f = F x g) ->
243 forall x : A, 243 forall x : A,
244 Fix Rwf P F x = F x (fun (y : A) (_ : R y x) => Fix Rwf P F y) 244 Fix Rwf P F x = F x (fun (y : A) (_ : R y x) => Fix Rwf P F y)
245 ]] 245 ]]
246 246
247 Most such obligations are dischargable with straightforward proof automation, and this example is no exception. *) 247 Most such obligations are dischargeable with straightforward proof automation, and this example is no exception. *)
248 248
249 match goal with 249 match goal with
250 | [ |- context[match ?E with left _ => _ | right _ => _ end] ] => destruct E 250 | [ |- context[match ?E with left _ => _ | right _ => _ end] ] => destruct E
251 end; simpl; f_equal; auto. 251 end; simpl; f_equal; auto.
252 Qed. 252 Qed.
746 repeat (apply eval_frob; simpl; constructor). 746 repeat (apply eval_frob; simpl; constructor).
747 Qed. 747 Qed.
748 748
749 (** We need to apply constructors of [eval] explicitly, but the process is easy to automate completely for concrete input programs. 749 (** We need to apply constructors of [eval] explicitly, but the process is easy to automate completely for concrete input programs.
750 750
751 Now consider another very similar definition, this time of a Fibonacci number funtion. *) 751 Now consider another very similar definition, this time of a Fibonacci number function. *)
752 752
753 Notation "x <- m1 ; m2" := 753 Notation "x <- m1 ; m2" :=
754 (TBind m1 (fun x => m2)) (right associativity, at level 70). 754 (TBind m1 (fun x => m2)) (right associativity, at level 70).
755 755
756 (* begin hide *) 756 (* begin hide *)
910 910
911 Another useful property is that a function and its termination argument may be developed separately. We may even want to define functions that fail to terminate on some or all inputs. The well-founded recursion technique does not have this property, but the other three do. 911 Another useful property is that a function and its termination argument may be developed separately. We may even want to define functions that fail to terminate on some or all inputs. The well-founded recursion technique does not have this property, but the other three do.
912 912
913 One minor plus is the ability to write recursive definitions in natural syntax, rather than with calls to higher-order combinators. This downside of the first two techniques is actually rather easy to get around using Coq's notation mechanism, though we leave the details as an exercise for the reader. 913 One minor plus is the ability to write recursive definitions in natural syntax, rather than with calls to higher-order combinators. This downside of the first two techniques is actually rather easy to get around using Coq's notation mechanism, though we leave the details as an exercise for the reader.
914 914
915 The first two techniques impose proof obligations that are more basic than terminaton arguments, where well-founded recursion requires a proof of extensionality and domain-theoretic recursion requires a proof of continuity. A function may not be defined, and thus may not be computed with, until these obligations are proved. The co-inductive techniques avoid this problem, as recursive definitions may be made without any proof obligations. 915 The first two techniques impose proof obligations that are more basic than termination arguments, where well-founded recursion requires a proof of extensionality and domain-theoretic recursion requires a proof of continuity. A function may not be defined, and thus may not be computed with, until these obligations are proved. The co-inductive techniques avoid this problem, as recursive definitions may be made without any proof obligations.
916 916
917 We can also consider support for common idioms in functional programming. For instance, the [thunk] monad effectively only supports recursion that is tail recursion, while the others allow arbitrary recursion schemes. 917 We can also consider support for common idioms in functional programming. For instance, the [thunk] monad effectively only supports recursion that is tail recursion, while the others allow arbitrary recursion schemes.
918 918
919 On the other hand, the [comp] monad does not support the effective mixing of higher-order functions and general recursion, while all the other techniques do. For instance, we can finish the failed [curriedAdd] example in the domain-theoretic monad. *) 919 On the other hand, the [comp] monad does not support the effective mixing of higher-order functions and general recursion, while all the other techniques do. For instance, we can finish the failed [curriedAdd] example in the domain-theoretic monad. *)
920 920