~ubuntu-branches/ubuntu/wily/coq-doc/wily

« back to all changes in this revision

Viewing changes to dev/doc/translate.txt

  • Committer: Bazaar Package Importer
  • Author(s): Stéphane Glondu, Stéphane Glondu, Samuel Mimram
  • Date: 2010-01-07 22:50:39 UTC
  • mfrom: (1.2.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20100107225039-n3cq82589u0qt0s2
Tags: 8.2pl1-1
[ Stéphane Glondu ]
* New upstream release (Closes: #563669)
  - remove patches
* Packaging overhaul:
  - use git, advertise it in Vcs-* fields of debian/control
  - use debhelper 7 and dh with override
  - use source format 3.0 (quilt)
* debian/control:
  - set Maintainer to d-o-m, set Uploaders to Sam and myself
  - add Homepage field
  - bump Standards-Version to 3.8.3
* Register PDF documentation into doc-base
* Add debian/watch
* Update debian/copyright

[ Samuel Mimram ]
* Change coq-doc's description to mention that it provides documentation in
  pdf format, not postscript, closes: #543545.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
 
 
2
                 How to use the translator
 
3
                 =========================
 
4
 
 
5
       (temporary version to be included in the official
 
6
           TeX document describing the translator)
 
7
 
 
8
The translator is a smart, robust and powerful tool to improve the
 
9
readibility of your script. The current document describes the
 
10
possibilities of the translator.
 
11
 
 
12
In case of problem recompiling the translated files, don't waste time
 
13
to modify the translated file by hand, read first the following
 
14
document telling on how to modify the original files to get a smooth
 
15
uniform safe translation. All 60000 lines of Coq lines on our
 
16
user-contributions server have been translated without any change
 
17
afterwards, and 0,5 % of the lines of the original files (mainly
 
18
notations) had to be modified beforehand to get this result.
 
19
 
 
20
Table of contents
 
21
-----------------
 
22
 
 
23
I) Implicit Arguments
 
24
 1) Strict Implicit Arguments 
 
25
 2) Implicit Arguments in standard library
 
26
 
 
27
II) Notations
 
28
 1) Translating a V7 notation as it was
 
29
 2) Translating a V7 notation which conflicts with the new syntax
 
30
  a) Associativity conflicts
 
31
  b) Conflicts with other notations
 
32
   b1) A notation hides another notation 
 
33
   b2) A notation conflicts with the V8 grammar
 
34
   b3) My notation is already defined at another level
 
35
  c) How to use V8only with Distfix ?
 
36
  d) Can I overload a notation in V8, e.g. use "*" and "+" ?
 
37
 3) Using the translator to have simplest notations
 
38
 4) Setting the translator to automatically use new notations that
 
39
    wasn't used in old syntax
 
40
 5) Defining a construction and its notation simultaneously
 
41
 
 
42
III) Various pitfalls
 
43
 1) New keywords
 
44
 2) Old "Case" and "Match"
 
45
 3) Change of definition or theorem names
 
46
 4) Change of tactic names
 
47
 
 
48
---------------------------------------------------------------------
 
49
 
 
50
I) Implicit Arguments
 
51
   ------------------
 
52
 
 
53
1) Strict Implicit Arguments 
 
54
 
 
55
  "Set Implicit Arguments" changes its meaning in V8: the default is
 
56
to turn implicit only the arguments that are _strictly_ implicit (or
 
57
rigid), i.e. that remains inferable whatever the other arguments
 
58
are. E.g "x" inferable from "P x" is not strictly inferable since it
 
59
can disappears if "P" is instanciated by a term which erase "x".
 
60
 
 
61
  To respect the old semantics, the default behaviour of the
 
62
translator is to replace each occurrence "Set Implicit Arguments" by
 
63
 
 
64
  Set Implicit Arguments.
 
65
  Unset Strict Implicits.
 
66
 
 
67
  However, you may wish to adopt the new semantics of "Set Implicit
 
68
Arguments" (for instance because you think that the choice of
 
69
arguments it setsimplicit is more "natural" for you). In this case,
 
70
add the option -strict-implicit to the translator.
 
71
 
 
72
  Warning: Changing the number of implicit arguments can break the
 
73
notations.  Then use the V8only modifier of Notations.
 
74
 
 
75
2) Implicit Arguments in standard library
 
76
 
 
77
  Main definitions of standard library have now implicit
 
78
arguments. These arguments are dropped in the translated files. This
 
