|
|
1.1 root 1: This file attempts to list differences between the Edinburgh compiler
2: and SML of New Jersey, as an aid to converting programs to run under
3: the new compiler. Items that are likely to break old code are
4: annotated with "!!!". The version of the Edinburgh compiler we have
5: used for comparison is quite old, and many of these differences may
6: not apply to the latest version. Users who find other differences can
7: help keep this file up to date by sending mail to:
8:
9: macqueen%[email protected]
10:
11:
12: Pervasives
13:
14: * The type of use is different; it is now applied to strings instead
15: of string lists. Users who prefer the old version of use can
16: redefine it:
17: val use = app use !!!
18:
19: * Structure Byte_array has been renamed ByteArray, and there have been
20: significant changes in the structure itself, including renaming of
21: functions to parallel those in the structure Array, and the addition
22: of a new exception Range. The new signature BYTEARRAY is defined in
23: boot/perv.sig. As before, ByteArray is not opened by default in
24: the pervasive environment. !!!
25:
26: * Strings and byte arrays are not limited to 65535 characters as they
27: were in the Edinburgh system.
28:
29: * There have been significant changes in the IO interface. The BasicIO
30: and ExtendedIO structures have been replaced by structure IO, which
31: matches signatures BasicIO and IO (signature ExtendedIO has been eliminated).
32: The IO and BASICIO signatures can be found in boot/perv.sig.
33:
34: * IO.input and IO.output are curried. !!!
35:
36: * IO.can_input now returns the number of characters which can be read from
37: an instream without blocking.
38:
39: * List.exists has been curried. !!!
40:
41: * List.@ now associates to the right.
42:
43: * The type of exportML has changed:
44: val exportML : string -> bool
45: The string is the file to export to, and the boolean returned distinguishes
46: between a new ML process (true) and the return from exportML (false).
47: In the Edinburgh system, exportML returned the new process to top level;
48: in our system, the new process takes up exactly where exportML would have
49: returned to.
50:
51: * The obsolete exception Varstruct is not supported; Bind should
52: be used instead. !!!
53:
54:
55: Core
56:
57: * We use the new exception syntax. !!!
58:
59: * We use the new form of numeric record labels, for example {2=5,3=true}. !!!
60:
61: * Record label abbreviations work only in patterns, not in expressions: !!!
62: val a = 4 val b = {a,c=3}
63: does not work on our system, but these will:
64: val a = 4 val b = {a=a,c=3}
65: fun f {a : int, c = 3} = ...
66:
67:
68: Modules
69:
70: * Functors may have free references to structures that are not parameters.
71:
72: * Sharing constraints are now components of signatures.
73:
74: * Functor parameter syntax is slightly different: !!!
75: Two styles of functor syntax are now supported. The parameter list following
76: the functor name in a functor declaration can consist either of a single
77: structure name with a signature, or it can consist of a sequence of specifications
78: like those in the body of a signature. For example:
79: functor F(X: sig structure A: SA and B: SB end) =
80: struct
81: ... X.A ... X.B ...
82: end
83: or
84: functor F'(structure A: SA and B: SB) =
85: struct
86: ... A ... B ...
87: end
88: Corresponding functor applications would have the forms
89: F(<strexp>)
90: or
91: F'(structure A = <strexp> and B = <strexp>)
92:
93:
94: All of the features above are documented in the manual (???).
95:
96:
97: Undocumented features of our compiler:
98:
99: * val cd : string -> unit
100: allows you to change working directories without leaving ML.
101:
102: * val exportFn : string * (string list*string list -> unit) -> unit
103: exportFn takes a string and a function, and exports the function
104: to the file specified by the string. Only the function itself and
105: code it is dependent on are exported; this will be much smaller
106: than the file produced by exportML (which contains the entire
107: compiler). The exported function will be applied to a list of
108: command-line arguments and a list of the (Unix) environment on startup.
109: Because exportFn "throws away" the compiler by forcing a special
110: garbage collection, it never returns.
111:
112: * Two functions are provided which allow the user to construct and
113: execute ML code on the fly:
114: val open_string : string -> instream
115: val use_stream : instream -> unit
116: use_stream is like use except that it is applied to an instream
117: rather than a file name. open_string converts a string to
118: an instream.
119:
120: * A structure System is present in the initial environment. The structure
121: contains special values used by the compiler, which for the most
122: part should be left alone. Two substructures may be of some
123: use: System.Control contains a number of flags which control
124: compiler behavior. They are not documented anywhere,
125: and some have unobvious functions, so it is unwise to play
126: with those which seem cryptic.
127: System.Timer contains some elementary timing functions.
128: Both have signatures defined in boot/system.sig, and both are
129: subject to change at any time.
130:
131: * System.version : string
132: a string identifying the version and origin date of the compiler.
133:
134: * exception SystemCall of string
135: may be raised by the functions system and cd, or in
136: unusual failures of system calls.
137:
138: * exception Real of string
139: may be raised by generic exceptions like overflow
140: encountered in floating point operations.
141:
142: * exception Overflow
143: is raised by integer overflow (bigints are not supported).
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.