aboutsummaryrefslogtreecommitdiff
path: root/contrib/extraction/README
diff options
context:
space:
mode:
authorletouzey2003-01-23 00:28:42 +0000
committerletouzey2003-01-23 00:28:42 +0000
commitc1c56a73bd8dd4896dba2212dca4b33387893567 (patch)
tree1d8935dda1f1642391d7e0863b20729e60cbce2b /contrib/extraction/README
parent84117b9db991c0cf25d3cbdc5bfb798c05a9d3ea (diff)
maj V7.4
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@3599 85f007b7-540e-0410-9357-904b9bb8a0f7
Diffstat (limited to 'contrib/extraction/README')
-rw-r--r--contrib/extraction/README69
1 files changed, 47 insertions, 22 deletions
diff --git a/contrib/extraction/README b/contrib/extraction/README
index 2fc077dbd6..7350365e7e 100644
--- a/contrib/extraction/README
+++ b/contrib/extraction/README
@@ -2,6 +2,9 @@
Status of Extraction in Coq version 7.x
======================================
+(* 22 jan 2003 : Updated for version 7.4 *)
+
+
J.C. Filliâtre
P. Letouzey
@@ -24,16 +27,23 @@ a dummy term like the ML unit.
Translation between Coq and ML is based upon the following principles:
- Terms of sort Prop don't have any computational meaning, so they are
-merged in one ML term "prop", which is for the moment the ML constant ().
-This part is done according to P. Letouzey's work (*).
+merged into one ML term "__". This part is done according to P. Letouzey's
+works (*) and (**).
+
+This dummy constant "__" used to be implemented by the unit (), but
+we recently found that this constant might be applied in some cases.
+So "__" is now in Ocaml a fixpoint that forgets its arguments:
-- Terms that are arities (i.e. something of shape ( : )( : )...s with
-s a sort ) don't have any ML counterpart, since they are types of
-types transformers. We have also a special constant "arity" to
-represent them if needed.
+ let __ = let rec f _ = Obj.repr f in Obj.repr f
+
+
+- Terms that are type schemes (i.e. something of type ( : )( : )...s with
+s a sort ) don't have any ML counterpart at the term level, since they
+are types transformers. In fact they do not have any computational
+meaning either. So we also merge them into that dummy term "__".
- A Coq term gives a ML term or a ML type depending of its type:
-a term of type an arity will give a ML type, and otherwise a ML term.
+type schemes will (try to) give ML types, and all other terms give ML terms.
And the rest of the translation is (almost) straightforward: an inductive
gives an inductive, etc...
@@ -43,9 +53,12 @@ to the incompatibilities between Coq and ML typing systems. In fact
most of the time everything goes right. For example, it is sufficient
to extract and compile everything in the "theories" directory
(cf test subdirectory).
-The last feature (not yet implemented) is to ensure that the extracted
-code will typecheck. This will be done soon by adding some "Obj.magic"
-calls in the code.
+
+We now verify during extraction that the produced code is typecheckable,
+and if it is not we insert unsafe type casting at critical points in the
+code. For the moment, it is an Ocaml-only feature, using the "Obj.magic"
+function, but the same kind of trick will be soon made in Haskell.
+
2) Differences with previous extraction (V6.3 and before)
@@ -61,7 +74,7 @@ You can have a taste of extraction directly at the toplevel by
using the "Extraction <ident>" or the "Recursive Extraction <ident>".
This toplevel extraction was already there in V6.3, but was printing
Fw terms. It now prints in the language of your choice:
-Ocaml, Haskell or an Ocaml-like with Coq namings.
+Ocaml, Haskell, Scheme, or an Ocaml-like with Coq namings.
The optimization done on extracted code has been ported between
V6.3 and V7 and enhanced, and in particular the mechanism of automatic
@@ -69,11 +82,12 @@ expansion.
2.b) The cons
-The presence of some parasite "unit" or "prop" (now () in ocaml and __ in
-Haskell) as dummy arguments
+The presence of some parasite "__" as dummy arguments
in functions. This denotes the rests of a proof part. The previous
-extraction was able to remove them totally, but this is no more possible
-due to extraction upon Type.
+extraction was able to remove them totally. The current implementation
+removes a good deal of them (more that in 7.0), but not all.
+
+This problem is due to extraction upon Type.
For example, let's take this pathological term:
(if b then Set else Prop) : Type
The only way to know if this is an Set (to keep) or a Prop (to remove)
@@ -83,9 +97,6 @@ extraction.
There is no more "ML import" feature. You can compensate by using
Axioms, and then "Extract Constant ..."
-Still no assurance of typechecking, since there is still no "Obj.magic"
-yet. Coming soon ...
-
3) Examples
The file "test-extraction.v" is made of some examples used while debugging.
@@ -93,7 +104,8 @@ The file "test-extraction.v" is made of some examples used while debugging.
In the subdirectory "test", you can test extraction on the Coq theories.
Go there.
"make tree" to make a local copy of the "theories" tree
-"make" to extract & compile most of the theories file
+"make" to extract & compile most of the theories file in Ocaml
+"make -f Makefile.haskell" to extract & compile in Haskell
See also Reference Manual for explanation of extraction syntaxes
and more examples.
@@ -103,12 +115,25 @@ and more examples.
Exécution de termes de preuves: une nouvelle méthode d'extraction
pour le Calcul des Constructions Inductives, Pierre Letouzey,
DEA thesis, 2000,
-http://www.eleves.ens.fr/home/letouzey/download/rapport_dea.ps.gz
-
+http://www.lri.fr/~letouzey/download/rapport_dea.ps.gz
+(**)
+A New Extraction for Coq, Pierre Letouzey,
+Types 2002 Post-Workshop Proceedings, to appear,
+draft at http://www.lri.fr/~letouzey/download/extraction2002.ps.gz
Any feedback is welcome:
Pierre.Letouzey@lri.fr
Jean.Christophe.Filliatre@lri.fr
-coq@pauillac.inria.fr
+
+
+
+
+
+
+
+
+
+
+