79
can exceptionally be a source of incompatibilities which has to be
 
80
solved by hand (it typically happens for polymorphic functions applied
 
81
to "nil" or "None").
 
82
 
 
83
II) Notations
 
84
    ---------
 
85
 
 
86
  Grammar (on constr) and Syntax are no longer supported. Replace them by
 
87
Notation before translation.
 
88
 
 
89
  Precedence levels are now from 0 to 200. In V8, the precedence and
 
90
associativity of an operator cannot be redefined. Typical level are
 
91
(refer to the chapter on notations in the Reference Manual for the
 
92
full list):
 
93
 
 
94
  <-> : 95                    (no associativity)
 
95
  -> : 90                     (right associativity)
 
96
  \/ : 85                     (right associativity)
 
97
  /\ : 80                     (right associativity)
 
98
  ~ : 75                      (right associativity)
 
99
  =, <, >, <=, >=, <> : 70    (no associativity)
 
100
  +, - : 50                   (left associativity)
 
101
  *, / : 40                   (left associativity)
 
102
  ^ : 30                      (right associativity)
 
103
 
 
104
1) Translating a V7 notation as it was
 
105
 
 
106
  By default, the translator keeps the associativity given in V7 while
 
107
the levels are mapped according to the following table:
 
108
 
 
109
  the V7 levels             [  0;  1;  2;  3;  4;  5;  6;  7;  8;  9;  10]
 
110
  are resp. mapped in V8 to [  0; 20; 30; 40; 50; 70; 80; 85; 90; 95; 100]
 
111
  with predefined assoc     [ No;  L;  R;  L;  L; No;  R;  R;  R; No;   L]
 
112
 
 
113
  If this is OK for you, just simply apply the translator.
 
114
 
 
115
2) Translating a V7 notation which conflicts with the new syntax
 
116
 
 
117
a) Associativity conflict
 
118
 
 
119
  Since the associativity of the levels obtained by translating a V7
 
120
level (as shown on table above) cannot be changed, you have to choose
 
121
another level with a compatible associativity.
 
122
 
 
123
  You can choose any level between 0 and 200, knowing that the
 
124
standard operators are already set at the levels shown on the list
 
125
above. 
 
126
 
 
127
Example 1: Assume you have a notation
 
128
 
 
129
Infix NONA 2 "=_S" my_setoid_eq.
 
130
 
 
131
By default, the translator moves it to level 30 which is right
 
132
associative, hence a conflict with the expected no associativity.
 
133
 
 
134
To solve the problem, just add the "V8only" modifier to reset the
 
135
level and enforce the associativity as follows:
 
136
 
 
137
Infix NONA 2 "=_S" my_setoid_eq V8only (at level 70, no associativity).
 
138
 
 
139
The translator now knows that it has to translate "=_S" at level 70
 
140
with no associativity.
 
141
 
 
142
Rem: 70 is the "natural" level for relations, hence the choice of 70
 
143
here, but any other level accepting a no-associativity would have been
 
144
OK.
 
145
 
 
146
Example 2: Assume you have a notation
 
147
 
 
148
Infix RIGHTA 1 "o" my_comp.
 
149
 
 
150
By default, the translator moves it to level 20 which is left
 
151
associative, hence a conflict with the expected right associativity.
 
152
 
 
153
To solve the problem, just add the "V8only" modifier to reset the
 
154
level and enforce the associativity as follows:
 
155
 
 
156
Infix RIGHTA 1 "o" my_comp V8only (at level 20, right associativity).
 
157
 
 
158
The translator now knows that it has to translate "o" at level 20
 
159
which has the correct "right associativity".
 
160
 
 
161
Rem: We assumed here that the user wants a strong precedence for
 
162
composition, in such a way, say, that "f o g + h" is parsed as
 
163
"(f o g) + h". To get "o" binding less than the arithmetical operators,
 
164
an appropriated level would have been close of 70, and below, e.g. 65.
 
165
 
 
166
b) Conflicts with other notations
 
167
 
 
168
Since the new syntax comes with new keywords and new predefined
 
169
symbols, new conflicts can occur. Again, you can use the option V8only
 
170
to inform the translator of the new syntax to use.
 
171
 
 
172
b1) A notation hides another notation 
 
173
 
 
174
Rem: use Print Grammar constr in V8 to diagnose the overlap and see the
 
175
section on factorization in the chapter on notations of the Reference
 
