![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to environ CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10no / cmd / sml / doc|
Return to environ CVS log | Up to [Research Unix] / researchv10no / cmd / sml / doc |
1.1 root 1: The following note by Andrew Appel points out a number of serious problems
2: with the standard environment as defined in "Definition of Standard ML,
3: Version 2", and proposes changes that would correct these problems. These
4: problems with the standard environment have come to our attention through
5: using and implementing the language. Unfortunately, the environment
6: described in the Definition was (in our opinion, prematurely) frozen before
7: the proposal was tested against "reality", but we hope that there is still
8: enough flexibility within the ML community to allow us to make corrections to
9: deal with these problems. We hope that this note will bring these issues to
10: the attention of the community. [DBM]
11:
12:
13: PROPOSED CHANGES
14:
15: Andrew Appel proposes the following changes to the initial static environment
16: in the "official" Definition of Standard ML. These have not all been
17: implemented, but we would like to implement them if no one objects.
18:
19: 1. input
20:
21: input(f,n) returns a string of length k <= n
22:
23: Current semantics: if k<n then end-of-stream has been reached.
24: New semantics:
25: If no characters available, input blocks (as it does now).
26: If j>0 is the number of characters available, then k = min(j,n).
27: If (and only if) end of stream is reached, the empty string is returned.
28:
29: The reason I suggest this change is that:
30:
31: A. this primitive is much closer to the one provided by the operating system
32: B. the old primitive can be defined in terms of this one, but not the reverse
33: C. users often need this primitive and not the old one
34:
35: The old definition of input can be implemented using the new definition:
36:
37: fun old_input(f,n) =
38: case input(f,n)
39: of "" => ""
40: | s => if size(s) < n then s ^ old_input(f,n-size(s)) else s
41:
42:
43: 2. Inequality operators for strings
44:
45: The operators < <= > >= should be supported for strings. Even though
46: they could be defined by users using the existing string primitives, it
47: would be impossible for ordinary users to get them overloaded properly
48: with the integer and real comparison operators. There are many functions
49: not in the standard that I would like in my environment, but I can simply
50: define them; I am unable to define new overloadings, however.
51:
52:
53: 3. Arithmetic exceptions
54:
55: The current set of arithmetic exceptions is unrealistic because it does
56: not correspond with what is available in the hardware. To correctly
57: implement the current standard would add a very substantial overhead
58: to each execution of an arithmetic operator. Therefore, I propose:
59:
60: exception Div for integer div and mod with a dividend of 0
61: exception Overflow for all integer operators with an out-of-range result
62:
63: exception Real of string for all real operators with an out-of-range or
64: other error result
65:
66: for floating point division by 0, I propose the use of the Div exception,
67: although a separate exception could be defined for this if anyone cares.
68:
69: The exceptions Floor and Sqrt and Exp and Ln can be left as is.
70:
71:
72: 4. div and mod
73:
74: The current language definition has perfectly reasonable definitions of
75: div and mod. The problem is that no machine supports these definitions;
76: all that is supported is an integer divide (which I'll call div' )
77: that always rounds towards zero. From this it is easy to synthesize modulus:
78:
79: fun a mod' b = a - b * (a div' b)
80:
81: These div and mod operators are not the ones in the language definition.
82: However, it is possible to implement div and mod as defined in the standard:
83:
84: fun a div b = if a<0 then ... else if b<0 then ... else a div' b
85: fun a mod b = a - b * (a div b)
86:
87: This is, of course, very slow. However, any compiler that implements
88: these directly will have to generate exactly the same (slow) code!
89: The poor user who just wants to do div and mod on positive integers will pay
90: a penalty. And consider the hard-luck case who actually needs rounding
91: towards zero; he would have to implement div'' and mod'' as:
92:
93: fun a div'' b = if a<0 then ... else if b<0 then ... else a div b
94:
95: That is, he'll have to insert tests that undo the test that the
96: standard-library functions are doing; no wonder he'll think that functional
97: languages are slow.
98:
99: Therefore, I propose:
100:
101: div always rounds towards zero
102: mod is just fun a mod b = a - b * (a div b)
103:
104: If a user wants the current versions of div and mod, he can implement them;
105: and his implementation will be no worse in performance
106: than what happens now in the standard library functions!
107:
108: And remember, I don't make this proposal because it's more elegant than
109: the current definition, just because it's what the machines actually do,
110: and users can easily synthesize the functions they really want from
111: the primitives.
112:
113:
114: 5. Interrupt
115:
116: Consider the following:
117:
118: fun f() = (process(input(std_in, 10)); f()) handle Interrupt => f()
119:
120: This is intended to be an Interrupt-proof loop (just like the "toplevel"
121: of an interactive ML system). However, if two interrupts arrive in very
122: close succession, then the second will arrive in the exception handler
123: and will cause execution to terminate. The only safe way to handle this
124: is to disable the interrupt button as soon as an Interrupt arrives,
125: with an explicit re-enabling of interrupts at the discretion of the program.
126: This requires the function:
127:
128: enable_interrupt : unit -> unit
129:
130: with (just for symmetry) a corresponding
131:
132: disable_interrupt : unit -> unit
133:
134: Then the function f() above can be written as
135:
136: fun f() = (enable_interrupt();
137: process(input(std_in, 10)); f()) handle Interrupt => f()
138:
139:
140: 6. Arrays
141:
142: I get tired of people telling me "ML doesn't have arrays, so I can't do X".
143: Then I have to explain that every ML compiler has arrays, even though
144: the language definition doesn't. Perhaps it would be simpler to put them
145: in the language definition.
146:
147:
148: 7. Io exception
149:
150: The current Io exception carries a string approximately of the form
151: "Cannot open s" where s is a filename. This is objectionable for two reasons.
152:
153: First, it's not possible to pattern-match on substrings; if the strings
154: are to be standardized, a datatype should be used.
155:
156: Second, there's no indication of why a file cannot be opened (or written,
157: read, etc.). Most operating systems are perfectly happy to provide a string
158: explaining what failed, e.g. "No such file or directory" or
159: "Interrupted system call". Therefore, I propose something like the following:
160:
161: exception Io of {operation : string, filename : string, reason : string}
162:
163: where operation is one of "open_in", "input", etc., filename is the
164: name of the stream (given to open_in or open_out) and reason is an
165: operating-system dependent explanation of what happened.
166:
167: Now it's much easier to pattern-match on Io failures, and the reasons for
168: failures are explained.
169:
170:
171: 8. curried input and output
172:
173: All of the first 7 proposals are in some sense fundamental; there's no way
174: that a user can get the right effect by defining functions in his own
175: environment. Proposal #8 is just cosmetic: we propose that the
176: input and output functions be curried. We circulated this proposal about
177: a year ago and got no response. Is anyone listening out there?
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.