-
Notifications
You must be signed in to change notification settings - Fork 1
/
Upgrading
109 lines (86 loc) · 4.52 KB
/
Upgrading
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
FAQ: how to upgrade from Objective Caml 3.02 to 3.03
I Installation
Q1: When compiling the distribution, I am getting strange linking
errors in "otherlibraries".
A1: This is probably a problem with dynamic linking. You can disable
it with ./configure -no-shared-libs. If you really want to use
shared libraries, look in the manual pages of your system for how
to get some debugging output from the dynamic linker.
II Non-label changes
Q2: I get a syntax error when I try to compile a program using stream
parsers.
A2: Stream parser now require camlp4. It is included in the
distribution, and you just need to use "ocamlc -pp camlp4o" in
place of "ocamlc". You can also use it under the toplevel with
#load"camlp4o.cma".
Q3: I get a warning when I use the syntax "#variant" inside type
expressions.
A3: The new syntax is [< variant], which just a special case of
the more general new syntax, which allows type expressions like
[ variant1 | variant2] or [> variant]. See the reference manual
for details.
III Label changes
Q4: I was using labels before, and now I get lots of type errors.
A4: The handling of labels changed with 3.03-alpha. The new default
is a more flexible version of the commuting label mode, allowing
one to omit labels in total applications. There is still a
-nolabels mode, but it does not allow non-optional labels in
applications (this was unsound).
To keep full compatibility with Objective Caml 2, labels were
removed from the standard libraries. Some labelized libraries are
kept as StdLabels (contains Array, List and String), MoreLabels
(contains Hashtbl, Map and Set), and UnixLabels.
Note that MoreLabels' status is not yet decided.
Q5: Why isn't there a ThreadUnixLabels module ?
A5: ThreadUnix is deprecated. It only calls directly the Unix module.
Q6: I was using commuting label mode, how can I upgrade ?
A6: The new behaviour is compatible with commuting label mode, but
standard libraries have no labels. You can add the following
lines at the beginning of your files (according to your needs):
open Stdlabels
open MoreLabels
module Unix = UnixLabels
Alternatively, if you already have a common module opened by
everybody, you can add these:
include StdLabels
include MoreLabels
module Unix = UnixLabels
You will then need to remove labels in functions from other modules.
This can be automated by using the scrapelabels tool, installed
in the Objective Caml library directory, which both removes labels
and inserts needed `open' clauses (see -help for details).
$CAMLLIB/scrapelabels -keepstd *.ml
or
$CAMLLIB/scrapelabels -keepmore *.ml
Note that scrapelabels is not guaranteed to be sound for commuting
label programs, since it will just remove labels, and not reorder
arguments.
Q7: I was using a few labels in classic mode, and now I get all these
errors. I just want to get rid of all these silly labels.
A7: scrapelabels will do it for you.
$CAMLLIB/scrapelabels [-all] *.ml
$CAMLLIB/scrapelabels -intf *.mli
You should specify the -all option only if you are sure that your
sources do not contain calls to functions with optional
parameters, as those labels would also be removed.
Q8: I was using labels in classic mode, and I was actually pretty fond
of them. How much more labels will I have to write now ? How can I
convert my programs and libraries ?
A8: The new default mode is more flexible than the original commuting
mode, so that you shouldn't see too much differences when using
labeled libraries. Labels are only compulsory in partial
applications (including the special case of function with an
unknown return type), or if you wrote some of them.
On the other hand, for definitions, labels present in the
interface must also be present in the implementation.
The addlabels tool can help you to do that. Suppose that you have
mymod.ml and mymod.mli, where mymod.mli adds some labels. Then
doing
$CAMLLIB/addlabels mymod.ml
will insert labels from the interface inside the implementation.
It also takes care of inserting them in recursive calls, as
the return type of the function is not known while typing it.
If you used labels from standard libraries, you will also have
problems with them. You can proceed as described in A6. Since you
used classic mode, you do not need to bother about changed
argument order.