176
Manual for hints on how to factorize.
 
177
 
 
178
Example:
 
179
 
 
180
Notation "{ x }" := (my_embedding x) (at level 1).
 
181
 
 
182
overlaps in V8 with notation "{ x : A & P }" at level 0 and with x at
 
183
level 99. The conflicts can be solved by left-factorizing the notation
 
184
as follows:
 
185
 
 
186
Notation "{ x }" := (my_embedding x) (at level 1)
 
187
  V8only (at level 0, x at level 99).
 
188
 
 
189
b2) A notation conflicts with the V8 grammar.
 
190
 
 
191
Again, use the V8only modifier to tell the translator to automatically
 
192
take in charge the new syntax.
 
193
 
 
194
Example:
 
195
 
 
196
Infix 3 "@" app.
 
197
 
 
198
Since "@" is used in the new syntax for deactivating the implicit
 
199
arguments, another symbol has to be used, e.g. "@@". This is done via
 
200
the V8only option as follows:
 
201
 
 
202
Infix 3 "@" app V8only "@@" (at level 40, left associativity).
 
203
 
 
204
or, alternatively by
 
205
 
 
206
Notation "x @ y" := (app x y) (at level 3, left associativity)
 
207
  V8only "x @@ y" (at level 40, left associativity).
 
208
 
 
209
b3) My notation is already defined at another level (or with another
 
210
associativity)
 
211
 
 
212
In V8, the level and associativity of a given notation can no longer
 
213
be changed. Then, either you adopt the standard reserved levels and
 
214
associativity for this notation (as given on the list above) or you
 
215
change your notation.
 
216
 
 
217
- To change the notation, follow the directions in section b2.
 
218
 
 
219
- To adopt the standard level, just use V8only without any argument.
 
220
 
 
221
Example.
 
222
 
 
223
Infix 6 "*" my_mult.
 
224
 
 
225
is not accepted as such in V8. Write
 
226
 
 
227
Infix 6 "*" my_mult V8only.
 
228
 
 
229
to tell the translator to use "*" at the reserved level (i.e. 40 with
 
230
left associativity). Even better, use interpretation scopes (look at
 
231
the Reference Manual).
 
232
 
 
233
c) How to use V8only with Distfix ?
 
234
 
 
235
You can't, use Notation instead of Distfix.
 
236
 
 
237
d) Can I overload a notation in V8, e.g. use "*" and "+" for my own
 
238
algebraic operations ?
 
239
 
 
240
Yes, using interpretation scopes (see the corresponding chapter in the
 
241
Reference Manual).
 
242
 
 
243
3) Using the translator to have simplest notations
 
244
 
 
245
Thanks to the new syntax, * has now the expected left associativity,
 
246
and the symbols <, >, <= and >= are now available.
 
247
 
 
248
Thanks to the interpretation scopes, you can overload the
 
249
interpretation of these operators with the default interpretation
 
250
provided in Coq.
 
251
 
 
252
This may be a motivation to use the translator to automatically change
 
253
the notations while switching to the new syntax.
 
254
 
 
255
See sections b) and d) above for examples.
 
256
 
 
257
4) Setting the translator to automatically use new notations that
 
258
wasn't used in old syntax
 
259
 
 
260
Thanks to the "Notation" mechanism, defining symbolic notations is
 
261
simpler than in the previous versions of Coq.
 
262
 
 
263
Thanks to the new syntax and interpretation scopes, new symbols and
 
264
overloading is available.
 
265
 
 
266
This may be a motivation for using the translator to automatically change
 
267
the notations while switching to the new syntax.
 
268
 
 
269
Use for that the commands V8Notation and V8Infix.
 
270
 
 
271
Examples:
 
272
 
 
273
V8Infix "==>" my_relation (at level 65, right associativity).
 
274
 
 
275
tells the translator to write an infix "==>" instead of my_relation in
 
276
the translated files.
 
277
 
 
278
V8Infix ">=" my_ge.
 
279
 
 
280
tells the translator to write an infix ">=" instead of my_ge in the
 
281
translated files and that the level and associativity are the standard
 
282
one (as defined in the chart above).
 
283
 
 
284
V8Infix ">=" my_ge : my_scope.
 
285
 
 
286
tells the translator to write an infix ">=" instead of my_ge in the
 
287
translated files, that the level and associativity are the standard
 
288
one (as defined in the chart above), but only if scope my_scope is
 
289
open or if a delimiting key is available for "my_scope" (see the
 
290
Reference Manual).
 
291
 
 
292
5) Defining a construction and its notation simultaneously
 
293
 
 
294
This is permitted by the new syntax. Look at the Reference Manual for
 
295
explanation. The translator is not fully able to take this in charge...
 
296
 
 
297
III) Various pitfalls
 
298
    ----------------
 
299
 
 
300
1) New keywords
 
301
 
 
302
  The following identifiers are new keywords
 
303
 
 
304
  "forall"; "fun"; "match"; "fix"; "cofix"; "for"; "if"; "then";
 
305
  "else"; "return"; "mod"; "at"; "let"; "_"; ".("
 
306
 
 
307
  The translator automatically add a "_" to names clashing with a
 
308
keyword, except for files. Hence users may need to rename the files
 
309
whose name clashes with a keyword.
 
310
 
 
311
  Remark: "in"; "with"; "end"; "as"; "Prop"; "Set"; "Type"
 
312
  were already keywords
 
313
 
 
314
2) Old "Case" and "Match"
 
315
 
 
316
  "Case" and "Match" are normally automatically translated into
 
317
  "match" or "match" and "fix", but sometimes it fails to do so. It
 
318
  typically fails when the Case or Match is argument of a tactic whose
 
319
  typing context is unknown because of a preceding Intro/Intros, as e.g. in 
 
320
 
 
321
     Intros; Exists [m:nat](<quasiterm>Case m of t [p:nat](f m) end)
 
322
 
 
323
  The solution is then to replace the invocation of the sequence of
 
324
  tactics into several invocation of the elementary tactics as follows
 
325
 
 
326
     Intros. Exists [m:nat](<quasiterm>Case m of t [p:nat](f m) end)
 
327
          ^^^
 
328
 
 
329
3) Change of definition or theorem names
 
330
 
 
331
  Type "entier" from fast_integer.v is renamed into "N" by the
 
332
translator. As a consequence, user-defined objects of same name "N"
 
333
are systematically qualified even tough it may not be necessary.  The
 
334
same apply for names "GREATER", "EQUAL", "LESS", etc... [COMPLETE LIST
 
335
TO GIVE].
 
336
 
 
337
4) Change of tactics names
 
338
 
 
339
  Since tactics names are now lowercase, this can clash with
 
340
user-defined tactic definitions. To pally this, clashing names are
 
341
renamed by adding an extra "_" to their name.
 
342
 
 
343
======================================================================
 
344
Main examples for new syntax
 
345
----------------------------
 
346
 
 
347
1) Constructions
 
348
 
 
349
  Applicative terms don't any longer require to be surrounded by parentheses as
 
350
e.g in
 
351
 
 
352
  "x = f y -> S x = S (f y)"
 
353
 
 
354
 
 
355
  Product is written
 
356
 
 
357
     "forall x y : T, U"
 
358
     "forall x y, U"
 
359
     "forall (x y : T) z (v w : V), U"
 
360
     etc.
 
361
 
 
362
  Abstraction is written
 
363
 
 
364
     "fun x y : T, U"
 
365
     "fun x y, U"
 
366
     "fun (x y : T) z (v w : V), U"
 
367
     etc.
 
368
 
 
369
  Pattern-matching is written
 
370
 
 
371
     "match x with c1 x1 x2 => t | c2 y as z => u end"
 
372
     "match v1, v2 with c1 x1 x2, _ => t | c2 y, d z => u end"
 
373
     "match v1 as y in le _ n, v2 as z in I p q return P n y p q z with
 
374
         c1 x1 x2, _ => t | c2 y, d z => u end"
 
375
 
 
376
     The last example is the new form of what was written
 
377
 
 
378
    "<[n;y:(le ? n);p;q;z:(I p q)](P n y p q z)>Cases v1 v2 of
 
379
         (c1 x1 x2) _ => t | (c2 y) (d z) => u end"
 
380
 
 
381
  Pattern-matching of type with one constructors and no dependencies
 
382
of the arguments in the resulting type can be written
 
383
 
 
384
    "let (x,y,z) as u return P u := t in v"
 
385
     
 
386
  Local fixpoints are written
 
387
 
 
388
    "fix f (n m:nat) z (x : X) {struct m} : nat := ...
 
389
     with ..."
 
390
 
 
391
    and "struct" tells which argument is structurally decreasing.
 
392
 
 
393
  Explicitation of implicit arguments is written
 
394
 
 
395
     "f @1:=u v @3:=w t"
 
396
     "@f u v w t"
 
397
 
 
398
2) Tactics
 
399
 
 
400
  The main change is that tactics names are now lowercase. Besides
 
401
this, the following renaming are applied:
 
402
 
 
403
  "NewDestruct" -> "destruct"
 
404
  "NewInduction" -> "induction"
 
405
  "Induction" -> "simple induction"
 
406
  "Destruct" -> "simple destruct"
 
407
 
 
408
  For tactics with occurrences, the occurrences now comes after and
 
409
  repeated use is separated by comma as in
 
410
 
 
411
  "Pattern 1 3 c d 4 e" -> "pattern c at 3 1, d, e at 4"
 
412
  "Unfold 1 3 f 4 g" -> "unfold f at 1 3, g at 4"
 
413
  "Simpl 1 3 e" -> "simpl e at 1 3"
 
414
 
 
415
3) Tactic language
 
416
 
 
417
  Definitions are now introduced with keyword "Ltac" (instead of
 
418
"Tactic"/"Meta" "Definition") and are implicitly recursive
 
419
("Recursive" is no longer used).
 
420
 
 
421
  The new rule for distinguishing terms from ltac expressions is:
 
422
 
 
423
  Write "ltac:" in front of any tactic in argument position and
 
424
  "constr:" in front of any construction in head position
 
425
 
 
426
4) Vernacular language
 
427
 
 
428
a) Assumptions
 
429
 
 
430
  The syntax for commands is mainly unchanged. Declaration of
 
431
assumptions is now done as follows
 
432
 
 
433
  Variable m : t.
 
434
  Variables m n p : t.
 
435
  Variables (m n : t) (u v : s) (w : r).
 
436
  
 
437
b) Definitions
 
438
 
 
439
  Definitions are done as follows
 
440
 
 
441
  Definition f m n : t := ... .
 
442
  Definition f m n := ... .
 
443
  Definition f m n := ... : t.
 
444
  Definition f (m n : u) : t := ... .
 
445
  Definition f (m n : u) := ... : t.
 
446
  Definition f (m n : u) := ... .
 
447
  Definition f a b (p q : v) r s (m n : t) : t := ... .
 
448
  Definition f a b (p q : v) r s (m n : t) := ... .
 
449
  Definition f a b (p q : v) r s (m n : t) := ... : t.
 
450
 
 
451
c) Fixpoints
 
452
 
 
453
  Fixpoints are done this way
 
454
  
 
455
  Fixpoint f x (y : t) z a (b c : u) {struct z} : v := ... with ... .
 
456
  Fixpoint f x : v := ... .
 
457
  Fixpoint f (x : t) : v := ... .
 
458
 
 
459
  It is possible to give a concrete notation to a fixpoint as follows
 
460
 
 
461
  Fixpoint plus (n m:nat) {struct n} : nat as "n + m" :=
 
462
    match n with
 
463
    | O => m
 
464
    | S p => S (p + m)
 
465
    end.
 
466
 
 
467
d) Inductive types
 
468
 
 
469
  The syntax for inductive types is as follows
 
470
 
 
471
  Inductive t (a b : u) (d : e) : v :=
 
472
     c1 : w1 | c2 : w2 | ... .
 
473
 
 
474
  Inductive t (a b : u) (d : e) : v :=
 
475
     c1 : w1 | c2 : w2 | ... .
 
476
 
 
477
  Inductive t (a b : u) (d : e) : v :=
 
478
     c1 (x y : t) : w1 | c2 (z : r) : w2 | ... .
 
479
 
 
480
  As seen in the last example, arguments of the constructors can be
 
481
given before the colon. If the type itself is omitted (allowed only in
 
482
case the inductive type has no real arguments), this yields an
 
483
ML-style notation as follows
 
484
 
 
485
  Inductive nat : Set := O | S (n:nat).
 
486
  Inductive bool : Set := true | false.
 
487
 
 
488
  It is even possible to define a syntax at the same time, as follows:
 
489
 
 
490
  Inductive or (A B:Prop) : Prop as "A \/ B":=
 
491
    | or_introl (a:A) : A \/ B 
 
492
    | or_intror (b:B) : A \/ B.
 
493
 
 
494
  Inductive and (A B:Prop) : Prop as "A /\ B" := conj (a:A) (b:B).
 
495