Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Annotation of /bugs/trunk/bugs.1201-1400
ViewVC logotype

Annotation of /bugs/trunk/bugs.1201-1400

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1339 - (view) (download)

1 : macqueen 944 Number: 1201
2 :     Title: ltUnbound in curried functor with where structure
3 :     Keywords: modules, functors, where structure
4 :     Submitter: Dave MacQueen
5 :     Date: 5/16/97
6 :     Version: 109.27+ (with SML 97 sharing, where structure, etc.)
7 :     System: -
8 :     Severity: major
9 :     Problem:
10 :     A "where structure" clause modifying the second parameter signature
11 :     refers to a substructure of the first parameter. The result is
12 :     a message "**** hmmm, I didn't find the variable 52" and an uncaught
13 :     ltUnbound exception.
14 :     Code:
15 :     signature SA =
16 :     sig
17 :     type t
18 :     end;
19 :    
20 :     signature SX =
21 :     sig
22 :     structure A : SA
23 :     end;
24 :    
25 :     signature SY =
26 :     sig
27 :     structure A : SA
28 :     end;
29 :    
30 :     functor F
31 :     (structure X : SX)
32 :     (structure Y : SY
33 :     where structure A = X.A) =
34 :     struct
35 :     end;
36 :    
37 :     Transcript:
38 :     - use "bug1201.sml";
39 :     [opening bug1201.sml]
40 :     signature SA =
41 :     sig type t end
42 :     signature SX =
43 :     sig structure A : sig type t end end
44 :     signature SY =
45 :     sig structure A : sig type t end end
46 :     **** hmmm, I didn't find the variable 52
47 :    
48 :     uncaught exception ltUnbound
49 :     raised at: basics/ltyenv.sml:244.32-244.41
50 :     util/stats.sml:164.40
51 :     util/stats.sml:164.40
52 :     util/stats.sml:164.40
53 :     build/evalloop.sml:192.58
54 :     build/evalloop.sml:284.46-284.49
55 :    
56 :     Comments:
57 :     An extended variant of this remains open. See bug 1205. [fixed in 109.31]
58 :    
59 :     Fix: In ElabSig, where a STRdef is created by elabWhere, in the case that
60 :     the STRdef in a CONSTstrDef variant, we replace the access and info fields
61 :     by null values (NO_ACCESS and INL_NO respectively), since these fields
62 :     are not relevant. Alternatively we could have CONSTstrDef have a
63 :     record with only the sign and rlzn fields from the structure.
64 :    
65 :     Test: bug1201.sml
66 :     Owner: dbm, zhong
67 :     Status: fixed in 109.28 [dbm, 5/19/97]
68 :     ----------------------------------------------------------------------
69 :     Number: 1202
70 :     Title: Unbound in functor with where structure clause on parameter sig
71 :     Keywords: modules, functors, where structure
72 :     Submitter: Dave MacQueen
73 :     Date: 5/16/97
74 :     Version: 109.27+ (with SML 97 sharing, where structure, etc)
75 :     System: -
76 :     Severity: major
77 :     Problem:
78 :     where structure clause in parameter signature causes uncaught
79 :     exception Unbound
80 :     Code:
81 :     signature SA =
82 :     sig
83 :     type t
84 :     end;
85 :    
86 :     signature SX =
87 :     sig
88 :     structure A : SA
89 :     end;
90 :    
91 :     signature SY =
92 :     sig
93 :     structure A : SA
94 :     end;
95 :    
96 :     functor F
97 :     (structure X : SX
98 :     structure Y : SY
99 :     where structure A = X.A) =
100 :     struct
101 :     end;
102 :    
103 :     Transcript:
104 :     - use "bug1202.sml";
105 :     [opening bug1202.sml]
106 :     signature SA =
107 :     sig type t end
108 :     signature SX =
109 :     sig structure A : sig type t end end
110 :     signature SY =
111 :     sig structure A : sig type t end end
112 :    
113 :     uncaught exception Unbound
114 :     raised at: elaborate/elabmod.sml:1144.39-1144.49
115 :     util/stats.sml:164.40
116 :     build/evalloop.sml:120.38
117 :     build/evalloop.sml:192.58
118 :     build/evalloop.sml:284.46-284.49
119 :    
120 :     Comments:
121 :     Note that in bug1202.3, the explicit definition of the parameter
122 :     signature SZ works, but the functor declaration still fails with
123 :     uncaught Unbound.
124 :    
125 :     This is probably the same bug as 1200.
126 :     Fix:
127 :     Test: bug1202.1.sml, bug1202.2.sml, bug1202.3.sml
128 :     Owner: dbm
129 :     Status: fixed in 109.28 [dbm,5/20/97]
130 :     ----------------------------------------------------------------------
131 :     Number: 1203
132 :     Title: structure def spec doesn't work
133 :     Keywords: modules, signatures, functors, structure definition spec
134 :     Submitter: Dave MacQueen
135 :     Date: 5/16/97
136 :     Version: 109.27+ (with SML 97 sharing, where structure, etc)
137 :     System: -
138 :     Severity: major
139 :     Problem:
140 :     A structure def spec in a functor parameter signature doesn't have
141 :     the expected effect.
142 :     Code:
143 :     signature S =
144 :     sig
145 :     type t
146 :     end;
147 :    
148 :     structure A : S =
149 :     struct
150 :     type t = int
151 :     end;
152 :    
153 :     functor F1(X: sig type t = A.t end) =
154 :     struct
155 :     val x : X.t = 3
156 :     end;
157 :    
158 :     functor F2(X: sig structure B: S = A end) =
159 :     struct
160 :     val x : X.B.t = 3
161 :     end;
162 :    
163 :     Transcript:
164 :     - use "bug1203.sml";
165 :     [opening bug1203.sml]
166 :     signature S =
167 :     sig type t end
168 :     structure A :
169 :     S
170 :     functor F1 : <sig>
171 :     GC #0.0.0.0.1.2: (0 ms)
172 :     bug1203.sml:18.3-18.20 Error: pattern and expression in val dec don't agree [literal]
173 :     pattern: ?.t
174 :     expression: int
175 :     in declaration:
176 :     x : ?.t = (3 : int)
177 :    
178 :     uncaught exception Error
179 :     raised at: build/evalloop.sml:103.44-103.52
180 :     build/evalloop.sml:120.38
181 :     build/evalloop.sml:192.58
182 :     build/evalloop.sml:284.46-284.49
183 :    
184 :     Comments:
185 :     Fix:
186 :     Test: bug1203.sml
187 :     Owner: dbm
188 :     Status: fixed in 109.28 [dbm]
189 :     ----------------------------------------------------------------------
190 :     Number: 1204
191 :     Title: invalid paths in lhs of where clauses
192 :     Keywords: modules, signatures, where clauses
193 :     Submitter: Dave MacQueen
194 :     Date: 5/16/97
195 :     Version: 109.27+ (SML 97 sharing, where structure, etc.)
196 :     System: -
197 :     Severity: major
198 :     Problem:
199 :     An invalid path in the the lhs of a where clause is not detected
200 :     when a signature is elaborated, and causes uncaught Unbound when
201 :     the signature is instantiated as a functor parameter.
202 :     Code:
203 :     This causes no complaint:
204 :    
205 :     (* bug1204.1.sml *)
206 :    
207 :     signature S =
208 :     sig
209 :     type t
210 :     end;
211 :    
212 :     signature S1 = S where type A.t = int;
213 :    
214 :     while this causes uncaught exception Unbound:
215 :    
216 :     (* bug1204.2.sml *)
217 :    
218 :     signature S =
219 :     sig
220 :     type t
221 :     end;
222 :    
223 :     functor F(X: S where type A.t = int) =
224 :     struct end;
225 :    
226 :     Comments:
227 :     Fix: added checkWhereDefs in ElabSig to check that lhs paths are valid.
228 :     Test: bug1204.1.sml, bug1204.2.sml
229 :     Owner: dbm
230 :     Status: fixed in 109.28 [dbm, 5/17/98]
231 :     ----------------------------------------------------------------------
232 :     Number: 1205
233 :     Title: problem with "where structure" and curried functors (cf. 1201)
234 :     Keywords: modules, functors, curried functors, where structure
235 :     Submitter: Dave MacQueen
236 :     Date: 5/21/97
237 :     Version: 109.27+ (109.28)
238 :     System: -
239 :     Severity: major
240 :     Problem:
241 :     Defining the result of a curried functor by partial application of another
242 :     curried functor, a "where structure" spec is not matched.
243 :     Code:
244 :     (* bug1205.sml *)
245 :    
246 :     signature SA =
247 :     sig
248 :     type t
249 :     end;
250 :    
251 :     signature SX =
252 :     sig
253 :     structure A : SA
254 :     end;
255 :    
256 :     signature SY =
257 :     sig
258 :     structure A : SA
259 :     end;
260 :    
261 :     functor F
262 :     (structure X : SX)
263 :     (structure Y : SY
264 :     where structure A = X.A) =
265 :     struct
266 :     fun f(x: X.A.t, y: Y.A.t list) = x::y
267 :     end;
268 :    
269 :     functor G(structure A : SA) :
270 :     sig
271 :     functor G1(structure Y: SY where structure A = A) : sig end
272 :     end =
273 :     struct
274 :     functor G1 = F(structure X = struct structure A = A end)
275 :     end;
276 :    
277 :     Transcript:
278 :     [opening test/bugs/bug1205.sml]
279 :     signature SA =
280 :     sig type t end
281 :     signature SX =
282 :     sig structure A : sig type t end end
283 :     signature SY =
284 :     sig structure A : sig type t end end
285 :     GC #0.0.0.0.1.5: (0 ms)
286 :     functor F : <sig>
287 :     test/bugs/bug1205.sml:26.9-32.4 Error: where structure spec not matched: A
288 :    
289 :     uncaught exception Error
290 :     raised at: build/evalloop.sml:103.44-103.52
291 :     build/evalloop.sml:120.38
292 :     build/evalloop.sml:192.58
293 :     build/evalloop.sml:284.46-284.49
294 :     Comments:
295 :     This bug represents a problem with MLRISC/mlrisc/ra.sml and
296 :     MLRISC/hppa/hppaRegAlloc.sml and MLRISC/alpha32/alpha32RegAlloc.sml.
297 :     Fix:
298 :     In processing structure def specs or where structure defs,
299 :     lookStrDef has to relativize structures that are local to a functor
300 :     (such as the functor parameter), turning CONSTstrDefs into VARstrDefs
301 :     for such local structures. A local version of lookStrDef was defined
302 :     within ElabSig (which is the only module using Lookup.lookStrDef) that
303 :     does this relativization.
304 :     Test: bug1205.sml
305 :     Owner: dbm, Zhong
306 :     Status: fixed in 109.31 [dbm, 8/14/97]
307 :     ----------------------------------------------------------------------
308 :     Number: 1206
309 :     Title: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
310 :     Keywords: modules, functors, TransTypes
311 :     Submitter: George Russell <george@persimmon.co.uk>
312 :     Date: 5/7/97
313 :     Version: 109.28-
314 :     System: -
315 :     Severity: major
316 :     Problem:
317 :     Compiling the code below (which requires smlnj-lib) causes
318 :     Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
319 :     Code:
320 :     functor Dictionary (HK:HASH_KEY):
321 :     sig type 'b dictionary
322 :     val create: int->'b dictionary
323 :     end=
324 :     struct
325 :     structure Hash=HashTableFn(HK)
326 :    
327 :     exception NF
328 :     type 'b dictionary='b Hash.hash_table
329 :     fun create i=Hash.mkTable(i,NF)
330 :     end
331 :     functor T(S:HASH_KEY)=
332 :     struct
333 :     structure U=Dictionary(S)
334 :     datatype v=v of int U.dictionary
335 :     fun cre n=v(U.create n)
336 :     end;
337 :     structure OP=T(struct
338 :     type hash_key=Word.word
339 :     fun hashVal k=k
340 :     val sameKey=op=
341 :     end)
342 :    
343 :     [Zhong, 5/7/97] I have narrowed your code further down the following
344 :     (it does not rely on the SML Library any more):
345 :    
346 :     functor Dict (type t) : sig type dict
347 :     end
348 :     = struct
349 :     datatype dict = HT of t | NIL
350 :     type dict = dict (* removing this line, the bug goes away *)
351 :     end
352 :    
353 :     functor T(type t) =
354 :     struct structure U = Dict(type t = t)
355 :     datatype s = EE of U.dict | FF
356 :     val x = FF
357 :     end;
358 :    
359 :     structure A = T(type t = int)
360 :    
361 :     Transcript:
362 :     - use "/usr/local/sml/bugs/tests/bug1206.sml";
363 :     [opening /usr/local/sml/bugs/tests/bug1206.sml]
364 :     functor Dictionary : <sig>
365 :     functor T : <sig>
366 :     Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
367 :    
368 :     uncaught exception Error
369 :     raised at: util/errormsg.sml:51.14-51.19
370 :     util/stats.sml:164.40
371 :     build/evalloop.sml:192.58
372 :     build/evalloop.sml:284.46-284.49
373 :     Comments: [Zhong, 6/24/97]
374 :     (* The following is a narrowed-down version of the code. The code raises
375 :     the following exception:
376 :    
377 :     - [opening ztodo/z3.sml]
378 :     functor T : <sig>
379 :     Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
380 :    
381 :     I managed to track it down and understand that the bug is caused
382 :     by the incorrect management of "epContext".
383 :    
384 :     The scenerio is like this: datatype u is shadowed by another DEFtyc
385 :     u inside U, so it is not exported by structure U; when we enter
386 :     structure U, we create a new level of epContext, but when finish
387 :     processing structure U, this level of epContext is popped off;
388 :     we do try to recover the epContext binding all the components
389 :     exported by structure U, but not the shadowed datatype "u".
390 :    
391 :     Therefore, when we process datatype s, the type U.u is not properly
392 :     relativized because the shadowed version of u is not in the epContext.
393 :    
394 :     Possible fixes: we have to adjust the "enterClosed" or the "mapEPC"
395 :     functions to take account these shadowed type bindings.
396 :     *)
397 :    
398 :     functor T(type t) =
399 :     struct
400 :     structure U =
401 :     struct
402 :     datatype u = HT of t
403 :     type u = u (* removing this line, the bug goes away *)
404 :     end
405 :     datatype s = EE of U.u
406 :     val x = fn (_: s) => 0
407 :     end;
408 :    
409 :     structure A = T(type t = int)
410 :     Fix:
411 :     Added enterOpenNew and mergeHidden functions to modules/epcontext.sml
412 :     and called them within function elabStrbs in elaborate/elabmod.sml.
413 :     The effect is the preserve mappings for local hidden types that won't
414 :     be found by the call to mapPaths, like the internal datatype u in
415 :     the above code.
416 :     Test: bug1206.sml (requires smlnj-lib), bug1206.2.sml
417 :     Owner: Zhong, dbm
418 :     Status: fixed in 109.32 (dbm, 7/21/97)
419 :     ----------------------------------------------------------------------
420 :     Number: 1207
421 :     Title: unimplemented include syntax
422 :     Keywords: syntax, parsing, include, signatures
423 :     Submitter: John Reppy
424 :     Date: 5/22/97
425 :     Version: 109.29
426 :     System: -
427 :     Severity: medium
428 :     Problem:
429 :     The syntax for the basic "include" spec is
430 :    
431 :     include sigexp
432 :    
433 :     (page 14, DSMLR). Only sidids are accepted as arguments now.
434 :     Comments:
435 :     The derived form
436 :    
437 :     include sigid1 ... sigidn
438 :    
439 :     is implemented properly. The derived form does not allow for sigexps.
440 :     Code: (from Andrew Kennedy)
441 :     signature SIG =
442 :     sig
443 :     datatype d = c include sig type t end where type t = d
444 :     end;
445 :     Transcript: Error: Compiler bug: Include: elabInclude
446 :     Fix:
447 :     Test: bug1207.sml
448 :     Owner: dbm
449 :     Status: fixed in 110 [dbm, 10/25/97]
450 :     ----------------------------------------------------------------------
451 :     Number: 1208
452 :     Title: unimplemented strexp syntax
453 :     Keywords: syntax, parsing, structures
454 :     Submitter: Dave MacQueen
455 :     Date: 6/19/97
456 :     Version: 109.29
457 :     System: -
458 :     Severity: major
459 :     Problem:
460 :     Syntax for structure expressions includes
461 :    
462 :     strexp : sigexp
463 :    
464 :     (DSMLR, p.13). This isn't implemented.
465 :    
466 :     Comments:
467 :     Fix:
468 :     Test:
469 :     Owner: dbm
470 :     Status: open
471 :     ----------------------------------------------------------------------
472 :     Number: 1209
473 :     Title: casting polymorphic functions and abstract types
474 :     Keywords: cast, polymorphism, abstract types
475 :     Submitter: Chris Paris <cap@cmu.edu>
476 :     Date: 5/28/97
477 :     Version: 109.28
478 :     System: ?
479 :     Severity: minor
480 :     Problem:
481 :     casting a polymorphic function causes a Compiler bug. A better error
482 :     message should be generated.
483 :     Transcript:
484 :     - fun subst (f : 'a -> unit) = System.Unsafe.cast f ();
485 :     Error: Compiler bug: Contract: UsageMap on 158
486 :    
487 :     Comments:
488 :     [Paris]
489 :     I reworked some of my code, and I believe I have it working in 109.28
490 :     now. In response to a comp.lang.ml post I made a while ago, Zhong Shao
491 :     suggested that the introduction of the FLINT code would change the
492 :     behavior of the cast function, so that I get to write one evil thing
493 :     instead of another. The "nicer" approach seems to work in 109.28,
494 :     though I don't know why my earlier code broke between 27 and 28, since
495 :     I thought that FLINT has been around for a while now.
496 :    
497 :     [Zhong]
498 :     While FLINT has been around for a few months, it is changing almost every
499 :     week :-) There are some major differences between 27 and 28, one is the
500 :     default calling conventions for polymorphic functions --- the result
501 :     is that it is no longer safe to directly cast a polymorphic function
502 :     from "'a -> unit" into "unit -> unit".
503 :    
504 :     Future compilers will report such "unsafe" uses of cast. For the time
505 :     being, the compiler does not bother, the CPS optimizer takes the code and
506 :     complains about "Contract: UsageMap on 158". I'll try to get a fix
507 :     into 109.29.
508 :    
509 :     [jhr]
510 :     The example where I get this bug involves converting the type
511 :    
512 :     (char -> char) -> string -> string
513 :    
514 :     to
515 :    
516 :     (Word8.word -> Word8.word) -> Word8Vector.vector -> Word8Vector.vector
517 :    
518 :     No polymorphism is involved, and the representations of the two types should
519 :     be the same.
520 :    
521 :     [Zhong]
522 :     There is a bug in 109.28 on representation analysis of values
523 :     with "abstract types". In this case, Word8Vector.vector is an
524 :     abstract type created by :> in boot/built-in.sml. I'll try to
525 :     fix this in 109.29.
526 :    
527 :     In general, care must be taken when creating new types using :>.
528 :     For example,
529 :    
530 :     structure V :> sig
531 :     eqtype vector
532 :     val create : int -> vector
533 :     end = struct
534 :     type vector = string
535 :     val create = Assembly.A.create_s
536 :     end
537 :    
538 :     representation analysis would think V.vector has type
539 :    
540 :     TC_ABS (string)
541 :    
542 :     and process it in the same way as other abstract types (with
543 :     same shapes but different type stamps). A better way to
544 :     add built-in types such as word8vector is to directly add it
545 :     into the initial Prim environment.
546 :    
547 :     There are no guarantees that values of type T and ABS(T) would
548 :     have same representations (right now, T and ABS(T) would have
549 :     same representations if T is "boxed" in a canonical way)
550 :    
551 :     Fix: same as fix for 1323?
552 :     Test: bug1209.sml
553 :     Owner: Zhong
554 :     Status: fixed in 110.0.1 [Zhong, 1/7/98]
555 :     ----------------------------------------------------------------------
556 :     Number: 1210
557 :     Title: weak pointers to strings cause SML to crash
558 :     Keywords: weak pointers
559 :     Submitter: Edo Biagioni, esb@cs.cmu.edu
560 :     Date: 05/30/1997
561 :     Version: 109.27
562 :     System: DEC alpha Osf1 V3.2
563 :     Severity: minor
564 :    
565 :     Transcript:
566 :    
567 :     % /afs/cs.cm.edu/project/fox/port/109.27/bin/sml
568 :     Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM&CMB]
569 :     val it = () : unit
570 :     - val a = "foo";
571 :     val a = "foo" : string
572 :     - val b = SMLofNJ.Weak.weak a;
573 :     val b = - : string ?.weak
574 :     - SMLofNJ.Internals.GC.doGC 0;
575 :     GC #1.1.1.1.1.2: /afs/cs.cmu.edu/project/fox/port/109.27/bin/.run/run.alpha32x-osf1: Fatal error -- weak big object
576 :    
577 :     Comments:
578 :     [jhr]
579 :     Actually, this bug is weak pointers to big objects (aka, code). Heap allocated
580 :     strings should work okay. This will be fixed when we go to the new array/vector
581 :     representations.
582 :     Fix:
583 :     Test:
584 :     Owner: jhr
585 :     Status: open
586 :     ----------------------------------------------------------------------
587 :     Number: 1211
588 :     Title: signature problems not reported until signature instantiation
589 :     Keywords: modules, signatures, instantiation
590 :     Submitter: Norman Ramsey <nr@cs.virginia.edu>
591 :     Date: 5/30/97
592 :     Version: 109.28
593 :     System: -
594 :     Severity: major
595 :     Problem:
596 :     I'm having trouble migrating my code to the new rules for sharing.
597 :     The error message I get is:
598 :     control.nw:94.9-94.44 Error: rigid type spec in sharing: item
599 :     The source code prompting this message is:
600 :     functor CodeBogus(Code : CODE) = struct end
601 :    
602 :     It would be more helpful if
603 :     - the error message were issued when the CODE signature was compiled
604 :     - the source locations referred to in the message contained the offending
605 :     sharing constraint
606 :     - the README file for 109.28 indicated what error message to expect
607 :     when the new illegal constructs are used. This way I could correlate
608 :     the error message with the potential problem.
609 :     Comments:
610 :     Fix:
611 :     Need to instantiate signatures where they are declared to detect these
612 :     errors at the appropriate point. This could be controlled by a
613 :     flag that could turn off instantiation when recompiling debugged code.
614 :     Test:
615 :     Owner: dbm, Zhong
616 :     Status: fixed in 109.30 [dbm]
617 :     ----------------------------------------------------------------------
618 :     Number: 1212
619 :     Title: where structure when signatures differ
620 :     Keywords: modules, where structure, SML97
621 :     Submitter: Norman Ramsey <nr@cs.virginia.edu>
622 :     Date: 5/30/97
623 :     Version: 109.28
624 :     System: -
625 :     Severity: major
626 :     Problem:
627 :     I am informed:
628 :     elabexp.nw:32.9...53.4 Error: Inconsistent defining constraints : type item = item
629 :    
630 :     I introduced this error by replacing
631 :    
632 :     functor ElabExpFun (structure Denotable : DENOTABLE
633 :     structure DoublePattern : DOUBLE_PATTERN
634 :     sharing DoublePattern.Normal = Denotable.Pattern
635 :     val simplify : Denotable.Constructor.Pattern.Exp.exp ->
636 :     Denotable.Constructor.Pattern.Exp.exp
637 :     ) : ELAB_EXP = struct ... end
638 :     with
639 :    
640 :     functor ElabExpFun (structure Denotable : DENOTABLE
641 :     structure DoublePattern : DOUBLE_PATTERN
642 :     where structure Normal = Denotable.Pattern
643 :     val simplify : Denotable.Constructor.Pattern.Exp.exp ->
644 :     Denotable.Constructor.Pattern.Exp.exp
645 :     ) : ELAB_EXP = struct ... end
646 :    
647 :     The replacement was necessary because the two structures have
648 :     difference signatures and both signatures are full of 'rigid' type
649 :     definitions (I've forgotten the proper term for these).
650 :    
651 :     I have no idea how to track down and diagnose this error.
652 :     Some more source locations in the error message might help.
653 :    
654 :     Comments:
655 :     Same as bug 1232.
656 :     Fix:
657 :     Test:
658 :     Owner: dbm
659 :     Status: fixed in 109.30
660 :     ----------------------------------------------------------------------
661 :     Number: 1213
662 :     Title: CM dependency analysis
663 :     Keywords: CM, dependency
664 :     Submitter: Andrew Kennedy <andrew@persimmon.co.uk>
665 :     Date: 6/3/97
666 :     Version: 109.28
667 :     System: -
668 :     Severity: major
669 :     Problem:
670 :     I don't have sample code for this one; I'm hoping that my vague
671 :     description will suffice. The situation is that a structure imports
672 :     another structure but only by way of rebinding e.g.
673 :    
674 :     structure STR1 = struct
675 :    
676 :     structure STR2 = STR3
677 :    
678 :     .... STR2.x ...
679 :    
680 :     end
681 :    
682 :     so that STR3 is never used in a qualified identifier. This seems to
683 :     trick the compilation manager into thinking that STR3 is not referenced
684 :     in STR1, leading to compilation errors such as "no such structure STR3".
685 :     However, if one of the qualified identifiers (such as STR2.x above) is
686 :     replaced by its synonym (STR3.x) then this fixes things. What's more, I
687 :     can then change it back to STR2.x and the compilation manager seems to
688 :     `remember' that STR1 referred to STR3.
689 :    
690 :     Comments:
691 :     Fix:
692 :     Test:
693 :     Owner: Matthias
694 :     Status: not reproducible [blume, 8/3/97]
695 :     ----------------------------------------------------------------------
696 :     Number: 1214
697 :     Title: Increased make time
698 :     Keywords: CM, memory usage
699 :     Submitter: Emden R. Gansner, erg@research.att.com
700 :     Date: Wed Jun 4 17:35:01 EDT 1997
701 :     Version: 109.28
702 :     System: Only tested on irix-mips
703 :     Severity: minor
704 :     Problem: There seems to be a dramatic increase in make time
705 :     from 109.27 to 109.28
706 :     Code:
707 :     Transcript:
708 :     <load in CML & eXene, plus 3 small files>
709 :     <edit one file and run CM.make()>
710 :     In 109.27, the entire process takes 20 secs and I get something like
711 :     the following:
712 :    
713 :     [dependency analysis completed]
714 :     GC #3.23.28.47.230.7259: (34 ms)
715 :     GC #3.23.28.47.231.7305: (29 ms)
716 :     GC #3.23.28.47.232.7343: (18 ms)
717 :     GC #3.24.29.48.233.7406: (127 ms)
718 :     GC #3.24.29.48.234.7455: (9 ms)
719 :     GC #3.24.29.48.235.7523: (18 ms)
720 :     GC #3.24.29.48.236.7581: (23 ms)
721 :     GC #3.24.29.48.237.7657: (19 ms)
722 :     GC #3.24.29.48.238.7735: (29 ms)
723 :     [compiling bezier.sml -> CM/mipseb-unix/bezier.sml.bin]
724 :    
725 :     In 109.28, the entire process takes 60 secs and I get something like
726 :     the following:
727 :    
728 :     [dependency analysis completed]
729 :     GC #2.15.16.21.104.6631: (35 ms)
730 :     GC #2.15.16.21.105.6741: (19 ms)
731 :     GC #2.15.16.21.106.6841: (10 ms)
732 :     GC #2.15.16.21.107.6955: (13 ms)
733 :     GC #2.15.16.21.108.7097: (7 ms)
734 :     GC #2.15.16.21.109.7242: (5 ms)
735 :     GC #2.15.16.21.110.7341: (48 ms)
736 :     GC #2.16.17.22.111.7408: (97 ms)
737 :     GC #2.16.17.22.112.7417: (1 ms)
738 :     GC #2.16.17.22.113.7453: (34 ms)
739 :     GC #2.16.17.22.114.7520: (8 ms)
740 :     GC #2.16.17.22.115.7586: (42 ms)
741 :     GC #2.17.18.23.116.7728: (159 ms)
742 :     GC #3.18.19.24.117.7774: (736 ms)
743 :     GC #3.18.19.24.118.7816: (37 ms)
744 :     GC #3.18.19.25.119.7887: (33 ms)
745 :     GC #3.18.19.25.120.7968: (43 ms)
746 :     GC #3.18.19.25.121.8107: (31 ms)
747 :     GC #3.18.19.25.122.8258: (17 ms)
748 :     GC #3.18.19.25.123.8389: (17 ms)
749 :     [compiling bezier.sml -> CM/mipseb-unix/bezier.sml.bin]
750 :    
751 :     Comments:
752 :     This was caused by supplying a context entityEnv when building a
753 :     realization for a closed signature in modules/instantiate.sml.
754 :     Fix:
755 :     Test:
756 :     Owner: dbm
757 :     Status: fixed in 109.30
758 :     ----------------------------------------------------------------------
759 :     Number: 1215
760 :     Title: Unaligned access messages
761 :     Keywords: reals, real arrays, alignment
762 :     Submitter: George Russell <george@persimmon.co.uk>
763 :     Date: 4/3/97
764 :     Version: 109.26
765 :     System: alpha, OSF4.0 (& probably OSF3.2)
766 :     Severity: major
767 :     Problem:
768 :     Following code produces lots and lots of "Unaligned access . . ."
769 :     messages.
770 :     Code:
771 :     Array.tabulate(500,fn i=>RealArray.array(500,0.0));
772 :     Transcript:
773 :     Comments: [Lal]
774 :     This bug appears to be garbage collection related.
775 :     Executing:
776 :    
777 :     Array.tabulate(100, fn i=>RealArray.array(500,0.0));
778 :    
779 :     results in a large number of unaligned accesses. However, executing
780 :     this under:
781 :    
782 :     sml @SMLalloc=10M
783 :    
784 :     works fine.
785 :     [jhr, 7/31/97]
786 :     This is the same as bug 1227, which is fixed in 109.30.
787 :     Fix:
788 :     Test: bug1215.sml
789 :     Owner: Lal, jhr
790 :     Status: fixed in 109.30 [jhr]
791 :     ----------------------------------------------------------------------
792 :     Number: 1216
793 :     Title: curried higher-order functors not accepted
794 :     Keywords: modules, functors, higher-order functors
795 :     Submitter: Zhong Shao (shao@cs.yale.edu)
796 :     Date: April 4, 1997
797 :     Version: 109.29
798 :     System: all platform
799 :     Severity: minor
800 :     Problem: curried higher-order functors not accepted
801 :     Code:
802 :    
803 :     signature SIG = sig end
804 :     functor F (A : SIG) (B : SIG) = struct end
805 :     structure V = struct end
806 :     structure X = F (struct end) (struct end)
807 :     structure Y = F (structure A = V) (structure B = V);
808 :    
809 :     structure Z = F V V ; (* this one is problematic *)
810 :    
811 :     Transcript:
812 :    
813 :     - signature SIG = sig end
814 :     functor F : <sig>
815 :     structure V : sig end
816 :     structure X : sig end
817 :     structure Y : sig end
818 :     - stdIn:94.23 Error: syntax error found at ID
819 :    
820 :     Comments:
821 :    
822 :     Probably this is not a bug. But I was never clear about
823 :     the currying syntax for higher-order functors. Is the
824 :     functor application "(F V V)" allowed ?
825 :    
826 :     [dbm]
827 :     Not a bug. Parantheses are required around all functor arguments.
828 :     Fix:
829 :     Test: bug1216.sml
830 :     Owner: dbm
831 :     Status: not a bug
832 :     ----------------------------------------------------------------------
833 :     Number: 1217
834 :     Title: Compiler generates exception [FPRegEA].
835 :     Keywords: code generation
836 :     Submitter: ?
837 :     Date: 5/1/97
838 :     Version: 109.27
839 :     System: x86-linux
840 :     Severity: major
841 :     Problem: Compiler generates exception [FPRegEA].
842 :     Code: val foo = fn x : 'a * 'b => [x]
843 :     val bar = fn y => foo(y,13)
844 :     Transcript:
845 :     Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
846 :     - val foo = fn x : 'a * 'b => [x]
847 :     val bar = fn y => foo(y,13) ;
848 :    
849 :     uncaught exception in compiler: FPRegEA
850 :     raised at: cps/generic.sml:98.67-98.74
851 :     util/stats.sml:164.40
852 :     util/stats.sml:164.40
853 :     build/evalloop.sml:191.58
854 :    
855 :     Comments: For the polymorphic function 'foo',
856 :     because 'x' is put in a list, representation analysis
857 :     generates special code (governed by a runtime test) that
858 :     coerces 'x' to its boxed representation if 'x' is a pair
859 :     of floats. In the cps optimizer, because the call to
860 :     'foo' in 'bar' is known, it is inlined. Because the type
861 :     of 'y' is unknown, the runtime test in 'foo' remains, and the
862 :     special case code for floating points is not dead.
863 :     However, the record '(y,13)' is known and the coercion
864 :     code for floating point attempts to coerce this record
865 :     to its boxed representation, which causes it to think
866 :     that '13' can be put in a floating point register.
867 :    
868 :     The bug occurs if you attempt to batch compile ml-yacc
869 :     (i.e. if you cat all the source files and compile as one
870 :     declaration).
871 :    
872 :     Fix: This is speculative, but the representation analysis uses
873 :     the following idiom, which is not type correct:
874 :    
875 :     Lambda alpha. lambda z:alpha.
876 :     typecase alpha of
877 :     float => <code depends on z being a float>
878 :     _ => <code that ignores the type of z>
879 :    
880 :     The idiom could be replaced by the following, which is
881 :     type correct:
882 :    
883 :     Lambda alpha.
884 :     typecase alpha of
885 :     float => lambda z:float.<code depends on z being a float>
886 :     _ => lambda z:alpha.<code that ignores the type of z>
887 :    
888 :     Comment:
889 :     [Lorenz, 5/1/97]
890 :     For what it's worth, this bug appeared in the transition from
891 :     109.23 to 109.24, appears (at least) on x86-linux and sparc-solaris,
892 :     but not on mipseb-unix.
893 :    
894 :     [Zhong, 5/1/97]
895 :     Thanks for the bug report (and also suggestion the fix). This was really
896 :     bug 1175 in the masterbug list. I have fixed it and will incorporate
897 :     the fix into 109.28.
898 :    
899 :     Test: bug1217.sml
900 :     Owner: Zhong
901 :     Status: fixed in 109.28 [Zhong]
902 :     ----------------------------------------------------------------------
903 :     Number: 1218
904 :     Title: increase in size of exportFn image
905 :     Keywords: exportFn, image size
906 :     Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
907 :     Date: 5/1/97
908 :     Version: 109.27
909 :     System: ?
910 :     Severity: major
911 :     Problem:
912 :     The size of the image that is exported with 109.27
913 :     is significantly higher than with for instance version
914 :     108. I made the following tests:
915 :     Transcript:
916 :     [108:]
917 :    
918 :     structure Test =
919 :     struct
920 :    
921 :     fun dummy(_,[name]) =
922 :     (print ("Hi I am "^name^"\n"))
923 :    
924 :     fun export() =
925 :     exportFn("/step/sml-108/bin/.heap/hi",dummy)
926 :    
927 :     end
928 :    
929 :    
930 :     [109.27:]
931 :    
932 :     structure Test =
933 :     struct
934 :    
935 :     fun dummy(name,_) =
936 :     (TextIO.print ("Hi I am "^name^"\n");
937 :     OS.Process.success)
938 :    
939 :     fun export() =
940 :     SMLofNJ.exportFn("/step/sml/bin/.heap/hi",dummy)
941 :    
942 :     end
943 :    
944 :     The sizes of the exported images were:
945 :    
946 :     108:
947 :     -rw-rw---- 1 nikolaj 196292 May 1 22:42 hi
948 :    
949 :     109.27
950 :     -rw-rw---- 1 nikolaj 500824 May 1 22:38 hi.sparc-solaris
951 :    
952 :     For larger executables the situation gets even worse. I
953 :     reported an image size of more than 35 MB in 109.27 compared
954 :     to approx 13 MB in 108.
955 :    
956 :     Comments:
957 :     [Zhong, 5/2/97]
958 :     This difference seems to be caused from changes in the runtime
959 :     system, as even the image for a null function is about this
960 :     big.
961 :    
962 :     fun export1() = SMLofNJ.exportFn("xxx1", dummy);
963 :     fun export2() = SMLofNJ.exportFn("xxx2", fn _ => 0);
964 :    
965 :     -rw-r--r-- 1 shao systems 449616 May 2 09:38 xxx1.sparc-solaris
966 :     -rw-r--r-- 1 shao systems 433232 May 2 10:55 xxx2.sparc-solaris
967 :    
968 :     I also checked the runtime closures for both the dummy function and
969 :     the "fn _ => 0" function, they all contain minimum amount of
970 :     free variables.
971 :    
972 :     |> For larger executables the situation gets even worse. I
973 :     |> reported an image size of more than 35 MB in 109.27 compared
974 :     |> to approx 13 MB in 108.
975 :     |>
976 :     |> Is there any way to improve on this situation?
977 :    
978 :     This could be caused by completely different reasons from the previous.
979 :     Sorry for keeping asking this, but if you can ship us the entire
980 :     source code, we can probably take a look and narrow the problem down
981 :     for you.
982 :    
983 :     [Nikolaj, 5/20/97]
984 :     A.
985 :     --
986 :    
987 :     I was asked if I could provide a more realistic example
988 :     where the size of the exported image problem showed up
989 :     in the 109 version. The example directory in eXene
990 :     (the bricks example) appears to be excellent.
991 :    
992 :     With 108:
993 :    
994 :     -rw-rw---- 1 nikolaj 1490428 May 20 14:17 /step/sml-108/bin/.heap/bricks
995 :    
996 :     With 109.27:
997 :    
998 :     -rw-rw---- 1 nikolaj 12978676 May 20 14:21 /step/sml/bin/.heap/bricks.sparc-solaris
999 :    
1000 :     As we can see, the size of the image is almost 10 times larger for this small eXene example.
1001 :    
1002 :    
1003 :     The size problem seems however not to be an artifact of eXene.
1004 :     I have exported images that are purely ML (that do not use CML)
1005 :     that are much larger than they should be. The fact that I am using
1006 :     an eXene demo is that it was the first and best example that I could find.
1007 :    
1008 :    
1009 :     B.
1010 :     --
1011 :    
1012 :     I have previously reported problems with CM. I still think there is something
1013 :     fishy about CM. Some of the problems appear to arise when the same files are loaded
1014 :     using different .cm files. If person A has one cm file and person B has a different
1015 :     one that loads different files, and A and B both use SCCS they may see different
1016 :     versions of files that other files depend on. It is typically possible to hack around
1017 :     this so I have not been eager to clarify the source of the problems precisely.
1018 :    
1019 :     C.
1020 :     --
1021 :    
1022 :     eXene/CML may have some problems running under Linux and over the network.
1023 :     We have just started to port our system to a laptop (IBM thinkpad 760 E).
1024 :     Here the Inbuf appears to die as well as IO exceptions are raised at will.
1025 :     Over the network (phone line) in Inbuf dies. Other applications (emacs,...)
1026 :     do not have these problems.
1027 :    
1028 :     -----------------------------------------------
1029 :    
1030 :    
1031 :     Below follows the modifications I did to export the images (so you can reproduce it):
1032 :    
1033 :     109:
1034 :    
1035 :     examples/bricks/sources.cm:
1036 :     Group
1037 :     is
1038 :    
1039 :     cml.cm
1040 :     cml-lib.cm
1041 :     ../../sources.cm
1042 :    
1043 :     util.sml
1044 :     brickview.sml
1045 :     brick.sml
1046 :     wall.sml
1047 :     badbricks.sml
1048 :     export.sml
1049 :    
1050 :    
1051 :     examples/bricks/export.sml:
1052 :    
1053 :    
1054 :     structure Export =
1055 :     struct
1056 :    
1057 :     val tq = Time.fromMilliseconds 20
1058 :    
1059 :     fun main(name,display::args) =
1060 :     (RunCML.doit(fn ()=>BadBricks.badBricks display,SOME tq);
1061 :     OS.Process.success)
1062 :    
1063 :     fun export() =
1064 :     SMLofNJ.exportFn("/step/sml/bin/.heap/bricks",main)
1065 :    
1066 :     end
1067 :    
1068 :     -----------------------------------------------
1069 :     108:
1070 :    
1071 :     examples/bricks/sources.cm:
1072 :     (* sources file for triangle demo *)
1073 :     Group
1074 :     is
1075 :     /step/sml-108/lib/smlnj-lib.cm
1076 :     /step/sml-108/lib/cml.cm
1077 :     /step/sml-108/lib/cml-lib.cm
1078 :     ../../sources.cm
1079 :    
1080 :     util.sml
1081 :     brickview.sml
1082 :     brick.sml
1083 :     wall.sml
1084 :     badbricks.sml
1085 :     export.sml
1086 :    
1087 :     examples/bricks/export.sml:
1088 :    
1089 :    
1090 :     structure Export =
1091 :     struct
1092 :    
1093 :     fun main(env,display::args) =
1094 :     BadBricks.badBricks display
1095 :    
1096 :     fun export() =
1097 :     RunCML.exportFn("/step/sml-108/bin/.heap/bricks",main,SOME 20)
1098 :    
1099 :     end
1100 :    
1101 :    
1102 :     examples/bricks/brickview.sml:
1103 :     This does not compile under 108, so I corrected it with parts from 109.
1104 :    
1105 :     Replaced:
1106 :    
1107 :     fun showText (backc, framec) txt _ = (
1108 :     Label.setBackground label backc;
1109 :     Label.setLabel label (Label.Text txt);
1110 :     Frame.setColor frame framec;
1111 :     framec)
1112 :    
1113 :     val showView = showText (#concrete palette, SOME(#lightLines palette))
1114 :     val endView = showText (#brick palette, SOME(#lightLines palette))
1115 :     val markView = showText (#mark palette, SOME(#darkLines palette)) "ok"
1116 :     val normView = showText (#brick palette, SOME(#darkLines palette)) ""
1117 :    
1118 :     examples/bricks/wall.sml:
1119 :     This does not compile under 108, so I corrected it with parts from 109.
1120 :    
1121 :     Replaced:
1122 :    
1123 :     fun setMsg txt = Label.setLabel msgArea (Label.Text txt)
1124 :    
1125 :     [Zhong, 5/21/97]
1126 :     Hi, Nikolaj, Thanks very much for narrowing down the problem for us.
1127 :     I can reproduce the image size using the following export.sml:
1128 :    
1129 :     structure Export =
1130 :     struct
1131 :     fun export() =
1132 :     SMLofNJ.exportFn("bricks", fn _ => (RunCML.doit (fn () => (), NONE); 0))
1133 :     end
1134 :    
1135 :     There are definitely wierd thing going on with exportFn. As if I use
1136 :     the following sources.cm file:
1137 :    
1138 :     Group
1139 :     is
1140 :    
1141 :     cml.cm
1142 :     cml-lib.cm
1143 :     ../../sources.cm
1144 :    
1145 :     util.sml
1146 :     brickview.sml
1147 :     brick.sml
1148 :     wall.sml
1149 :     badbricks.sml
1150 :     export.sml
1151 :    
1152 :     I get 12Mbytes image, while if I use this sources.cm file:
1153 :    
1154 :     Group
1155 :     is
1156 :    
1157 :     cml.cm
1158 :     cml-lib.cm
1159 :     export.sml
1160 :    
1161 :     I get only 8.2Mbytes. Even though export.sml does not refer to
1162 :     anything in eXene or brick code at all.
1163 :    
1164 :     Clearly, the closure for RunCML.doit function contains a pointer
1165 :     to all the toplevel environments. Even worse, I am afraid that
1166 :     it contains a pointer to the top-level environment (where code
1167 :     for bricks and eXene stays).
1168 :    
1169 :     This bug occurs also in version 109.16 (with probably 1.2 Mbytes
1170 :     smaller image size, which is the image size difference between
1171 :     sml-cm-109.16 and sml-cm-109.27).
1172 :    
1173 :     John, what are the main differences between 108's RunCML.doit and
1174 :     109.16's RunCML.doit ? Would the new code possibly hold more
1175 :     free variables ?
1176 :    
1177 :     |> The size problem seems however not to be an artifact of eXene.
1178 :     |> I have exported images that are purely ML (that do not use CML)
1179 :     |> that are much larger than they should be. The fact that I am using
1180 :     |> an eXene demo is that it was the first and best example that I could find.
1181 :    
1182 :     It is possible that the image-size problems for these purely-ML code
1183 :     are caused by different reasons (from the brick example above). We'll
1184 :     continue diagnosing the problem, at the same time, we would very
1185 :     appreciate you send us new (purely-ML) examples if you happen to run
1186 :     into any of them in the future.
1187 :    
1188 :     [Bjorner, 8/7/97]
1189 :     The recent bugfixes in version 109.30 offered some hopes that
1190 :     the heap size bug has been fixed. This appears not to be the
1191 :     case:
1192 :    
1193 :     -rw-rw---- 1 root 14293696 Aug 7 08:38 bricks.sparc-solaris
1194 :    
1195 :     is the 109.30 size of the bricks exported image. Compared with
1196 :     previous sizes this is a clear worsening.
1197 :    
1198 :     [Bjorner, 8/7/97]
1199 :     I have previously communicated with various members of the SML/NJ
1200 :     team on the memory problems in versions 109.**. Desparately trying
1201 :     to track the problem down further in 109.30 (it is really a serious
1202 :     problem for us and others who wish to use SML/NJ images on reasonable
1203 :     hardware) I ran into the following simple scenario that can recreate
1204 :     some weird memory behaviour.
1205 :    
1206 :     I am still a bit frustrated that I am don't have an overview of the
1207 :     source code of SML/NJ which could allow me to track the problem in
1208 :     a more systematic way. What are the documents describing the design
1209 :     of the present compiler?
1210 :    
1211 :     Regards
1212 :     Nikolaj
1213 :    
1214 :    
1215 :     ---------------------------------------------
1216 :    
1217 :     sources.cm:
1218 :    
1219 :     Group
1220 :     is
1221 :    
1222 :    
1223 :     (** (* C *)
1224 :     cml.cm
1225 :     cml-lib.cm
1226 :    
1227 :     **)
1228 :    
1229 :     export.sml
1230 :    
1231 :    
1232 :     --------------------
1233 :    
1234 :    
1235 :     structure Export =
1236 :     struct
1237 :    
1238 :     val tq = Time.fromMilliseconds 20
1239 :    
1240 :     fun main(name,display::args) =
1241 :     (** (* A *)
1242 :     (TextIO.print "dummy"; OS.Process.success)
1243 :     **)
1244 :     (** (* B *)
1245 :     (RunCML.doit(fn ()=>(),SOME tq);
1246 :     OS.Process.success)
1247 :     **)
1248 :    
1249 :    
1250 :     fun export() =
1251 :     SMLofNJ.exportFn("dummy",main)
1252 :    
1253 :     end
1254 :    
1255 :     --------------------
1256 :    
1257 :     1. To obtain an image of with 318 big objects (9 MB!) uncomment C and B.
1258 :    
1259 :     2. Then comment B, and uncomment A. This still gives the same image size.
1260 :    
1261 :     3. Then comment C. This gives 38 big objects, about 0.5 MB (nice and "small").
1262 :    
1263 :     4. Then uncomment C. This still gives only 38 big objects, different than
1264 :     point 2 although the CM.sa files look exactly the same!
1265 :     It has been listed below.
1266 :    
1267 :     To narrow the source of the problems down further it should also
1268 :     be possible to recreate the situation with the reference to cml-lib.cm
1269 :     deleted from the sources.cm. This already seems to follow from the CM.sa
1270 :     generate file below.
1271 :     Even when replacing C by:
1272 :    
1273 :     /sml-109.30/src/cml/src/Unix/sources.cm
1274 :    
1275 :     in step 2 I get the 9 MB large image size.
1276 :    
1277 :     In comparison when compiling the following under version 108 I only
1278 :     get 22 big objects ( 0.3 MB). This is the 108 equivalent of step 1 above.
1279 :    
1280 :     sources.cm
1281 :     ----------
1282 :    
1283 :     Group
1284 :     is
1285 :    
1286 :     /sml-108/lib/cml.cm
1287 :    
1288 :     export.sml
1289 :    
1290 :    
1291 :     export.sml
1292 :     ----------
1293 :    
1294 :     structure Export =
1295 :     struct
1296 :    
1297 :     val tq = Time.fromMilliseconds 20
1298 :    
1299 :     fun main(name,display::args) =
1300 :     (RunCML.doit(fn ()=>(),SOME 20);())
1301 :    
1302 :    
1303 :     fun export() =
1304 :     exportFn("dummy",main)
1305 :    
1306 :     end
1307 :    
1308 :    
1309 :    
1310 :     ------------------------------------------------------
1311 :    
1312 :     CM.sa for step 1,2,3,4:
1313 :    
1314 :     local open Compiler.CMSA val pervenv = pervenv ()
1315 :     val o1 = run ("/step/sml-109.30/src/cml/src/core-cml/rep-types.sml", pervenv)
1316 :     val d0 = layer [o1, pervenv]
1317 :     val o2 = run ("/step/sml-109.30/src/cml/src/core-cml/queue.sml", d0)
1318 :     val o3 = run ("/step/sml-109.30/src/cml/src/core-cml/debug.sml", pervenv)
1319 :     val d1 = layer [o1, o2, o3, pervenv]
1320 :     val o4 = run ("/step/sml-109.30/src/cml/src/core-cml/scheduler.sml", d1)
1321 :     val o5 = run ("/step/sml-109.30/src/cml/src/core-cml/event-sig.sml", pervenv)
1322 :     val d2 = layer [o1, o4, o5, pervenv]
1323 :     val o6 = run ("/step/sml-109.30/src/cml/src/core-cml/event.sml", d2)
1324 :     val d3 = layer [o6, pervenv]
1325 :     val o21 = run ("/step/sml-109.30/src/cml/src/OS/os-io-sig.sml", d3)
1326 :     val o22 = run ("/step/sml-109.30/src/cml/src/OS/os-process-sig.sml", d3)
1327 :     val d4 = layer [o21, o22, pervenv]
1328 :     val o23 = run ("/step/sml-109.30/src/cml/src/OS/os-sig.sml", d4)
1329 :     val d5 = layer [o21, o22, o23, pervenv]
1330 :     val o24 = run ("/step/sml-109.30/src/cml/src/OS/os-signatures.sml", d5)
1331 :     val f0 = filter [SIG "OS", SIG "OS_IO", SIG "OS_PROCESS"]
1332 :     val d6 = f0 o24
1333 :     val d7 = layer [o1, o4, o6, pervenv]
1334 :     val o13 = run ("/step/sml-109.30/src/cml/src/core-cml/io-manager.sml", d7)
1335 :     val o0 = run ("/step/sml-109.30/src/cml/src/core-cml/version.sml", pervenv)
1336 :     val o7 = run ("/step/sml-109.30/src/cml/src/core-cml/thread-sig.sml", pervenv)
1337 :     val d8 = layer [o1, o4, o6, o7, pervenv]
1338 :     val o8 = run ("/step/sml-109.30/src/cml/src/core-cml/thread.sml", d8)
1339 :     val o9 = run ("/step/sml-109.30/src/cml/src/core-cml/channel-sig.sml", pervenv)
1340 :     val d9 = layer [o1, o2, o4, o6, o8, o9, pervenv]
1341 :     val o10 = run ("/step/sml-109.30/src/cml/src/core-cml/channel.sml", d9)
1342 :     val o11 = run ("/step/sml-109.30/src/cml/src/core-cml/timeout-sig.sml", pervenv)
1343 :     val d10 = layer [o1, o4, o6, o11, pervenv]
1344 :     val o12 = run ("/step/sml-109.30/src/cml/src/core-cml/timeout.sml", d10)
1345 :     val d11 = layer [o5, o7, o9, o11, pervenv]
1346 :     val o14 = run ("/step/sml-109.30/src/cml/src/core-cml/cml-sig.sml", d11)
1347 :     val d12 = layer [o0, o6, o8, o10, o12, o14, pervenv]
1348 :     val o15 = run ("/step/sml-109.30/src/cml/src/core-cml/cml.sml", d12)
1349 :     val d13 = layer [o13, o15, d6, pervenv]
1350 :     val o25 = run ("/step/sml-109.30/src/cml/src/Unix/os-io.sml", d13)
1351 :     val f1 = filter [SIG "OS", STR "OS_Process", SIG "OS_IO", STR "OS_IO", SIG "OS_PROCESS", STR "ProcManager"]
1352 :     val d14 = f1 o25
1353 :     val d15 = layer [o15, pervenv]
1354 :     val o16 = run ("/step/sml-109.30/src/cml/src/core-cml/sync-var-sig.sml", d15)
1355 :     val d16 = layer [o1, o2, o4, o16, pervenv]
1356 :     val o17 = run ("/step/sml-109.30/src/cml/src/core-cml/sync-var.sml", d16)
1357 :     val d17 = layer [o15, o17, pervenv]
1358 :     val o20 = run ("/step/sml-109.30/src/cml/src/util/result.sml", d17)
1359 :     val d18 = layer [o4, o6, o20, pervenv]
1360 :     val o26 = run ("/step/sml-109.30/src/cml/src/Unix/proc-manager.sml", d18)
1361 :     val d19 = layer [o26, o4, o6, d6, pervenv]
1362 :     val o27 = run ("/step/sml-109.30/src/cml/src/Unix/os-process.sml", d19)
1363 :     val d20 = f1 o27
1364 :     val d21 = layer [d6, d14, d20, pervenv]
1365 :     val o45 = run ("/step/sml-109.30/src/cml/src/Unix/os.sml", d21)
1366 :     val f2 = filter [STR "OS", SIG "UNIX", STR "Unix", STR "TextPrimIO", STR "BinPrimIO", SIG "OS_IO", STR "BinIO", STR "RunCML", SIG "OS_PROCESS", STR "TextIO"]
1367 :     val d22 = f2 o45
1368 :     val o32 = run ("/step/sml-109.30/src/cml/src/IO/prim-io-sig.sml", d15)
1369 :     val d23 = layer [o32, o15, pervenv]
1370 :     val o36 = run ("/step/sml-109.30/src/cml/src/IO/prim-io-fn.sml", d23)
1371 :     val d24 = layer [o36, pervenv]
1372 :     val o39 = run ("/step/sml-109.30/src/cml/src/IO/text-prim-io.sml", d24)
1373 :     val o34 = run ("/step/sml-109.30/src/cml/src/IO/cml-text-stream-io-sig.sml", d15)
1374 :     val d25 = layer [o34, o39, o15, pervenv]
1375 :     val o40 = run ("/step/sml-109.30/src/cml/src/IO/cml-text-io-sig.sml", d25)
1376 :     val d26 = layer [o32, pervenv]
1377 :     val o41 = run ("/step/sml-109.30/src/cml/src/IO/os-prim-io-sig.sml", d26)
1378 :     val o18 = run ("/step/sml-109.30/src/cml/src/core-cml/mailbox-sig.sml", d3)
1379 :     val d27 = layer [o1, o4, o18, pervenv]
1380 :     val o19 = run ("/step/sml-109.30/src/cml/src/core-cml/mailbox.sml", d27)
1381 :     val d28 = layer [o32, o15, o17, o19, pervenv]
1382 :     val o43 = run ("/step/sml-109.30/src/cml/src/IO/chan-io-fn.sml", d28)
1383 :     val d29 = layer [o39, o40, o41, o43, o15, o17, pervenv]
1384 :     val o44 = run ("/step/sml-109.30/src/cml/src/IO/text-io-fn.sml", d29)
1385 :     val o37 = run ("/step/sml-109.30/src/cml/src/IO/bin-prim-io.sml", d24)
1386 :     val d30 = layer [o45, o4, pervenv]
1387 :     val o46 = run ("/step/sml-109.30/src/cml/src/Unix/syscall.sml", d30)
1388 :     val d31 = layer [o45, o46, o13, o15, o17, o37, o41, pervenv]
1389 :     val o47 = run ("/step/sml-109.30/src/cml/src/Unix/posix-bin-prim-io.sml", d31)
1390 :     val d32 = layer [o47, o15, o17, o39, o41, pervenv]
1391 :     val o49 = run ("/step/sml-109.30/src/cml/src/Unix/posix-text-prim-io.sml", d32)
1392 :     val d33 = layer [o49, o44, pervenv]
1393 :     val o50 = run ("/step/sml-109.30/src/cml/src/Unix/posix-text-io.sml", d33)
1394 :     val d34 = f2 o50
1395 :     val d35 = layer [d22, d34, pervenv]
1396 :     val o153 = run ("export.sml", d35)
1397 :     in val _ = register o153 end
1398 :    
1399 :     Fix:
1400 :     Optimization to lift structure references out of closures restored (it
1401 :     had been dropped in 109.24). Isolate function fixed. CML version of
1402 :     exportFn cleaned up.
1403 :     Test:
1404 :     Owner: Zhong, jhr
1405 :     Status: fixed in 109.31 [jhr, Zhong, 9/15/97]
1406 :     ----------------------------------------------------------------------
1407 :     Number: 1219
1408 :     Title: sml crashes while trying to print
1409 :     Keywords: printing, representations
1410 :     Submitter: Chris Paris <cap@cs.cmu.edu>
1411 :     Date: 5/5/97
1412 :     Version: 109.27
1413 :     System: sparc/solaris 5.5, mipseb
1414 :     Severity: major
1415 :     Problem:
1416 :     Printing datatype values involving ints and words causes segmentation faults.
1417 :     Transcript:
1418 :     Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
1419 :     - datatype id = ID of Int32.int;
1420 :     datatype id = ID of int32
1421 :     - ID (Int32.fromInt 0);
1422 :     Segmentation fault
1423 :    
1424 :     Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
1425 :     - datatype id = ID of int32;
1426 :     datatype id = ID of int32
1427 :     - ID (0 : int32);
1428 :     Segmentation fault
1429 :    
1430 :     Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
1431 :     - datatype id = ID of Word32.word;
1432 :     datatype id = ID of word32
1433 :     - ID (Word32.fromInt 0);
1434 :     Segmentation fault
1435 :    
1436 :     Comments:
1437 :    
1438 :     Fix:
1439 :     Test: bug1219.sml
1440 :     Owner: Zhong
1441 :     Status: fixed
1442 :     ----------------------------------------------------------------------
1443 :     Number: 1220
1444 :     Title: type definition masks datatype
1445 :     Keywords: modules, signature matching, datatypes
1446 :     Submitter: Zhong Shao
1447 :     Date: 5/7/97
1448 :     Version: 109.29
1449 :     System: -
1450 :     Severity: minor
1451 :     Problem:
1452 :     Is the following legal sml ?
1453 :    
1454 :     structure A : sig datatype t = HT end =
1455 :     struct datatype t = HT
1456 :     type t = t
1457 :     end
1458 :    
1459 :     Our compiler complains that
1460 :    
1461 :     z2.sml:1.1-4.6 Error: type t must be a datatype
1462 :     z2.sml:1.1-4.6 Error: unmatched type specification: t
1463 :    
1464 :     uncaught exception Error
1465 :     raised at: build/evalloop.sml:103.44-103.52
1466 :     build/evalloop.sml:120.38
1467 :     build/evalloop.sml:192.58
1468 :     build/evalloop.sml:284.46-284.49
1469 :    
1470 :     Changing it to the following works as expected:
1471 :    
1472 :     structure A : sig datatype t = HT end =
1473 :     struct datatype t = HT
1474 :     datatype t = datatype t
1475 :     end
1476 :    
1477 :     Code:
1478 :     Transcript:
1479 :     Comments:
1480 :     Check whether this is legal.
1481 :     Fix:
1482 :     Test:
1483 :     Owner: dbm
1484 :     Status: open
1485 :     ----------------------------------------------------------------------
1486 :     Number: 1221
1487 :     Title: type inference of literals is quirky
1488 :     Keywords: type inference, literals
1489 :     Submitter: Perry Cheng; pscheng@cs.cmu.edu
1490 :     Date: 5/9/97
1491 :     Version: 109.25, 109.29
1492 :     System: alpha DEC UNIX 3.2
1493 :     Severity: minor
1494 :     Problem: The type of word literals seems to fail when they occur
1495 :     in top-level bindings inside a structure.
1496 :     Transcript:
1497 :    
1498 :     - let val ten = 0w10 val y = Word32.div(ten,ten) in y end;
1499 :     val it = 0wx1 : Word32.word
1500 :     - structure X = struct val ten = 0w10 val y = Word32.div(ten,ten) end;
1501 :     stdIn:270.21-277.4 Error: operator and operand don't agree (tycon mismatch)
1502 :     operator domain: Word32.word * Word32.word
1503 :     operand: word * word
1504 :     in expression:
1505 :     Word32.div (ten,ten)
1506 :    
1507 :     Comments:
1508 :     This is not a bug because of the way literal overloading is resolved
1509 :     in let expressions vs within structures. The overloading is resolved
1510 :     at each structure element declaration, meaing that the type of ten
1511 :     in structure X will default to Word.word, not Word32.word. In the
1512 :     let expression the resolution of the type of ten is not done until
1513 :     after the body is typed.
1514 :     Fix:
1515 :     Test: bug1221.sml
1516 :     Owner: dbm
1517 :     Status: not a bug
1518 :     ----------------------------------------------------------------------
1519 :     Number: 1222
1520 :     Title: ref assignment not performed before overflow
1521 :     Keywords:
1522 :     Submitter: Lorenz Huelsbergen (lorenz@research.bell-labs.com)
1523 :     Date: 5/27/97
1524 :     Version: 109.28
1525 :     System: mipseb-irix5 (but not sparc-solaris)
1526 :     Severity: major
1527 :     Problem: ref assignment not performed before overflow
1528 :     Code:
1529 :     val x = ref 0;
1530 :    
1531 :     fun f n : unit =
1532 :     (x := !x + 1;
1533 :     f (n+1));
1534 :    
1535 :     f (valOf Int.maxInt);
1536 :     x; (* should be 1 *)
1537 :    
1538 :     Transcript:
1539 :    
1540 :     - : canna.research.bell-labs.com 178;
1541 :     Standard ML of New Jersey, Version 109.28, May 23, 1997 [new runtime]
1542 :     - val x = ref 0;
1543 :     val x = ref 0 : int ref
1544 :     - fun f n : unit =
1545 :     (x := !x + 1;
1546 :     f (n+1));
1547 :     = = val f = fn : int -> unit
1548 :     - ;
1549 :     - f (valOf Int.maxInt);
1550 :    
1551 :     uncaught exception Overflow [overflow]
1552 :     - x; (* should be 1 *)
1553 :     val it = ref 0 : int ref
1554 :     -
1555 :    
1556 :     Comments:
1557 :     Appears to be work properly on sparc.
1558 :     Fix:
1559 :     The problem is caused by the following CPS fragment generated
1560 :     by unrolling f a couple of times:
1561 :    
1562 :     f772(v785[I],v784[PV]) =
1563 :     !(v784) -> v698[PV] .. 1
1564 :     +i31(v698,(I)1) -> v710[I] .. 2
1565 :     unboxedupdate(v784,(I)0,v710) .. 3
1566 :     +i31(v785,(I)1) -> v740[I] .. 4
1567 :     !(v784) -> v758[PV] .. 5
1568 :     +i31(v758,(I)1) -> v759[I] .. 6
1569 :     unboxedupdate(v784,(I)0,v759) .. 7
1570 :     +i31(v740,(I)1) -> v760[I] .. 8
1571 :     (L)f772(v760,v784) .. 9
1572 :    
1573 :     In mips/mipsdepend.sml the use/def information associated with
1574 :     trapping add is given by:
1575 :    
1576 :     fun arith_ud(rd,rs,ea) = (exnptr::(reg rs @ arithOpndUse ea), reg rd)
1577 :    
1578 :     The problem with this, is that there is no dependence of any kind with
1579 :     memory. Thus there is nothing preventing (trapping) instruction 4 from
1580 :     being scheduled before 3. [I cannot believe that we haven't tripped
1581 :     this bug earlier.]
1582 :    
1583 :     It doesn't matter what kind of dependency is introduced so I think I
1584 :     prefer to create a regular data dependency and define arith_ud as:
1585 :    
1586 :     fun arith_ud(rd,rs,ea) =
1587 :     (mem::exnptr::(reg rs @ arithOpndUse ea), reg rd)
1588 :    
1589 :     This essentially says that the trapping instruction will use memory
1590 :     on a trap. A similar consideration should be made with arith3_ud and
1591 :     mult_ud.
1592 :     -- Lal
1593 :    
1594 :     Test:
1595 :     Owner:
1596 :     Status: fixed in 109.31 [Lal, 8/18/97]
1597 :     ----------------------------------------------------------------------
1598 :     Number: 1223
1599 :     Title: Compiler bug: ModuleUtil: strId after unbound structure in functor
1600 :     Keywords: modules, unbound identifier, secondary error
1601 :     Submitter: Chris Paris (cap@cs.cmu.edu)
1602 :     Date: 6/15/97
1603 :     Version: 109.29
1604 :     System: -
1605 :     Severity: minor
1606 :     Problem: Unbound structure identifier in a functor body leads to
1607 :     "Compiler bug: ModuleUtil: strId".
1608 :     Code:
1609 :     functor A () = struct structure B = B end;
1610 :     Transcript:
1611 :     Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled]
1612 :     - functor A () = struct structure B = B end;
1613 :     stdIn:17.37 Error: unbound structure: B
1614 :     Error: Compiler bug: ModuleUtil: strId
1615 :     Comments:
1616 :     Fix:
1617 :     Test: bug1223.sml
1618 :     Owner: Zhong
1619 :     Status: fixed in 109.31 [Zhong, 8/14/97]
1620 :     ----------------------------------------------------------------------
1621 :     Number: 1224
1622 :     Title: representation foulup
1623 :     Keywords: data representation
1624 :     Submitter: Chris Paris
1625 :     Date: 6/15/97
1626 :     Version: 109.28?
1627 :     System: ?
1628 :     Severity: major
1629 :     Problem:
1630 :     Execution gives wrong answers or core dumps.
1631 :     Code:
1632 :     structure T =
1633 :     struct
1634 :     datatype 'a pref = PREF of {obj : 'a}
1635 :     fun apply (PREF {obj}, arg) = obj arg
1636 :    
1637 :     fun f ((x, y), z) = y
1638 :    
1639 :     fun s () = apply (PREF {obj=f}, (("one", "two"), "three"))
1640 :     fun t () = apply (PREF {obj=f}, (("one", "two"), ()))
1641 :     end;
1642 :     T.s();
1643 :     T.t();
1644 :     Transcript:
1645 :     - T.s();
1646 :     val it = "three" : string (* should be "two" *)
1647 :     - T.t();
1648 :     Bus error (* tries to print a unit as a string? *)
1649 :    
1650 :     Comments: [Paris]
1651 :     Something interesting happens if I change the definition of f to
1652 :     fun f ((x, y), z) = x
1653 :     Then we get
1654 :    
1655 :     - T.s();
1656 :     val it =
1657 :     "\238\160\145\224\238\160\145\208\238\1335X\238\^Q\218\244\238\147 0\000\000\^A\219\000\000\000\^A\238\029\231\^H\000\000\000\^E\238\029\231\^P\238\029\231\^X\238\029\231 \000\000\000\^E\238\029\231(\000\000\000\^E\238\029\2310\238\178\250\192\000\000#"
1658 :     : string
1659 :    
1660 :     And if f is fun f ((x, y), z) = z, then the file doesn't compile:
1661 :    
1662 :     - use "test.sml";
1663 :     [opening test.sml]
1664 :    
1665 :     uncaught exception Lookup
1666 :     raised at: cps/nclosure.sml:384.49-384.62
1667 :     util/stats.sml:164.40
1668 :     util/stats.sml:164.40
1669 :     build/evalloop.sml:192.58
1670 :     build/evalloop.sml:284.46-284.49
1671 :     Fix:
1672 :     Test: bug1224.sml
1673 :     Owner: Zhong
1674 :     Status: fixed in 109.30 [Zhong]
1675 :     ----------------------------------------------------------------------
1676 :     Number: 1225
1677 :     Title: SMLofNJ.Internals.GC.doGC doesn't work
1678 :     Keywords: garbage collection, runtime
1679 :     Submitter: Christoph Kern <ckern@cs.ubc.ca>
1680 :     Date: 06/18/97
1681 :     Version: Version 109.28, May 23, 1997
1682 :     System: sparc-solaris (probably any)
1683 :     Severity: minor
1684 :     Problem: SMLofNJ.Internals.GC.doGC x doesn't cause a collection,
1685 :     regardless of the value of x.
1686 :     Fix:
1687 :     --- src/runtime/c-libs/smlnj-runtime/gc-ctl.c.orig Wed Jun 18 14:11:03
1688 :     1997
1689 :     +++ src/runtime/c-libs/smlnj-runtime/gc-ctl.c Wed Jun 18 14:12:51 1997
1690 :     @@ -86,7 +86,7 @@
1691 :     PVT void DoGC (ml_state_t *msp, ml_val_t arg)
1692 :     {
1693 :     heap_t *heap = msp->ml_heap;
1694 :     - int level = INT_MLtoC(arg);
1695 :     + int level = INT_MLtoC(DEREF(arg));
1696 :    
1697 :     if (level < 0)
1698 :     level = 0;
1699 :     Comment [jhr]
1700 :     I think you are right. What is happening is that the ref cell's
1701 :     address is a negative number on the sparc, but is a (large) positive
1702 :     number on the SGI. When you call doGC, it only does a minor collection,
1703 :     whereas, when I call it, it always collects all generations. I've applied
1704 :     your patch, and it will be in 109.30. Thanks.
1705 :    
1706 :     Test: *
1707 :     Owner: jhr
1708 :     Status: fixed in 109.30
1709 :     ----------------------------------------------------------------------
1710 :     Number: 1226
1711 :     Title: Ctrl-C no longer works on Alpha
1712 :     Keywords: signals, interrupt
1713 :     Submitter: Andrew.Kennedy@persimmon.co.uk
1714 :     Date: 6/17/97
1715 :     Version: 109.29
1716 :     System: Alpha
1717 :     Severity: critical
1718 :     Problem: Ctrl-C does not interrupt compilation or execution
1719 :     Comments:
1720 :     [George Russell <george@persimmon.co.uk>, 6/23/97]
1721 :     This is more about a problem reported by Andrew Kennedy, that SML109.29
1722 :     on Digital Unix 4 does not respond to <Ctrl>/C. I can now report that
1723 :     it also does not respond to
1724 :    
1725 :     kill -2 [process id]
1726 :     (IE sending SIGINT to it). However SML109.29 on Digital Unix 3.2,
1727 :     and SML109.28 on Digital Unix 4, both do respond to kill -2.
1728 :    
1729 :     [jhr, 6/23/97]
1730 :     We have not been able to reproduce these problems on our Unix 4.0
1731 :     Alpha, so we will need your help in tracking this down.
1732 :     Please try the following experiment:
1733 :    
1734 :     cd src/runtime/objs
1735 :     make -f mk.alpha32-dunix BASE_DEFS="-DSIGNAL_DEBUG"
1736 :     run.alpha32-dunix @SMLload=../../../bin/.heap/sml
1737 :     (* and then try your ^C at the SML prompt *)
1738 :    
1739 :     Another thing to try (you might do this first) is typing
1740 :    
1741 :     Signals.inqHandler Signals.sigINT;
1742 :    
1743 :     at the prompt. This should return
1744 :    
1745 :     val it = HANDLER fn : sig_action
1746 :    
1747 :     Let me know what you find out.
1748 :    
1749 :     [jhr, 6/23/97]
1750 :     In message <33AE614D.41C6@persimmon.co.uk>, George Russell writes:
1751 :     >
1752 :     > Test #1 - Ctrl/C does nothing. I'll keep this SML session going in
1753 :     > case there's anything else you want me to try.
1754 :     >
1755 :     > Test #2 yields
1756 :     > val it = IGNORE : sig_action
1757 :     > !!
1758 :     > But for 109.28 and 109.29 on 3.2 it does what you say it should do.
1759 :    
1760 :     Then the explanation is quite simple. When SML starts up, it checks
1761 :     the status of signals that it inherits from its parent process; if
1762 :     the status is SIGING, then it doesn't install a handler. This behavior
1763 :     is necessary to get sml to work properly as a background process (or
1764 :     under nohup). Why you see different behavior between 109.28 and
1765 :     109.29, I have no idea, but I think that the problem is in your
1766 :     shell environment.
1767 :    
1768 :     [jhr, 7/14/97]
1769 :     not a bug --- sml was built in a non interactive shell.
1770 :    
1771 :     Owner: jhr, Lal
1772 :     Status: not a bug
1773 :     ----------------------------------------------------------------------
1774 :     Number: 1227
1775 :     Title: Unaligned access generated from floating-point arrays
1776 :     Keywords: arrays, reals
1777 :     Submitter: Perry Cheng (pscheng@cs.cmu.edu)
1778 :     Date: 6/26/97
1779 :     Version: 109.28
1780 :     System: Alpha OSF/1 3.2
1781 :     Severity: major
1782 :     Problem: Floating point array manipulations cause unaligned accesses.
1783 :     Code: The following program computes FFTs at sizes 16, 32, ..., 65536.
1784 :     The code comes from a CAML-Lite distribution.
1785 :    
1786 :     local
1787 :     val sin = Real.Math.sin
1788 :     val cos = Real.Math.cos
1789 :     open Array
1790 :     fun abs_real(x:real) = if x < 0.0 then ~x else x
1791 :     fun print_real (x:real) = print(Real.toString x)
1792 :    
1793 :     val pi = 3.14159265358979323846
1794 :    
1795 :     val tpi = 2.0 * pi
1796 :    
1797 :     fun for(start,stop,f) =
1798 :     let fun loop i = if i > stop then () else (f i; loop (i+1))
1799 :     in
1800 :     loop start
1801 :     end
1802 :    
1803 :     val print_string : string -> unit = print
1804 :     val print_int : int -> unit = print_string o Int.toString
1805 :     val print_newline : unit -> unit = fn _ => print_string "\n"
1806 :    
1807 :     fun dump pxr pxi =
1808 :     for(0,15,fn i =>
1809 :     (print_int i;
1810 :     print " ";
1811 :     print_real (sub(pxr,i+1));
1812 :     print " ";
1813 :     print_real (sub(pxi,i+1));
1814 :     print_newline()))
1815 :    
1816 :    
1817 :     fun fft px py np =
1818 :     let val i = ref 2
1819 :     val m = ref 1
1820 :    
1821 :     val _ =
1822 :     while (!i < np) do
1823 :     (i := !i + !i;
1824 :     m := !m + 1)
1825 :     val n = !i
1826 :     in
1827 :     if n <> np then (
1828 :     for (np+1,n,fn i=>
1829 :     (update(px,i,0.0);
1830 :     update(py,i,0.0)));
1831 :     print_string "Use "; print_int n;
1832 :     print_string " point fft"; print_newline()
1833 :     ) else ();
1834 :    
1835 :     let val n2 = ref(n+n)
1836 :     in
1837 :     for(1,!m-1,fn k =>
1838 :     let val _ = n2 := !n2 div 2
1839 :     val n4 = !n2 div 4
1840 :     val e = tpi / (real (!n2 ))
1841 :     in
1842 :     for(1,n4,fn j =>
1843 :     let val a = e * real(j - 1)
1844 :     val a3 = 3.0 * a
1845 :     val cc1 = cos(a)
1846 :     val ss1 = sin(a)
1847 :     val cc3 = cos(a3)
1848 :     val ss3 = sin(a3)
1849 :     val is = ref j
1850 :     val id = ref(2 * !n2)
1851 :     in
1852 :     while !is < n do
1853 :     let val i0r = ref (!is)
1854 :     in
1855 :     while !i0r < n do
1856 :     let val i0 = !i0r
1857 :     val i1 = i0 + n4
1858 :     val i2 = i1 + n4
1859 :     val i3 = i2 + n4
1860 :     val r1 = sub(px,i0) - sub(px,i2)
1861 :     val _ = update(px,i0,sub(px,i0) + sub(px,i2))
1862 :     val r2 = sub(px,i1) - sub(px,i3)
1863 :     val _ = update(px,i1,sub(px,i1) + sub(px,i3))
1864 :     val s1 = sub(py,i0) - sub(py,i2)
1865 :     val _ = update(py,i0,sub(py,i0) + sub(py,i2))
1866 :     val s2 = sub(py,i1) - sub(py,i3)
1867 :     val _ = update(py,i1,sub(py,i1) + sub(py,i3))
1868 :     val s3 = r1 - s2
1869 :     val r1 = r1 + s2
1870 :     val s2 = r2 - s1
1871 :     val r2 = r2 + s1
1872 :     in
1873 :     update(px,i2,r1*cc1 - s2*ss1);
1874 :     update(py,i2,~s2*cc1 - r1*ss1);
1875 :     update(px,i3,s3*cc3 + r2*ss3);
1876 :     update(py,i3,r2*cc3 - s3*ss3);
1877 :     i0r := i0 + !id
1878 :     end;
1879 :     is := 2 * !id - !n2 + j;
1880 :     id := 4 * !id
1881 :     (* ; dump px py *)
1882 :     end
1883 :     end)
1884 :     end)
1885 :     end;
1886 :    
1887 :     (************************************)
1888 :     (* Last stage, length=2 butterfly *)
1889 :     (************************************)
1890 :    
1891 :     let val is = ref 1
1892 :     val id = ref 4
1893 :     in
1894 :     while !is < n do
1895 :     let val i0r = ref (!is)
1896 :     in
1897 :     while !i0r <= n do
1898 :     let val i0 = !i0r
1899 :     val i1 = i0 + 1
1900 :     val r1 = sub(px,i0)
1901 :     val _ = update(px,i0,r1 + sub(px,i1))
1902 :     val _ = update(px,i1,r1 - sub(px,i1))
1903 :     val r1 = sub(py,i0)
1904 :     in
1905 :     update(py,i0,r1 + sub(py,i1));
1906 :     update(py,i1,r1 - sub(py,i1));
1907 :     i0r := i0 + !id
1908 :     end;
1909 :     is := 2 * !id - 1;
1910 :     id := 4 * !id
1911 :     end
1912 :     end;
1913 :     (*
1914 :     print "\nbutterfly\n";
1915 :     dump px py;
1916 :     *)
1917 :     (*************************)
1918 :     (* Bit reverse counter *)
1919 :     (*************************)
1920 :    
1921 :     let val j = ref 1
1922 :     in
1923 :     for (1,n-1,fn i =>
1924 :     (if i < !j then (
1925 :     let val xt1 = sub(px,!j)
1926 :     val xt2 = sub(px,i)
1927 :     val _ = update(px,!j,xt2)
1928 :     val _ = update(px,i,xt1)
1929 :     val yt1 = sub(py,!j)
1930 :     val yt2 = sub(py,i)
1931 :     in
1932 :     update(py,!j,yt2);
1933 :     update(py,i,yt1)
1934 :     end)
1935 :     else ();
1936 :     let val k = ref(n div 2)
1937 :     in
1938 :     while !k < !j do (j := !j - !k; k := !k div 2);
1939 :     j := !j + !k
1940 :     end));
1941 :     (*
1942 :     print "\nbit reverse\n";
1943 :     dump px py;
1944 :     *)
1945 :     n
1946 :     end
1947 :     end;
1948 :    
1949 :     fun test np =
1950 :     (print_int np; print_string "... ";
1951 :     let val enp = real np
1952 :     val npm = np div 2 - 1
1953 :     val pxr = array ((np+2), 0.0)
1954 :     val pxi = array ((np+2), 0.0)
1955 :     val t = pi / enp
1956 :     val _ = update(pxr,1,(enp - 1.0) * 0.5)
1957 :     val _ = update(pxi,1,0.0)
1958 :     val n2 = np div 2
1959 :     val _ = update(pxr,n2+1,~0.5)
1960 :     val _ = update(pxi,n2+1,0.0)
1961 :     in
1962 :     for (1,npm,fn i =>
1963 :     let val j = np - i
1964 :     val _ = update(pxr,i+1,~0.5)
1965 :     val _ = update(pxr,j+1,~0.5)
1966 :     val z = t * (real i)
1967 :     val y = ~0.5 * (cos(z)/sin(z))
1968 :     in
1969 :     update(pxi,i+1,y);
1970 :     update(pxi,j+1,~y)
1971 :     end);
1972 :     (*
1973 :     print "\n"; print "before fft: \n";
1974 :     dump pxr pxi;
1975 :     *)
1976 :     fft pxr pxi np;
1977 :     (*
1978 :     print "\n"; print "after fft: \n";
1979 :     dump pxr pxi;
1980 :     *)
1981 :     let val zr = ref 0.0
1982 :     val zi = ref 0.0
1983 :     val kr = ref 0
1984 :     val ki = ref 0
1985 :     in
1986 :     for (0,np-1,fn i =>
1987 :     let val a = abs_real(sub(pxr,i+1) - (real i))
1988 :     in
1989 :     if !zr < a then
1990 :     (zr := a;
1991 :     kr := i)
1992 :     else ();
1993 :     let val a = abs_real(sub(pxi,i+1))
1994 :     in
1995 :     if !zi < a then
1996 :     (zi := a;
1997 :     ki := i)
1998 :     else ()
1999 :     end
2000 :     end);
2001 :     let val zm = if abs_real (!zr) < abs_real (!zi) then !zi else !zr
2002 :     in
2003 :     print_real zm; print_newline()
2004 :     end
2005 :     end
2006 :     end)
2007 :    
2008 :     fun doit() =
2009 :     let val np = ref 16
2010 :     in for(1,13,fn i => (test (!np); np := (!np)*2))
2011 :     end
2012 :    
2013 :     in
2014 :     val _ = doit()
2015 :     end
2016 :    
2017 :     Transcript:
2018 :    
2019 :     Standard ML of New Jersey, Version 109.28, May 23, 1997 [CM&CMB]
2020 :     val it = () : unit
2021 :     - use "/afs/cs/user/pscheng/bug.sml";
2022 :     [opening /afs/cs/user/pscheng/bug.sml]
2023 :     GC #0.0.0.0.1.6: (10 ms)
2024 :     GC #0.0.0.0.2.24: (14 ms)
2025 :     GC #0.0.0.1.3.40: (23 ms)
2026 :     GC #0.0.0.1.4.51: (16 ms)
2027 :     GC #0.0.1.2.5.60: (55 ms)
2028 :     GC #0.0.1.3.6.96: (12 ms)
2029 :     GC #0.0.1.3.7.120: (23 ms)
2030 :     16... 8.881784197e~16
2031 :     32... 3.5527136788e~15
2032 :     64... 1.06581410364e~14
2033 :     128... 2.84217094304e~14
2034 :     256... 5.68434188608e~14
2035 :     512... 1.16795462191e~13
2036 :     1024... GC #0.0.1.4.8.130: (1 ms)
2037 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c205c pc=2b439f4 ra=2b43994
2038 :     type=stt
2039 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c2064 pc=2b43a28
2040 :     ra=ffffffffffffffff type=stt
2041 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c206c pc=2b439f4
2042 :     ra=ffffffffffffffff type=stt
2043 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c2074 pc=2b43a28
2044 :     ra=ffffffffffffffff type=stt
2045 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c207c pc=2b439f4
2046 :     ra=ffffffffffffffff type=stt
2047 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c2084 pc=2b43a28
2048 :     ra=ffffffffffffffff type=stt
2049 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c208c pc=2b439f4
2050 :     ra=ffffffffffffffff type=stt
2051 :    
2052 :     Comments: This works correctly in 109.25.
2053 :     [Zhong, 6/26/97]
2054 :     This seems to be an Alpha-specific bug, as the above code work
2055 :     fine on my SPARC. Do we align all floating-point numbers on Alpha ?
2056 :     [jhr, 6/26/97]
2057 :     I suspect that it must be a bug in the code generator. The run-time
2058 :     system and garbage collector aligns all real and real array objects
2059 :     on 64-bit boundries on all machines.
2060 :    
2061 :     BTW, I hope this code is not being used for benchmarking. It uses
2062 :     int refs to do iteration, instead of the more natural (and more
2063 :     efficient) tail recursive form.
2064 :    
2065 :     [Lal, 6/29/97]
2066 :     The bug is in the runtime system, in the routine
2067 :     runtime/gc/ml-object.c:ML_AllocRealdarray.
2068 :    
2069 :     If garbage collection is invoked there is no guarantee that the
2070 :     next word in the STRING arena is properly aligned.
2071 :    
2072 :     ------
2073 :     ml_val_t ML_AllocRealdarray (ml_state_t *msp, int len)
2074 :     {
2075 :     int nwords = DOUBLES_TO_WORDS(len);
2076 :     if (nwords > SMALL_OBJ_SZW) {
2077 :     arena_t *ap = msp->ml_heap->gen[0]->arena[STRING_INDX];
2078 :     BEGIN_CRITICAL_SECT(MP_GCGenLock)
2079 :     #ifdef ALIGN_REALDS
2080 :     /* Force REALD_SZB alignment (descriptor is off by one word) */
2081 :     ap->nextw = (ml_val_t *)((Addr_t)(ap->nextw) | WORD_SZB);
2082 :     #endif
2083 :     IFGC (ap, (WORD_SZB*(nwords + 1))+msp->ml_heap->allocSzB) {
2084 :     /* we need to do a GC */
2085 :     ap->reqSizeB += WORD_SZB*(nwords + 1);
2086 :     RELEASE_LOCK(MP_GCGenLock);
2087 :     InvokeGC (msp, 1);
2088 :     ACQUIRE_LOCK(MP_GCGenLock);
2089 :     }
2090 :     *(ap->nextw++) = desc; <<<<<< not aligned.
2091 :     res = PTR_CtoML(ap->nextw);
2092 :     ap->nextw += nwords;
2093 :    
2094 :     ----
2095 :    
2096 :     A crude fix to get you going is to replicate the
2097 :     #ifdef ALIGN_REALDS ... #endif
2098 :    
2099 :     just before the line containing:
2100 :    
2101 :     *(ap->nextw++) = desc; <<<<<< not aligned.
2102 :    
2103 :     p.s. This bug manifested on the HPPA, and this fix solved the
2104 :     problem. I have not tested this on the alpha, so please let me know if
2105 :     it works on the alpha as well. Thanks.
2106 :     Fix:
2107 :     Test:
2108 :     Owner: Lal, jhr
2109 :     Status: fixed in 109.30
2110 :     ----------------------------------------------------------------------
2111 :     Number: 1228
2112 :     Title: various Real functions on Alpha
2113 :     Keywords: Floating point, Real
2114 :     Submitter: Andrew.Kennedy@persimmon.co.uk, George Russell <george@persimmon.co.uk>
2115 :     Date: 7/7/97
2116 :     Version: 109.29
2117 :     System: Alpha, OSF 4.0
2118 :     Severity: Minor
2119 :     Problem:
2120 :     1. Real.ceil and Real.floor cause segmentation fault on reals
2121 :     whose integer equivalent is out of range
2122 :     2. Real.signBit (~0.0);
2123 :     returns false on both Alpha/OSF 4.0 and Linux/i386.
2124 :     3. Real.fromManExp{exp=0,man=1.5};
2125 :     causes SML/NJ 109.29 to hang forever (well, 8 GCs so far and counting)
2126 :     on Alpha/Digital Unix 4 and i686/Linux
2127 :     4. Real.toManExp(1.0);
2128 :     returns
2129 :     {exp=0,man=1.0}
2130 :     for both Alpha/Digital Unix 4.0 and Linux/i686. However by my version
2131 :     of the standard this is wrong because we should have
2132 :     0.5<=man<1.0. The correct answer is {exp=1,man=0.5}. The local
2133 :     version of frexp gets this right, incidentally.
2134 :     5. Real.isNormal 0.0
2135 :     ought to return false.
2136 :    
2137 :     Code: Real.floor 1073741824.0
2138 :     Transcript:
2139 :     Comments:
2140 :     [Kennedy] NB Real.ceil 1073741823.1 correctly raises Overflow
2141 :     [jhr, 7/7/97]
2142 :     > Real.signBit (~0.0);
2143 :     > returns false on both Alpha/OSF 4.0 and Linux/i386.
2144 :    
2145 :     Actually, this is a feature of the IEEE 754-1985 specification.
2146 :     The negation of zero is negative zero, only when the rounding
2147 :     mode is set to TO_NEGINF.
2148 :    
2149 :     I don't know if the SML specification says anything about how
2150 :     the literal ~0.0 should be interpreted (is it the same as
2151 :     Real.~(0.0) in default rounding mode)?
2152 :     [appel, 9/17/97]
2153 :     No, this is not true. The IEEE specification calls for the
2154 :     negation of 0.0 to be ~0.0 regardless of rounding mode.
2155 :    
2156 :     [jhr, 7/7/97]
2157 :     I've tried the various FP bugs on canna, and here is some more info:
2158 :    
2159 :     1) The Real.floor and Real.ceil of 1073741824.0 work correctly. This
2160 :     is probably a bug in the assembly code for floor.
2161 :    
2162 :     2) Real.signBit(~0.0) returns false, but Real.signBit(0.0/ ~1.0) returns
2163 :     true. This is probably not a bug, but a feature of the IEEE specification.
2164 :    
2165 :     3) Real.fromManExp{exp=0,man=1.5} goes to lunch on the MIPS too. I suspect
2166 :     this is a bug in the Real.fromManExp function (written by Andrew, I think).
2167 :    
2168 :     Fix: [for which part?]
2169 :     [Lal, 7/7/97]
2170 :     Thanks for the bug report. In the file
2171 :     src/runtime/mach-dep/ALPHA32-prim.asm
2172 :    
2173 :     there are two labels called floor_overflow that require a trapb
2174 :     instruction at the end. The first floor_overflow label should look
2175 :     like:
2176 :    
2177 :     floor_overflow:
2178 :     ldl ATMP1, ovfl_MAXINT
2179 :     addlv ATMP1, ATMP1, ATMP1
2180 :     trapb
2181 :    
2182 :     and the second should look like:
2183 :    
2184 :     floor_overflow:
2185 :     addq $30, 16, $30
2186 :     ldl ATMP1, ovfl_MAXINT
2187 :     addlv ATMP1, ATMP1, ATMP1
2188 :     trapb
2189 :    
2190 :     The stack deallocation must be added to the second label as well.
2191 :    
2192 :     Making this change and recompiling the runtime system fixes this
2193 :     problem.
2194 :     Test: *
2195 :     Owner: jhr, Lal
2196 :     Status: fixed in 109.31 [Lal, Andrew]
2197 :     ----------------------------------------------------------------------
2198 :     Number: 1229
2199 :     Title: Bugs in unionWith, unionWithi of smlnj-lib
2200 :     Keywords: smlnj-lib, binary-set-map
2201 :     Submitter: Yasuhiko Minamide, nan@kurims.kyoto-u.ac.jp
2202 :     Date: 7/11/1997
2203 :     Version: 109.29
2204 :     System: any
2205 :     Severity: minor
2206 :     Problem:
2207 :    
2208 :     The behaviour of unionWith and unionWithi of smlnj-lib seems wrong.
2209 :    
2210 :     Code:
2211 :    
2212 :     let open IntBinaryMap
2213 :     val x = insert (insert (empty, 1,1), 2, 2)
2214 :     val y = insert (empty, 1, 0)
2215 :     val z = unionWith (fn (x,y) => x) (x, y)
2216 :     in
2217 :     listItemsi z
2218 :     end
2219 :    
2220 :     Transcript:
2221 :    
2222 :     The code above returns
2223 :    
2224 :     val it = [(1,0),(2,2)] : (int * int) list
2225 :    
2226 :     I think that this should be
2227 :    
2228 :     val it = [(1,1),(2,2)] : (int * int) list
2229 :    
2230 :     Test: *
2231 :     Owner: jhr
2232 :     Status: fixed in 109.30 [jhr, 7/14/97]
2233 :     ----------------------------------------------------------------------
2234 :     Number: 1230
2235 :     Title: bus-error due to representation problem
2236 :     Keywords: bus-error
2237 :     Submitter: manuel@cs.berkeley.edu
2238 :     Date: July 12
2239 :     Version: 109.26 and 109.29
2240 :     System: Solaris Ultrasparc and Linux i686
2241 :     Severity: severe
2242 :     Problem: Small test program crashes sml process
2243 :     Code:
2244 :     signature CONS =
2245 :     sig
2246 :     type 'a sign
2247 :     type 'a constructor
2248 :    
2249 :     val new : {name : string,
2250 :     signa : 'a sign} -> 'a constructor
2251 :    
2252 :     end
2253 :    
2254 :     structure Cons : CONS =
2255 :     struct
2256 :    
2257 :     datatype sort =
2258 :     SUB
2259 :     | CSUB
2260 :    
2261 :     datatype datacon = DCON of {name : string,
2262 :     arity : int,
2263 :     sign : sort list,
2264 :     sort : sort,
2265 :     strict : bool}
2266 :    
2267 :     type 'a constructor = datacon
2268 :     type 'a sign = {sign : sort list, sort : sort, strict : bool}
2269 :    
2270 :     fun new {name,signa={sign,sort,strict}} =
2271 :     DCON {name=name,
2272 :     arity=List.length sign,
2273 :     sign=sign,
2274 :     sort=sort,
2275 :     strict=strict
2276 :     }
2277 :    
2278 :     end
2279 :    
2280 :     Transcript:
2281 :     [Solaris,UltraSparc]
2282 :     Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
2283 :     - [opening /tmp/mla002oZ]
2284 :     signature CONS =
2285 :     sig
2286 :     type 'a sign
2287 :     type 'a constructor
2288 :     val new : {name:string, signa:'a sign} -> 'a constructor
2289 :     end
2290 :     structure Cons :
2291 :     CONS?
2292 :     val it = () : unit
2293 :     - Cons.new;
2294 :    
2295 :     Process sml bus error
2296 :    
2297 :     [Linux i686]
2298 :     Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
2299 :     use "/tmp/mla32088";^M
2300 :     - [opening /tmp/mla32088]
2301 :     signature CONS =
2302 :     sig
2303 :     type 'a sign
2304 :     type 'a constructor
2305 :     val new : {name:string, signa:'a sign} -> 'a constructor
2306 :     end
2307 :     structure Cons :
2308 :     CONS?
2309 :     val it = () : unit
2310 :     - Cons.new;
2311 :     /disks/orodruin/aa/home/manuel/Projects/sml-109.26/bin/.run/run.x86-linux:
2312 :     Fatal error --\
2313 :     unexpected fault, signal = 11, code = 0x4081346b
2314 :    
2315 :     Process sml exited abnormally with code 1
2316 :    
2317 :     Comments:
2318 :     I tried to make the example as short as possible. It seems important
2319 :     that the datatype DCON have at least 5 fields in the record, and that
2320 :     new takes 2 arguments.
2321 :    
2322 :     Fix:
2323 :     Test: bug1230.sml
2324 :     Owner: Zhong
2325 :     Status: fixed in 109.30 [Zhong]
2326 :     ----------------------------------------------------------------------
2327 :     Number: 1231
2328 :     Title: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
2329 :     Keywords: secondary error, error recovery
2330 :     Submitter: manuel@cs.berkeley.edu
2331 :     Date: July 12
2332 :     Version: 109.29
2333 :     System: Solaris Ultrasparc
2334 :     Severity: severe
2335 :     Problem: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
2336 :     Code:
2337 :     signature CONS =
2338 :     sig
2339 :     type 'a sign
2340 :     type 'a constructor
2341 :    
2342 :     val new : {name : string,
2343 :     signa : 'a sign} -> 'a constructor
2344 :    
2345 :     end
2346 :    
2347 :     structure Cons : CONS =
2348 :     struct
2349 :    
2350 :     datatype sort =
2351 :     SUB
2352 :     | CSUB
2353 :    
2354 :     datatype datacon = DCON of {name : string,
2355 :     arity : int,
2356 :     sign : sort list,
2357 :     sort : sort,
2358 :     strict : bool}
2359 :    
2360 :     type 'a constructor = datacon
2361 :     datatype 'a sign = Sign of {sign : sort list, sort : sort, strict : bool}
2362 :    
2363 :     fun new {name,signa=Sign{sign,sort,strict}} =
2364 :     DCON {name=name,
2365 :     arity=List.length sign,
2366 :     sign=sign,
2367 :     sort=sort,
2368 :     strict=strict
2369 :     }
2370 :    
2371 :     end
2372 :    
2373 :     signature B =
2374 :     sig
2375 :     structure Cons : Cons
2376 :     end
2377 :    
2378 :     structure B :> B =
2379 :     struct
2380 :     structure Cons = Cons
2381 :     end
2382 :    
2383 :     Transcript:
2384 :     Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled]
2385 :     - [opening /tmp/mla002oZ]
2386 :     /tmp/mla002oZ:39.2-40.5 Error: unbound signature: Cons
2387 :     Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
2388 :    
2389 :     uncaught exception Error
2390 :     raised at: util/errormsg.sml:51.14-51.19
2391 :     modules/sigmatch.sml:807.24
2392 :     elaborate/elabmod.sml:1039.8
2393 :     util/stats.sml:164.40
2394 :     build/evalloop.sml:120.38
2395 :     build/evalloop.sml:192.58
2396 :     build/evalloop.sml:284.46-284.49
2397 :     -
2398 :     Comments:
2399 :     Fix:
2400 :     Test: bug1231.sml
2401 :     Owner: Zhong
2402 :     Status: fixed in 109.30
2403 :     ----------------------------------------------------------------------
2404 :     Number: 1232
2405 :     Title: consistent definitional specs seen as inconsistent
2406 :     Keywords: modules, signatures, definitional specs, where definitions
2407 :     Submitter: Norman Ramsey <nr@cs.virginia.edu>
2408 :     Date: 6/19/97
2409 :     Version: 109.29
2410 :     System: -
2411 :     Severity: major
2412 :     Problem:
2413 :     Definitional specs are rejected as inconsistent when they are not.
2414 :     Code:
2415 :     signature SIG1 =
2416 :     sig
2417 :     type t = int
2418 :     end
2419 :    
2420 :     signature SIG2 =
2421 :     sig
2422 :     structure N : SIG1
2423 :     end
2424 :    
2425 :     functor Bad(structure X : SIG1
2426 :     structure Y : SIG2 where N = X) =
2427 :     struct end;
2428 :    
2429 :     Transcript:
2430 :     - use "foo.sml";
2431 :     [opening foo.sml]
2432 :     foo.sml:11.9-13.11 Error: Inconsistent defining constraints : type t = t
2433 :    
2434 :     uncaught exception Error
2435 :     raised at: build/evalloop.sml:103.44-103.52
2436 :     build/evalloop.sml:120.38
2437 :     build/evalloop.sml:193.58
2438 :     build/evalloop.sml:285.46-285.49
2439 :    
2440 :     Comments:
2441 :     Confusing error message too.
2442 :     Fix:
2443 :     Remove consistency checking for multiple definitions in
2444 :     Instantiate.builtTycClass.constrain when one or both definitions
2445 :     are not instantiated (NOTINST tyc).
2446 :     Test: bug1232.sml
2447 :     Owner: dbm
2448 :     Status: fixed in 109.30 [dbm, 7/16/97]
2449 :     ----------------------------------------------------------------------
2450 :     Number: 1233
2451 :     Title: funny printing of multiple bindings in a declaration
2452 :     Keywords: printing, duplicate binding
2453 :     Submitter: Walid Taha
2454 :     Date: 7/16/97
2455 :     Version: 109.29
2456 :     System: -
2457 :     Severity: minor
2458 :     Problem:
2459 :     The top level prints an odd message when a value variable is bound twice
2460 :     in a declaration.
2461 :     Transcript:
2462 :     - val c = 1 val c = 2;
2463 :     val c = <hidden-value> : int
2464 :     val c = 2 : int
2465 :     Comments:
2466 :     It would be preferable to just print
2467 :    
2468 :     val c = 2 : int
2469 :    
2470 :     as the result of the declaration.
2471 :     Fix:
2472 :     Test: bug1233.sml
2473 :     Owner: Zhong?
2474 :     Status: open
2475 :     ----------------------------------------------------------------------
2476 :     Number: 1234
2477 :     Title: EntityEnv.Unbound raised in functor application
2478 :     Keywords: modules, translation, hidden types
2479 :     Submitter: Dave MacQueen
2480 :     Date: 7/21/97
2481 :     Version: 109.30 (+ bug 1206 fix)
2482 :     System: -
2483 :     Severity: major
2484 :     Problem:
2485 :     EntityEnv.Unbound exception raised in function specLty when compiling
2486 :     legal functor application.
2487 :     Code:
2488 :     functor F(type t val x : t) =
2489 :     struct
2490 :     structure U : sig type u val y : u end =
2491 :     struct
2492 :     datatype u = K of t
2493 :     type u = u list
2494 :     val y = [K x]
2495 :     end
2496 :     val z = hd U.y
2497 :     end;
2498 :    
2499 :     structure A = T(type t = int val x = 3);
2500 :     Transcript:
2501 :     - use "bug1234.sml";
2502 :     [opening bug1234.sml]
2503 :     functor F : <sig>
2504 :    
2505 :     uncaught exception Unbound
2506 :     raised at: translate/transmodules.sml:79.33-79.43
2507 :     util/stats.sml:164.40
2508 :     build/evalloop.sml:193.58
2509 :     build/evalloop.sml:285.46-285.49
2510 :     Comments:
2511 :     [dbm]
2512 :     This is after incorporating the fix for bug 1206.
2513 :     If the signature on U is removed, the code works.
2514 :    
2515 :     Looking at the functor representation and the bad entityEnv with
2516 :     debugging on, it looks like signature matching is introducing an extra
2517 :     level of structure nesting. The path to the hidden datatype u should
2518 :     be of length 2, but in the entityEnv, the datatype is nested inside an
2519 :     extra intermediate structure, so the length two path doesn't reach it.
2520 :     I presume that sigmatch is creating the extra intermediate structure
2521 :     level.
2522 :    
2523 :     Fix:
2524 :     Test: bug1234.sml
2525 :     Owner: dbm, Zhong
2526 :     Status: Fixed in 109.31 [Zhong]
2527 :     ----------------------------------------------------------------------
2528 :     Number: 1235
2529 :     Title: Argument type constraint changes behavior of a function
2530 :     Keywords: types
2531 :     Submitter: Sam Kamin, s-kamin@uiuc.edu
2532 :     Date: 7/21/97
2533 :     Version: Version 109.29, June 13, 1997 [CM&CMB]
2534 :     System: sparc-solaris, don't know what version offhand
2535 :     Severity: major
2536 :     Problem: Function defined as fun f x = ... type-checks, but then
2537 :     crashes. When defined as fun f (x:T) = ..., it works
2538 :     fine.
2539 :     Code: I'm not going to send enough to reproduce the error,
2540 :     because it's too much. If this turns out to be an
2541 :     interesting problem, I can send it. Anyway, the specific
2542 :     problem is demonstrated in this function:
2543 :    
2544 :     fun mkseqlist seqop [] = empty
2545 :     | mkseqlist seqop [p:Picture] = p
2546 :     | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
2547 :    
2548 :     If the ":Picture" in the second clause is omitted, the
2549 :     function type-checks but crashes when used.
2550 :    
2551 :     Transcript: In this transcript, "seq" is an infix operator. As I said,
2552 :     I haven't come up with a simpler example, and I don't
2553 :     think you want all the code (especially not if this turns
2554 :     out to be something simple).
2555 :    
2556 :     - fun mkseqlist seqop [] = empty
2557 :     | mkseqlist seqop [p] = p
2558 :     | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
2559 :     = = val mkseqlist = fn
2560 :     : ((('a -> string) * Environment) * (('a -> string) * Environment)
2561 :     -> ('a -> string) * Environment)
2562 :     -> (('a -> string) * Environment) list -> ('a -> string) *
2563 :     Environment
2564 :     - val seqlist = mkseqlist (op seq);
2565 :     val seqlist = fn
2566 :     : ((GraphicsContext -> string) * Environment) list
2567 :     -> (GraphicsContext -> string) * Environment
2568 :     - draw (seqlist [text "a"]) "test";
2569 :     ~2.34725596609e228, ~2.34705354077e228
2570 :     uncaught exception Overflow [overflow]
2571 :     - fun mkseqlist seqop [] = empty
2572 :     | mkseqlist seqop [p:Picture] = p
2573 :     | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
2574 :     = = val mkseqlist = fn
2575 :     : (Picture * ((GraphicsContext -> string) * Environment)
2576 :     -> (GraphicsContext -> string) * Environment)
2577 :     -> Picture list -> (GraphicsContext -> string) * Environment
2578 :     - val seqlist = mkseqlist (op seq);
2579 :     val seqlist = fn : Picture list -> (GraphicsContext -> string) *
2580 :     Environment
2581 :     - draw (seqlist [text "a"]) "test";
2582 :     1.0, 0.0(1.0, 1.0)(0.0, 0.0)val it = () : unit
2583 :     -
2584 :    
2585 :     Comments: I'm not sure if this is really a bug, but it seems to me
2586 :     that adding type declarations is not supposed to matter.
2587 :     And it's a heck of a difficult error to track down.
2588 :     Fix:
2589 :     Test: ?
2590 :     Owner: Zhong
2591 :     Status: fixed in 109.30
2592 :     ----------------------------------------------------------------------
2593 :     Number: 1236
2594 :     Title: TextIO.outputSubstr doesn't work on substrings containing \n
2595 :     Keywords: IO, TextIO, outputSubstr
2596 :     Submitter: Konrad.Slind@cl.cam.ac.uk
2597 :     Date: 7/23/97
2598 :     Version: 109.30
2599 :     System: sparc/solaris 2.5.5
2600 :     Severity: major
2601 :     Problem:
2602 :     TextIO.outputSubstr doesn't seem to handle substrings with "\n" in
2603 :     them. For example:
2604 :    
2605 :     - TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n"));
2606 :     val it = () : unit
2607 :    
2608 :     This behaviour contradicts the description in the basis documentation.
2609 :    
2610 :     Code:
2611 :     TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n"));
2612 :     Comments:
2613 :     Fix:
2614 :     Test: bug1236.sml
2615 :     Owner: jhr, erg
2616 :     Status: fixed in 109.32 [jhr, 7/24/97]
2617 :     ----------------------------------------------------------------------
2618 :     Number: 1237
2619 :     Title: ml-yacc doesn't handle constructors with long names
2620 :     Keywords: ml-yacc, constructor names
2621 :     Submitter: Konrad.Slind@cl.cam.ac.uk
2622 :     Date: 7/23/97
2623 :     Version: 109.30
2624 :     System: -
2625 :     Severity: major
2626 :     Problem:
2627 :     ml-yacc emits bogus string literals from constructors with long
2628 :     names. The following input will generate a file where, on about line
2629 :     104, a mangled string literal is produced.
2630 :     Code:
2631 :     %%
2632 :     %term I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild
2633 :     | EOLEX
2634 :     | EOF
2635 :    
2636 :     %nonterm START of unit
2637 :    
2638 :     %start START
2639 :     %eop EOF EOLEX
2640 :     %pos int
2641 :     %header (functor ELrValsFun (structure Token : TOKEN))
2642 :     %name E
2643 :     %noshift EOF
2644 :     %pure
2645 :     %%
2646 :    
2647 :     START : I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild()
2648 :     Transcript:
2649 :     Comments:
2650 :     Fix:
2651 :     Test:
2652 :     Owner: appel
2653 :     Status: fixed in 109.32
2654 :     ----------------------------------------------------------------------
2655 :     Number: 1238
2656 :     Title: Elaboration error involving where structure
2657 :     Keywords: where structure
2658 :     Submitter: Perry Cheng (pscheng@cs.cmu.edu)
2659 :     Date: 7/23/97
2660 :     Version: 109.30
2661 :     System: Digital Unix 4.0
2662 :     Severity: major
2663 :     Problem: Where structure construct causes strange error message.
2664 :     Code:
2665 :     signature MA =
2666 :     sig
2667 :     type t
2668 :     end;
2669 :    
2670 :     signature MU =
2671 :     sig
2672 :     structure M : MA
2673 :     end;
2674 :    
2675 :     signature DA =
2676 :     sig
2677 :     type t
2678 :     end;
2679 :    
2680 :     (* ------------ this one works ---------------------- *)
2681 :     functor Good(structure D : DA
2682 :     structure Mu : MU
2683 :     where type M.t = D.t)
2684 :     = struct end;
2685 :    
2686 :     (* ------------ this one fails ---------------------- *)
2687 :     functor Bad(structure D : DA
2688 :     structure Mu : MU where M = D)
2689 :     = struct end;
2690 :    
2691 :     Transcript:
2692 :     - use "bug1238.sml";
2693 :     [opening bug1238.sml]
2694 :     signature MA =
2695 :     sig type t end
2696 :     signature MU =
2697 :     sig structure M : sig type t end end
2698 :     signature DA =
2699 :     sig type t end
2700 :     functor Good : <sig>
2701 :    
2702 :     uncaught exception Unbound
2703 :     raised at: elaborate/elabmod.sml:1164.39-1164.49
2704 :     util/stats.sml:164.40
2705 :     build/evalloop.sml:120.38
2706 :     build/evalloop.sml:193.58
2707 :     build/evalloop.sml:285.46-285.49
2708 :    
2709 :     Comments:
2710 :     Minor modification to the code will make the bug go away.
2711 :     This bug is related to bug 1232.
2712 :     On a related note, sometime a functor definition that involves
2713 :     "where structure" generates a functor which, when instantiated,
2714 :     gives the same error message even though the code is correct.
2715 :    
2716 :     [dbm, 7/23/97]
2717 :     If DA is replaced by MA in Bad, the code compiles ok. So the problem
2718 :     is caused by the difference in signatures (DA vs MA).
2719 :     Fix:
2720 :     Modified entityInfo datatype in Instantiate so that GENERATE_ENT
2721 :     carries a boolean value indicating whether there was a VARstrDef
2722 :     with signature that does not agree with the spec.
2723 :     Test: bug1238.sml
2724 :     Owner: dbm
2725 :     Status: fixed in 109.31 [dbm, 8/13/97]
2726 :     ----------------------------------------------------------------------
2727 :     Number: 1239
2728 :     Title: Subscript-out-of-bounds error when opening a structure
2729 :     Keywords: pretty printing, compiler
2730 :     Submitter: Jon Riecke, riecke@bell-labs.com
2731 :     Date: 07/25/97
2732 :     Version: 109.30
2733 :     System: Linux and Irix
2734 :     Severity: major
2735 :     Problem:
2736 :     When opening the CML structure, a "subscript out of bounds" exn is raised.
2737 :     Code: CML standard library
2738 :     Transcript:
2739 :     - open CML;
2740 :     GC #0.0.0.1.3.57: (43 ms)
2741 :     open CML
2742 :     val version = {date="June 11, 1997",system="Concurrent ML",version_id=[1,0,7]}
2743 :     : {date:string, system:string, version_id:int list}
2744 :     val banner = "Concurrent ML, Version 1.0.7, June 11, 1997" : string
2745 :     val getTid = fn : unit -> thread_id
2746 :     val sameTid = fn : thread_id * thread_id -> bool
2747 :     val compareTid = fn : thread_id * thread_id -> order
2748 :     val hashTid = fn : thread_id -> word
2749 :     val tidToString = fn : thread_id -> string
2750 :     val spawnc = fn : ('a -> unit) -> 'a -> thread_id
2751 :     val spawn = fn : (unit -> unit) -> thread_id
2752 :     val exit = fn : unit -> 'a
2753 :     val joinEvt = fn : thread_id -> unit event
2754 :     val yield = fn : unit -> unit
2755 :     val channel = fn : unit -> 'a chan
2756 :     val sameChannel = fn : 'a chan * 'a chan -> bool
2757 :     val send = fn : 'a chan * 'a -> unit
2758 :     val recv = fn : 'a chan -> 'a
2759 :     val sendEvt = fn : 'a chan * 'a -> unit event
2760 :     val recvEvt = fn : 'a chan -> 'a event
2761 :     val sendPoll = fn : 'a chan * 'a -> bool
2762 :     val recvPoll = fn : 'a chan -> 'a option
2763 :    
2764 :     uncaught exception in compiler: subscript out of bounds
2765 :     raised at: print/ppobj.sml:89.24-89.29
2766 :     print/ppobj.sml:349.20
2767 :     print/ppobj.sml:349.20
2768 :     print/ppobj.sml:349.20
2769 :     util/pp.sml:545.6
2770 :     build/evalloop.sml:193.58
2771 :    
2772 :     Comments:
2773 :     [jhr, 7/30/97]
2774 :     Appears to be the same as bug 1241, which is fixed in 109.31.
2775 :     Fix:
2776 :     Test: *
2777 :     Owner: Zhong
2778 :     Status: fixed in 109.31 [Zhong, 7/29/97]
2779 :     ----------------------------------------------------------------------
2780 :     Number: 1240
2781 :     Title: Can't form pairs of reals
2782 :     Keywords: reals
2783 :     Submitter: Sam Kamin, kamin@cs.uiuc.edu
2784 :     Date: 7/25/97
2785 :     Version: 109.30
2786 :     System: sparc-solaris
2787 :     Severity: Critical
2788 :     Problem: Attempt to create tuples containing only real numbers
2789 :     results in "uncaught exception in compiler: Representation"
2790 :     Code: (0.0,0.0)
2791 :     Transcript: Here are a couple of more examples:
2792 :    
2793 :     - (0.0, 0.0);
2794 :    
2795 :     uncaught exception in compiler: Representation
2796 :     raised at: boot/Unsafe/object.sml:58.19-58.33
2797 :     print/ppobj.sml:349.20
2798 :     print/ppobj.sml:349.20
2799 :     util/pp.sml:545.6
2800 :     build/evalloop.sml:193.58
2801 :     - (real 0, real 0);
2802 :    
2803 :     uncaught exception in compiler: Representation
2804 :     raised at: boot/Unsafe/object.sml:58.19-58.33
2805 :     print/ppobj.sml:349.20
2806 :     print/ppobj.sml:349.20
2807 :     util/pp.sml:545.6
2808 :     build/evalloop.sml:193.58
2809 :     - ((fn x => (x,x)) 0.0);
2810 :    
2811 :     uncaught exception in compiler: Representation
2812 :     raised at: boot/Unsafe/object.sml:58.19-58.33
2813 :     print/ppobj.sml:349.20
2814 :     print/ppobj.sml:349.20
2815 :     util/pp.sml:545.6
2816 :     build/evalloop.sml:193.58
2817 :    
2818 :     - (0.0, 0);
2819 :     val it = (0.0,0) : real * int
2820 :     - (0.0, "abc");
2821 :     val it = (0.0,"abc") : real * string
2822 :    
2823 :    
2824 :     Comments:
2825 :     Fix:
2826 :     Test: bug1240.sml
2827 :     Owner: jhr, Zhong
2828 :     Status: fixed in 109.31 [jhr, 7/28/97]
2829 :     ----------------------------------------------------------------------
2830 :     Number: 1241
2831 :     Title: confused datatype constructors
2832 :     Keywords: datatype
2833 :     Submitter: Elsa L. Gunter, elsa@research.bell-labs.com
2834 :     Date: July 25, 1997
2835 :     Version: 109.30
2836 :     System: x86 - linux 2.0
2837 :     Severity: critical
2838 :     Problem: In a datatype with two constructors, the constructors get
2839 :     swapped
2840 :     Code:
2841 :    
2842 :     datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1;
2843 :    
2844 :     datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0;
2845 :    
2846 :     norfolk% sml
2847 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
2848 :     - datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1;
2849 :     datatype 'a t1 = A1 | B1 of 'a list
2850 :     val i1 = B1 [] : 'a t1
2851 :     - datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0;
2852 :     datatype 'a t2 = A2 of int | B2 of 'a list
2853 :    
2854 :     uncaught exception in compiler: subscript out of bounds
2855 :     raised at: print/ppobj.sml:89.24-89.29
2856 :     print/ppobj.sml:349.20
2857 :     print/ppobj.sml:349.20
2858 :     util/pp.sml:545.6
2859 :     build/evalloop.sml:193.58
2860 :     -
2861 :     Comments: Notice that in the first datatype declaration, I assign, i1
2862 :     to be A1, but it gives me back that it is B1 []. In the second case,
2863 :     it raises an exception (I think because it is trying to apply B2 [] to
2864 :     0.).
2865 :    
2866 :     Fix: change to ppobj.sml
2867 :     Test: bug1241.sml
2868 :     Owner: Zhong
2869 :     Status: fixed in 109.31 [Zhong]
2870 :     ----------------------------------------------------------------------
2871 :     Number: 1242
2872 :     Title: error recovery in open could be better
2873 :     Keywords: open error recovery
2874 :     Submitter: manuel@cs.berkeley.edu
2875 :     Date: July 29/97
2876 :     Version: 109.29
2877 :     System: all
2878 :     Severity: low
2879 :     Problem: If one structure is undefined in an open declarations with
2880 :     multiple structures, the non-constant constructors made visible from
2881 :     opening preceding structures are not bound. Results in weird spurious
2882 :     error messages.
2883 :    
2884 :     Code:
2885 :     structure A =
2886 :     struct
2887 :     datatype at = A | B | C of int
2888 :     end
2889 :    
2890 :     local
2891 :     open A Foo
2892 :     in
2893 :     fun toString A = "A"
2894 :     | toString B = "B"
2895 :     | toString (C i) = "C " ^ Int.toString i
2896 :     end
2897 :    
2898 :     Transcript:
2899 :     - [opening /tmp/mla003Cy]
2900 :     /tmp/mla003Cy:7.5-7.15 Error: unbound structure: Foo
2901 :     /tmp/mla003Cy:9.9-11.47 Error: non-constructor applied to argument in pattern: C
2902 :    
2903 :     uncaught exception Error
2904 :     raised at: build/evalloop.sml:103.44-103.52
2905 :     build/evalloop.sml:120.38
2906 :     build/evalloop.sml:192.58
2907 :     build/evalloop.sml:284.46-284.49
2908 :     -
2909 :    
2910 :     Comments:
2911 :     The C constructor isn't visible, even though A and B
2912 :     are. Removing the Foo structure from the open declaration
2913 :     makes the second error disappear.
2914 :     [dbm, 7/29/97]
2915 :     The reason there is no error message complaining about A and B
2916 :     in the first two clauses of toString is that since these are not
2917 :     bound as constructors they are interpreted as variables.
2918 :    
2919 :     It should be possible to have the open take effect on the structures
2920 :     that are defined, which would cut down on secondary errors like
2921 :     this one.
2922 :     [manuel, 7/29/97]
2923 :     Yes, you are right about the constant constructors. I didn't think of
2924 :     that. But what is strange is that only constructors seem to be missing
2925 :     from the environment. Value bindings are visible in the same context.
2926 :     Fix:
2927 :     Test: bug1242.sml
2928 :     Owner: dbm
2929 :     Status: open
2930 :     ----------------------------------------------------------------------
2931 :     Number: 1243
2932 :     Title: Application of functor to different representations
2933 :     Keywords: functor application, polymorphism, representation analysis
2934 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
2935 :     Date: 7/28/97
2936 :     Version: 109.30
2937 :     System: x86-linux
2938 :     Severity: major
2939 :     Problem: compiler bug tickled by application of functor
2940 :     to two different polymorphic representations
2941 :     Code:
2942 :    
2943 :     local
2944 :     functor Foo(type 'a t
2945 :     val destruct : 'a t -> ('a * 'a t) option) =
2946 :     struct
2947 :     fun first s =
2948 :     case destruct s of
2949 :     SOME(x,_) => x
2950 :     end
2951 :    
2952 :     structure Foo1 =
2953 :     Foo(type 'a t = 'a list
2954 :     fun destruct _ = let exception E in raise E end)
2955 :    
2956 :     structure Foo2 =
2957 :     Foo(datatype 'a t = T of ('a * 'a t) option
2958 :     fun destruct _ = let exception E in raise E end)
2959 :    
2960 :     in
2961 :     val _ = 13
2962 :     end
2963 :    
2964 :     Transcript:
2965 :    
2966 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
2967 :    
2968 :     stdIn:36.6-37.23 Warning: match nonexhaustive
2969 :     SOME (x,_) => ...
2970 :    
2971 :     for the type:
2972 :     I
2973 :     Error: Compiler bug: LambdaType: unexpected case in tcd_arw
2974 :     -
2975 :    
2976 :     Comments:
2977 :     Fix: change to translate/specialize.sml
2978 :     Test: bug1243.sml
2979 :     Owner: Zhong
2980 :     Status: fixed in 109.31 [Zhong, 7/29/97]
2981 :     ----------------------------------------------------------------------
2982 :     Number: 1244
2983 :     Title: Explicitly scoped type variable with 'val ... and' declaration
2984 :     Keywords: translate, lambda types
2985 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
2986 :     Date: 8/1/97
2987 :     Version: 109.30, 109.30+
2988 :     System: x86-linux
2989 :     Severity: minor
2990 :     Problem: Compiler bug caused by use of an explicitly scoped type
2991 :     variable in multiple val declarations.
2992 :     Code:
2993 :    
2994 :     val 'a f = fn x : 'a => x
2995 :     and g = fn y : 'a => y
2996 :    
2997 :     Transcript:
2998 :    
2999 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3000 :     - val 'a f = fn x : 'a => x
3001 :     and g = fn y : 'a => y
3002 :     = = ;
3003 :     Error: Compiler bug: Translate: unexpected tyvar INSTANTIATED in mkPE
3004 :     -
3005 :    
3006 :     Comments:
3007 :     Fix:
3008 :     Test: bug1244.sml
3009 :     Owner: Zhong, dbm
3010 :     Status: fixed in 109.31
3011 :     ----------------------------------------------------------------------
3012 :     Number: 1245
3013 :     Title: Pretty printer bug
3014 :     Keywords:
3015 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3016 :     Date: 8/4/97
3017 :     Version: 109.30
3018 :     System: x86-linux
3019 :     Severity: minor
3020 :     Problem: Error raised when attempting to print the binding of a
3021 :     pair of empty lists in the REPL.
3022 :    
3023 :     Code: val (x,y) = ([],[])
3024 :    
3025 :     Transcript:
3026 :    
3027 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3028 :     val it = () : unit
3029 :     - val (x,y) = ([],[]);
3030 :    
3031 :     uncaught exception in compiler: subscript out of bounds
3032 :     raised at: print/ppobj.sml:422.28-422.33
3033 :     print/ppobj.sml:349.20
3034 :     print/ppobj.sml:349.20
3035 :     util/pp.sml:545.6
3036 :     build/evalloop.sml:193.58
3037 :     -
3038 :     Comments:
3039 :     Fix:
3040 :     Test: bug1245.sml
3041 :     Owner: Zhong
3042 :     Status: fixed in 109.31
3043 :     ----------------------------------------------------------------------
3044 :     Number: 1246
3045 :     Title: Explicit scoping of type variables does not obey the standard.
3046 :     Keywords: explicity scoped type variable
3047 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3048 :     Date: 8/4/97
3049 :     Version: 109.30
3050 :     System: x86-linux
3051 :     Severity: minor
3052 :     Problem:
3053 :    
3054 :     The following definition does not typecheck.
3055 :    
3056 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3057 :     fn z => z:'a)
3058 :    
3059 :     The following definition does typecheck.
3060 :    
3061 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3062 :     fn z => z:'b)
3063 :    
3064 :     I believe that, according to the standard, they both should typecheck.
3065 :     It appears that the first example is failing because the typechecker
3066 :     is changing the scope of the explicitly scoped 'a, whereas the
3067 :     standard only specifies how to determine the scope of implicitly
3068 :     scoped type variables -- the scope of explicitly scoped type variables
3069 :     should not change. As the second example demonstrates, the problem
3070 :     appears to occur because a bound type variable happens to have the
3071 :     same name as a free type variable.
3072 :    
3073 :     Code:
3074 :    
3075 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3076 :     fn z => z:'a)
3077 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3078 :     fn z => z:'b)
3079 :    
3080 :     Transcript:
3081 :    
3082 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3083 :     val it = () : unit
3084 :     - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3085 :     fn z => z:'a);
3086 :     = stdIn:13.12-13.60 Error: operator and operand don't agree [UBOUND match]
3087 :     operator domain: 'a
3088 :     operand: 'a -> 'a
3089 :     in expression:
3090 :     id id
3091 :     - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3092 :     fn z => z:'b);
3093 :     = val f = fn : unit -> ('a -> 'a) * ('b -> 'b)
3094 :     -
3095 :    
3096 :     Another example from Andrew Tolmach [8/18/97]
3097 :    
3098 :     - val 'a f = fn (x:'a) => let val 'a g = fn (y:'a) => (y,y) in g (x,x) end;
3099 :     stdIn:15.25-15.73 Error: operator and operand don't agree [UBOUND match]
3100 :     operator domain: 'a
3101 :     operand: 'a * 'a
3102 :     in expression:
3103 :     g (x,x)
3104 :    
3105 :     Comments:
3106 :     [Andrew Kennedy, 3/20/98]
3107 :     I have a small query concerning explicit type variables: the final
3108 :     syntactic restriction listed in Section 2.9 (page 9) of the Definition
3109 :     seems unnecessary and isn't enforced by SML/NJ. Was it a mistake? In
3110 :     particular, the Tolmach example cited on your bug list
3111 :    
3112 :     val 'a f = fn (x:'a) =>
3113 :     let val 'a g = fn (y:'a) => (y,y) in g (x,x)
3114 :     end
3115 :    
3116 :     would appear (to me) not to obey this restriction, and yet is perfectly
3117 :     sensible if val 'a is essentially `big lambda'. Surely a desirable
3118 :     property of the SML is that a declaration such as
3119 :    
3120 :     val 'a id = fn x : 'a => x
3121 :    
3122 :     can be plugged into an arbitrary program context without breaking any
3123 :     restrictions.
3124 :    
3125 :    
3126 :     Fix: in elabcore.sml, revised calculations of updt in the presence of
3127 :     etvs (explicitly bound type variables) to avoid inappropriate instantiations
3128 :     of explicit variables.
3129 :     Test: bug1246.sml, bug1246.1.sml
3130 :     Owner: dbm
3131 :     Status: fixed in 109.31 [dbm, 9/4/97]
3132 :     ----------------------------------------------------------------------
3133 :     Number: 1247
3134 :     Title: IntSet library module is wrong
3135 :     Keywords: smlnj-lib, IntSet, ListSet
3136 :     Submitter: Andrew Kennedy <andrew@persimmon.co.uk>
3137 :     Date: 8/4/97
3138 :     Version: 109.30
3139 :     System: -
3140 :     Severity: major
3141 :     Problem:
3142 :     A while back I reported some bugs in the ListSet functor. They were
3143 :     fixed but unfortunately the fix doesn't appear to have been applied to
3144 :     the IntSet specialised version. (Just compare the source files: they're
3145 :     are some missing primes on variable names in some functions).
3146 :     Comments:
3147 :     Fix:
3148 :     Test: ?
3149 :     Owner: jhr, Emden
3150 :     Status: Fixed in 109.31
3151 :     ----------------------------------------------------------------------
3152 :     Number: 1248
3153 :     Title: blastWrite failures
3154 :     Keywords: blastRead, blastWrite
3155 :     Submitter: Chris Paris <cap@cmu.edu>
3156 :     Date: 8/5/97
3157 :     Version: 109.30
3158 :     System: ?
3159 :     Severity: major
3160 :     Problem: blastwrite fails catastrophically
3161 :     Code:
3162 :     Transcript:
3163 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3164 :     val it = () : unit
3165 :     - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);val blastWrite = fn : 'a -> Word8Vector.vector
3166 :     - blastWrite (Word8Array.array (516000, 0w0));
3167 :     GC #0.0.0.0.1.4: (0 ms)
3168 :     GC #0.0.0.0.2.6: (10 ms)
3169 :     val it = - : Word8Vector.vector
3170 :     - blastWrite (Word8Array.array (516001, 0w0));
3171 :     GC #0.0.0.1.3.7: (0 ms)
3172 :     GC #0.0.0.1.4.8: (0 ms)
3173 :     ./sml: Fatal error -- blasting out of 516096 bytes not supported yet! Increase allocation arena size.
3174 :    
3175 :     But perhaps blasting one large atomic object presents a problem that
3176 :     blasting a collection of small objects wouldn't, so here's another
3177 :     example.
3178 :    
3179 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3180 :     val it = () : unit
3181 :     - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);
3182 :     val blastWrite = fn : 'a -> Word8Vector.vector
3183 :     - fun iter 0 = []
3184 :     = | iter n = n :: (iter (n-1));
3185 :     val iter = fn : int -> int list
3186 :     - blastWrite (iter 10);
3187 :     val it = - : Word8Vector.vector
3188 :     - blastWrite (iter 100);
3189 :     val it = - : Word8Vector.vector
3190 :     - blastWrite (iter 1000);
3191 :     val it = - : Word8Vector.vector
3192 :     - blastWrite (iter 10000);
3193 :     GC #0.0.0.0.1.13: (20 ms)
3194 :     val it = - : Word8Vector.vector
3195 :     - blastWrite (iter 100000);
3196 :     GC #0.0.0.1.2.16: (110 ms)
3197 :     GC #0.0.0.2.3.17: (140 ms)
3198 :     Segmentation fault
3199 :    
3200 :     Comments:
3201 :     [Chris Paris, 8/5/97]
3202 :     In last night's message, I meant to make another comment about
3203 :     blastWrite but forgot. I find it limiting that the size of the object
3204 :     blastWrite can handle is limited by the allocation arena size. I'm
3205 :     already running with a doubled allocation arena size to accomodate our
3206 :     growing data, but I understand that I can't just keep increasing it
3207 :     indefinitely and expect to retain reasonable performance. The end of
3208 :     blast-out.c mentions allocating space in the big-object arena as an
3209 :     alternative implementation. I'm wondering if this would be an easy
3210 :     change to make that hasn't been done simply due to lack of demand, or
3211 :     whether there are difficult issues to overcome in order to remove the
3212 :     current limitation.
3213 :     Fix:
3214 :     Test: bug1248.1.sml, bug1248.2.sml
3215 :     Owner: jhr
3216 :     Status: fixed in 109.31 [jhr, 8/12/97]
3217 :     ----------------------------------------------------------------------
3218 :     Number: 1249
3219 :     Title: Time.time type too small
3220 :     Keywords: Time.time
3221 :     Submitter: Chris Paris <cap@cmu.edu>
3222 :     Date: 8/5/97
3223 :     Version: 109.30
3224 :     System: -
3225 :     Severity: minor
3226 :     Problem:
3227 :     The project I'm working on uses the Time.time type for some
3228 :     things. Today we ran into some data that required 32 bits in the sec
3229 :     field. We had to write our own time type to handle this. I'm not
3230 :     saying the system Time type should definitely be changed, but I
3231 :     thought you'd like to know that someone needed more than 31 bits
3232 :     there.
3233 :     Comments:
3234 :     The SML Basis now specifies a LargeInt.int representation for
3235 :     the seconds field. -- jhr
3236 :     Fix:
3237 :     Test:
3238 :     Owner: jhr?
3239 :     Status: Fixed in 109.31 [jhr, 7/31/97]
3240 :     ----------------------------------------------------------------------
3241 :     Number: 1250
3242 :     Title: Bind exception delayed by polymorphic generalization
3243 :     Keywords: Bind exception
3244 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3245 :     Date: 8/5/97
3246 :     Version: 109.30
3247 :     System: x86-linux
3248 :     Severity: minor
3249 :     Problem: A Bind exception is not raised in a value declaration
3250 :     when the variable being defined is polymorphically
3251 :     generalized. I suspect that the raise is getting wrapped
3252 :     in a _/\_ in the translation into the typed IL.
3253 :     The exception is raised later if the polymorphic value
3254 :     is applied.
3255 :    
3256 :     Code: datatype 'a foo = Foo1 of 'a | Foo2 of 'a
3257 :     val Foo1 f = Foo2(fn x => x);
3258 :     f 13;
3259 :     Transcript:
3260 :    
3261 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3262 :     - datatype 'a foo = Foo1 of 'a | Foo2 of 'a
3263 :     val Foo1 f = Foo2(fn x => x);
3264 :     = stdIn:<nullRegion> Warning: binding not exhaustive
3265 :     Foo1 f = ...
3266 :     datatype 'a foo = Foo1 of 'a | Foo2 of 'a
3267 :     val f = fn : 'a -> 'a
3268 :     - f 13;
3269 :    
3270 :     uncaught exception Bind [nonexhaustive binding failure]
3271 :     raised at: stdIn:<nullRegion>
3272 :    
3273 :     Comments:
3274 :     [Zhong, 8/5/97]
3275 :     Thanks for the bug report. This bug is actually related to the
3276 :     pretty-printing. As you observed, binding f to _/\_ does not
3277 :     raise the exception; the exception should be raised when
3278 :     printing f in the top-level (however, the pretty-printing in
3279 :     109.30 was broken, so the exception is not raised).
3280 :    
3281 :     Our fixes for the other pretty-printing bugs (which have been
3282 :     incorporated into 109.31) should correctly raise the exception,
3283 :     however, the exception name is not printed out correctly still.
3284 :     Fix:
3285 :     Test: bug1250.sml
3286 :     Owner: Zhong
3287 :     Status: Fixed in 109.31 [Zhong]
3288 :     ----------------------------------------------------------------------
3289 :     Number: 1251
3290 :     Title: where specs cause exception Unbound
3291 :     Keywords: where Unbound
3292 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3293 :     Date: 8/6/97
3294 :     Version: 109.30
3295 :     System: x86-linux
3296 :     Severity: minor
3297 :     Problem: The use of a where spec can cause exception Unbound to be
3298 :     raised by the elaborator.
3299 :     Code:
3300 :    
3301 :     structure S : sig
3302 :     structure A : sig end
3303 :     structure B : sig structure C : sig end end where C = A
3304 :     end =
3305 :     struct
3306 :     structure A = struct end
3307 :     structure B = struct structure C = A end
3308 :     end
3309 :    
3310 :     Transcript:
3311 :    
3312 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3313 :     - structure S : sig
3314 :     structure A : sig end
3315 :     structure B : sig structure C : sig end end where C = A
3316 :     end =
3317 :     struct
3318 :     structure A = struct end
3319 :     structure B = struct structure C = A end
3320 :     end;
3321 :    
3322 :    
3323 :     uncaught exception in compiler: Unbound
3324 :     raised at: elaborate/elabmod.sml:1050.15-1050.25
3325 :     util/stats.sml:164.40
3326 :     build/evalloop.sml:120.38
3327 :     build/evalloop.sml:193.58
3328 :    
3329 :     Comments:
3330 :     [Zhong, 8/6/97]
3331 :     Thanks for the bug report. I encountered this same bug while
3332 :     trying to fix bug 1205. It happens only if the righthand side
3333 :     of the where clause is a "flexible" structure (i.e., locally
3334 :     defined structure). Dave and I will try to get a fix into 109.31.
3335 :     Fix: change strEntEnv to entEnv around line 545 of sigmatch.sml
3336 :     Test: bug1251.sml
3337 :     Owner: Zhong, dbm
3338 :     Status: fixed in 109.31 [Zhong, dbm]
3339 :     ----------------------------------------------------------------------
3340 :     Number: 1252
3341 :     Title: Unbound exception on functor application
3342 :     Keywords: modules, functors
3343 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3344 :     Date: 8/6/97
3345 :     Version: 109.30
3346 :     System: x86-linux
3347 :     Severity: minor
3348 :     Problem: A compiler bug is raised on the following code.
3349 :    
3350 :     Code:
3351 :    
3352 :     functor F(type t) =
3353 :     let structure S : sig
3354 :     type v
3355 :     val x : v
3356 :     end =
3357 :     struct
3358 :     datatype 'a u = U of (t * 'a) list
3359 :     type v = t u
3360 :     val x = U[]
3361 :     end
3362 :     in struct
3363 :     datatype t = T of S.v
3364 :     val x = T S.x
3365 :     end
3366 :     end;
3367 :    
3368 :     structure S = F(type t = int);
3369 :    
3370 :     Transcript:
3371 :    
3372 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3373 :     - functor F(type t) =
3374 :     let structure S : sig
3375 :     type v
3376 :     val x : v
3377 :     end =
3378 :     struct
3379 :     datatype 'a u = U of (t * 'a) list
3380 :     type v = t u
3381 :     val x = U[]
3382 :     end
3383 :     in struct
3384 :     datatype t = T of S.v
3385 :     val x = T S.x
3386 :     end
3387 :     end;
3388 :    
3389 :     - structure S = F(type t = int);
3390 :     functor F : <sig>
3391 :     Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
3392 :    
3393 :     [dbm: In 109.31-, the behavior is different. Unbound (EE.Unbound?) is
3394 :     raised instead: ]
3395 :    
3396 :     - use "test/bugs/bug1252.sml";
3397 :     [opening test/bugs/bug1252.sml]
3398 :     functor F : <sig>
3399 :    
3400 :     uncaught exception Unbound
3401 :     raised at: elaborate/elabmod.sml:1060.15-1060.25
3402 :     util/stats.sml:164.40
3403 :     build/evalloop.sml:123.38
3404 :     build/evalloop.sml:196.58
3405 :     build/evalloop.sml:289.46-289.49
3406 :    
3407 :     Comments:
3408 :     [Zhong]
3409 :     This seems to be the same as bug 1234.
3410 :     Fix:
3411 :     Test: bug1252.sml, bug1252.1.sml
3412 :     Owner: Zhong, dbm
3413 :     Status: Fixed in 109.31 [Zhong]
3414 :     ----------------------------------------------------------------------
3415 :     Number: 1253
3416 :     Title: pretty printing nested polymorphic records
3417 :     Keywords: pretty printing, representations
3418 :     Submitter: Chris Page <cap@cmu.edu>
3419 :     Date: 8/6/97
3420 :     Version: 109.30
3421 :     System: -
3422 :     Severity: major
3423 :     Problem:
3424 :     The code in the printer that tries to avoid printing
3425 :     polymorphic records doesn't work when the record is wrapped in another
3426 :     (non-record) type.
3427 :     Transcript:
3428 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3429 :     val it = () : unit
3430 :     - (NONE, ());
3431 :     val it = <poly-record> : 'a option * unit
3432 :     - SOME (NONE, ());
3433 :    
3434 :     uncaught exception in compiler: Representation
3435 :    
3436 :     Comments:
3437 :     [Zhong, 4/4/98]
3438 :     By the way, in 110.4, I have fixed the pretty printing of poly record.
3439 :     So typing things such as:
3440 :    
3441 :     val x = (nil, nil)
3442 :    
3443 :     or
3444 :    
3445 :     val x = (nil, 3)
3446 :    
3447 :     will print the expected values rather than <poly-record>.
3448 :    
3449 :     Fix:
3450 :     Test: bug1253.sml
3451 :     Owner: Zhong
3452 :     Status: fixed in 109.31
3453 :     ----------------------------------------------------------------------
3454 :     Number: 1254
3455 :     Title: Disagreements between SML/NJ and Defn: datatype replication
3456 :     Keywords: datatype replication
3457 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3458 :     Date: 8/11/97
3459 :     Version: 109.30
3460 :     System: x86-linux
3461 :     Severity: minor
3462 :     Problem:
3463 :     (1) I believe that the Standard says that the following
3464 :     program is legal, and should make 's' an abbreviation for
3465 :     'int'. However, SML/NJ responds with "Error: rhs of
3466 :     datatype replication not a datatype".
3467 :    
3468 :     type t = int
3469 :     datatype s = datatype t
3470 :    
3471 :     SML/NJ and the Standard both accept the following program,
3472 :     but I believe they do so for different reasons.
3473 :    
3474 :     (2)
3475 :     structure S : sig type t end =
3476 :     struct
3477 :     datatype t = T
3478 :     end
3479 :    
3480 :     datatype u = datatype S.t
3481 :    
3482 :     After the above program is entered, I believe that the
3483 :     Standard says that the following declaration is illegal,
3484 :     whereas SML/NJ accepts it.
3485 :    
3486 :     val x = T
3487 :    
3488 :     My reading of the Standard is that the signature
3489 :     constraint on 'S' should hide the constructors associated
3490 :     with type 't' and that the declaration of 'u' should
3491 :     declare 'u' as an abbreviation of 't', but not be able to
3492 :     access t's constructors, since they were hidden by the
3493 :     signature.
3494 :    
3495 :     Comments:
3496 :     [dbm, 8/14/97]
3497 :     Part (1) is considered an omission in the Definition.
3498 :     Part (2) is a bug because of rule (80), which says that
3499 :     the constructor environment component of t is stipped out
3500 :     by signature matching. This should really cause the
3501 :     subsequent datatype replication declaration
3502 :    
3503 :     datatype u = datatype S.t
3504 :    
3505 :     to fail, because there is no constructor environment for
3506 :     u to inherit from S.t, and a datatype without a constructor
3507 :     environment is not a proper datatype.
3508 :     Fix:
3509 :     Test: bug1254.sml
3510 :     Owner: dbm
3511 :     Status: open (2)
3512 :     ----------------------------------------------------------------------
3513 :     Number: 1255
3514 :     Title: Disagreements between SML/NJ and Defn: datatype replication, part II
3515 :     Keywords: datatype replication
3516 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3517 :     Date: 8/11/97
3518 :     Version: 109.30
3519 :     System: x86-linux
3520 :     Severity: minor
3521 :     Problem: I believe that the following code is legal, according
3522 :     to the Standard. However, SML/NJ rejects it, responding
3523 :     with:
3524 :    
3525 :     Error: value type in structure doesn't match signature spec
3526 :     name: U
3527 :     spec: ?.t -> ?.Foo.u
3528 :     actual: ?.int -> ?.Foo.u
3529 :    
3530 :     Code:
3531 :     structure Foo : sig
3532 :     type t
3533 :     datatype u = U of t
3534 :     structure Goo :
3535 :     sig
3536 :     datatype v = datatype u
3537 :     end
3538 :     end =
3539 :     struct
3540 :     type t = int
3541 :     datatype u = U of t
3542 :     structure Goo =
3543 :     struct
3544 :     datatype v = datatype u
3545 :     end
3546 :     end
3547 :    
3548 :     Transcript:
3549 :     Comments:
3550 :     Fix:
3551 :     Modified PATHtyc case of expandTyc in elabDATArepl in elabsig.sml.
3552 :     Check if entPath is external, in which case nothing needs to be
3553 :     done. Otherwise, if PATHtyc is internal to current signature, adjust
3554 :     it by adding appending prefix.
3555 :     Test: bug1255.sml
3556 :     Owner: dbm
3557 :     Status: fixed in 109.31 [dbm, 7/15/97]
3558 :     ----------------------------------------------------------------------
3559 :     Number: 1256
3560 :     Title: Free type variables in local datatype declarations.
3561 :     Keywords: datatype type variable
3562 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3563 :     Date: 8/11/97
3564 :     Version: 109.30
3565 :     System: x86-linux
3566 :     Severity: minor
3567 :     Problem: In a local datatype declarations, SML/NJ does not accept
3568 :     constructors whose types contain type variables that are not
3569 :     bound in the datatype declaration (even if they are bound
3570 :     in the enclosing program). For example, I believe that
3571 :     the Standard says that following program should be
3572 :     accepted. SML/NJ responds with "Error: unbound type
3573 :     variable in type declaration: 'a".
3574 :    
3575 :     Code:
3576 :     fun 'a f (x : 'a) =
3577 :     let datatype foo = Foo of 'a * int
3578 :     in 13
3579 :     end
3580 :     Transcript:
3581 :     Comments:
3582 :     [dbm, 8/13/97]
3583 :     This may technically be accepted under the definition, but this is
3584 :     an oversight or error in the definition. For various reasons, if
3585 :     a polymorphically bound type variable could participate in type
3586 :     definitions as in your example, there would be serious implementation
3587 :     complications for very little gain in utility. I don't plan to "fix"
3588 :     this bug in SML/NJ.
3589 :     Fix:
3590 :     Test: *
3591 :     Owner: dbm
3592 :     Status: not a bug
3593 :     ----------------------------------------------------------------------
3594 :     Number: 1257
3595 :     Title: (spurious) dependency cycle in instantiate
3596 :     Keywords: modules, opaque signatures
3597 :     Submitter: manuel@cs.berkeleye.edu
3598 :     Date: 8/19/97
3599 :     Version: SML-109.30 + blume patch
3600 :     System: x86-linux, sparc-solaris2.5
3601 :     Severity: major
3602 :     Problem: Opaque signature matching fails when the structure
3603 :     contains a functor whose signature has where
3604 :     specifications. Produces uncaught exception Unbound and
3605 :     a message "dependency cycle in instantiate"
3606 :    
3607 :     Code:
3608 :     signature S =
3609 :     sig
3610 :     type genT
3611 :    
3612 :     type T
3613 :    
3614 :     val embed : T -> genT
3615 :     end
3616 :    
3617 :    
3618 :     structure S =
3619 :     struct
3620 :     type genT = int
3621 :     type T = int
3622 :    
3623 :     val embed = fn x => x
3624 :     end
3625 :    
3626 :    
3627 :    
3628 :     signature B =
3629 :     sig
3630 :     type genT
3631 :    
3632 :     functor mkS() : S where type genT = genT
3633 :    
3634 :     end
3635 :    
3636 :     structure B :> B =
3637 :     struct
3638 :     type genT = S.genT
3639 :    
3640 :     functor mkS() = S
3641 :    
3642 :     end
3643 :    
3644 :     Transcript:
3645 :    
3646 :     - use "bug_inst.sml";
3647 :     [opening bug_inst.sml]
3648 :     bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate
3649 :    
3650 :     uncaught exception Unbound
3651 :     raised at: elaborate/elabmod.sml:1060.15-1060.25
3652 :     util/stats.sml:164.40
3653 :     build/evalloop.sml:123.38
3654 :     build/evalloop.sml:196.58
3655 :     build/evalloop.sml:289.46-289.49
3656 :     -
3657 :     Comments: The idea behind this code is to create new structures
3658 :     using B.mkS(), each of which will share the type genT,
3659 :     but not the type T.
3660 :    
3661 :     The desired behavior can be obtained with the following
3662 :     code, which moves the opaque matching from B to the
3663 :     functor. The difference to the code above is in that genT
3664 :     is not opaque in B.
3665 :    
3666 :     signature S =
3667 :     sig
3668 :     type genT
3669 :    
3670 :     type T
3671 :    
3672 :     val embed : T -> genT
3673 :     val new : int -> T
3674 :     val show : genT -> unit
3675 :    
3676 :     end
3677 :    
3678 :    
3679 :     structure S =
3680 :     struct
3681 :     type genT = int
3682 :     type T = int
3683 :    
3684 :     val embed = fn x => x
3685 :    
3686 :     fun new x = x
3687 :     val show = fn x => print (Int.toString x ^"\n")
3688 :    
3689 :     end
3690 :    
3691 :    
3692 :    
3693 :     signature B =
3694 :     sig
3695 :     type genT
3696 :    
3697 :     functor mkS() : S where type genT = genT
3698 :    
3699 :     end
3700 :    
3701 :     structure B : B =
3702 :     struct
3703 :     type genT = S.genT
3704 :    
3705 :     functor mkS() :> S where type genT = genT = S
3706 :    
3707 :     end
3708 :    
3709 :     structure X = B.mkS;
3710 :     structure Y = B.mkS;
3711 :    
3712 :     val x = X.new 5;
3713 :     val y = Y.new 7;
3714 :    
3715 :     val xe = X.embed x;
3716 :     val ye = X.embed y;
3717 :    
3718 :     val _ = X.show ye; (* is accepted correctly *)
3719 :     val _ = Y.show xe; (* is accepted correctly *)
3720 :     val xf = Y.embed x; (* rejected correctly *)
3721 :     val yf = X.embed y; (* rejected correctly *)
3722 :    
3723 :     val _ = X.show 5; (* genT isn't opaque. *)
3724 :    
3725 :     Fix:
3726 :     Test:
3727 :     Owner: dbm
3728 :     Status: Fixed in 109.31
3729 :     ----------------------------------------------------------------------
3730 :     Number: 1258
3731 :     Title: OS.Process.atExit does not agree with basis documentation
3732 :     Keywords: standard basis
3733 :     Submitter: Chris Stone, cstone+@cs.cmu.edu
3734 :     Perry Cheng, pscheng+@cs.cmu.edu
3735 :     Date: August 19, 1997
3736 :     Version: 109.30
3737 :     System: Alpha OSF/1 3.2
3738 :     Severity: minor
3739 :     Problem:
3740 :    
3741 :     From the on-line standard basis documentation for OS.Process.atExit:
3742 :    
3743 :     Calls to exit do not return, but should cause the remainder of the
3744 :     functions registered with atExit to be executed.
3745 :    
3746 :     The code does not have this behavior.
3747 :    
3748 :     Transcript:
3749 :    
3750 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3751 :     - OS.Process.atExit (fn _ => print "1\n");
3752 :     val it = () : unit
3753 :     - OS.Process.atExit (fn _ => print "2\n");
3754 :     val it = () : unit
3755 :     - OS.Process.atExit (fn _ => print "3\n");
3756 :     val it = () : unit
3757 :     - ^D3
3758 :     2
3759 :     1
3760 :    
3761 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3762 :     - OS.Process.atExit (fn _ => print "1\n");
3763 :     val it = () : unit
3764 :     - OS.Process.atExit (fn _ => OS.Process.exit 1);
3765 :     val it = () : unit
3766 :     - OS.Process.atExit (fn _ => print "3\n");
3767 :     val it = () : unit
3768 :     - ^D3
3769 :     3
3770 :     3
3771 :     3
3772 :     ...[infinite loop]
3773 :    
3774 :     Comments:
3775 :    
3776 :     A quick glance at the file NJ/cleanup.sml led us to initially expect
3777 :     that the call to exit would terminate the program immediately,
3778 :     skipping the third function registered with atExit. However, it turns
3779 :     out that since the "clean" function does not change the list "hooks"
3780 :     when called with the AtExit parameter, the call to exit starts
3781 :     re-invoking all of the functions registered with AtExit.
3782 :    
3783 :     Fix:
3784 :     Test:
3785 :     Owner: jhr
3786 :     Status: fixed in 109.31
3787 :     ----------------------------------------------------------------------
3788 :     Number: 1259
3789 :     Title: Mistakenly inadmissable signature.
3790 :     Keywords: modules, signatures
3791 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3792 :     Date: 8/19/97
3793 :     Version: 109.30
3794 :     System: x86-linux
3795 :     Severity: minor
3796 :     Problem:
3797 :     The following signature is not accepted by SML/NJ 109.30,
3798 :     even though it should be. SML/NJ 109.30 returns the message
3799 :     "Error: dependency cycle in instantiate". Earlier
3800 :     versions, such as 109.29, accepted this signature at
3801 :     the point it was declared, but reported the dependency
3802 :     cycle error when it was used as a functor parameter
3803 :     (i.e. when it was instantiated).
3804 :     Code:
3805 :     signature SIG =
3806 :     sig
3807 :     type b'
3808 :     datatype a = A1 | A2 of b'
3809 :     datatype b = B1 | B2 of a
3810 :     sharing type b = b'
3811 :     end
3812 :    
3813 :     The signature is accepted when it directly constrains a structure, as
3814 :     in the following code.
3815 :    
3816 :     structure S : sig
3817 :     type b'
3818 :     datatype a = A1 | A2 of b'
3819 :     datatype b = B1 | B2 of a
3820 :     sharing type b = b'
3821 :     end =
3822 :     struct
3823 :     datatype a = A1 | A2 of b
3824 :     and b = B1 | B2 of a
3825 :     type b' = b
3826 :     end
3827 :    
3828 :     Transcript:
3829 :     Comments:
3830 :     This might be the same as bug #1257.
3831 :    
3832 :     [Zhong, 8/21/97]
3833 :     Ok, in 109.30, we check the validity of every signature at its definition
3834 :     site (i.e., we try to instantiate it), thus the cycle is detected even
3835 :     at the declaration site.
3836 :    
3837 :     |> In any case, both versions are wrong to reject the signature, since it
3838 :     |> can be instantiated by the structure I provided.
3839 :     |>
3840 :     |> structure S : sig
3841 :     |> type b'
3842 :     |> datatype a = A1 | A2 of b'
3843 :     |> datatype b = B1 | B2 of a
3844 :     |> sharing type b = b'
3845 :     |> end =
3846 :     |> struct
3847 :     |> datatype a = A1 | A2 of b
3848 :     |> and b = B1 | B2 of a
3849 :     |> type b' = b
3850 :     |> end
3851 :    
3852 :     I'd not say our implementation is wrong :-) I'd argue that it is the
3853 :     Definition that is wrong --- in fact, the Definition is vague on how
3854 :     the above signature will be elaborated --- if you follow what's said
3855 :     in the Definition, you will get a structure of the form
3856 :    
3857 :     structure SIG-INST =
3858 :     struct type b' = b
3859 :     datatype a = A1 | A2 of b
3860 :     datatype b = B1 | B2 of a
3861 :     end
3862 :    
3863 :     [dbm: not quite. The definition (rule 78) elaborates the sharing
3864 :     spec by applying a substitution to an already elaborated environment
3865 :     structure representing the previous specs.]
3866 :    
3867 :     Notice I have no way to reorder the above into a valid ML structure.
3868 :     The best I can do is:
3869 :    
3870 :     structure SIG-INST =
3871 :     struct datatype a = A1 | A2 of b
3872 :     datatype b = B1 | B2 of a
3873 :     type b' = b
3874 :     end
3875 :    
3876 :     still type a and b are mutually recursive. To make it work, the
3877 :     signature elaboration has to make a and b mutually recursive:
3878 :    
3879 :     structure SIG-INST =
3880 :     struct datatype a = A1 | A2 of b
3881 :     and b = B1 | B2 of a
3882 :     type b' = b
3883 :     end
3884 :    
3885 :     This is non-trivial to generalize to cover other cases; for example,
3886 :     what if SIG is like the following:
3887 :    
3888 :     signature SIG' =
3889 :     sig type b'
3890 :     datatype a = A1 | A2 of b'
3891 :     structure S : sig
3892 :     datatype b = B1 | B2 of a
3893 :     end
3894 :     sharing type b' = S.b'
3895 :     end
3896 :    
3897 :     SIG' probably will not match any structure, but it is very hard
3898 :     to discover what is match-able and what is not.
3899 :    
3900 :     Because of all these, we decided to adopt a simpler algorithm
3901 :     in SML/NJ --- we'll only do reorganizations of all the specs,
3902 :     but we'll never merge two non-recursive datatype specs into
3903 :     mutually-recursive ones.
3904 :    
3905 :     [dbm, 8/5/97]
3906 :     I think that it would probably be possible to fix this "bug"
3907 :     superficially in the Instantiate module, but I am not sure what
3908 :     the consequences would be for FLINT's type representation analysis.
3909 :    
3910 :     In particular, with a signature declaration such as the
3911 :     following
3912 :    
3913 :     [1] signature SIG =
3914 :     sig
3915 :     type b'
3916 :     datatype a = A1 | A2 of b'
3917 :     datatype b = B1 | B2 of a
3918 :     sharing type b = b'
3919 :     end
3920 :    
3921 :     the datatypes a and b are made mutually recursive "after the fact"
3922 :     as a consequence of the type sharing spec. Will the FLINT
3923 :     representation analysis be able to come up with the same
3924 :     representations of a and b as for the following "equivalent"
3925 :     (see comment on equality properties below) signatures:
3926 :    
3927 :     [2] signature SIG =
3928 :     sig
3929 :     datatype a = A1 | A2 of b
3930 :     and b = B1 | B2 of a
3931 :     type b'
3932 :     sharing type b = b'
3933 :     end
3934 :    
3935 :     [3] signature SIG =
3936 :     sig
3937 :     datatype a = A1 | A2 of b
3938 :     and b = B1 | B2 of a
3939 :     type b' = b
3940 :     end
3941 :    
3942 :     and if you come up with different representations for the latter
3943 :     two signatures, does it matter?
3944 :    
3945 :     In other words, if you have two independent datatype specs, and
3946 :     then tie a knot between them by a subsequent sharing spec, can you
3947 :     recover the same representation as though the types had originally
3948 :     been specified as mutually recursive, or do you care?
3949 :    
3950 :     There is also the issue of assigning the equality properties to
3951 :     the specified types. In [1], b' does not admit equality, and
3952 :     therefore neither does a, and so neither does b. In [2] and [3],
3953 :     a and b, and therefore b', do admit equality. Does this inconsistency
3954 :     matter?
3955 :    
3956 :     Also, things can get much more convoluted; for instance
3957 :    
3958 :     signature SIG =
3959 :     sig
3960 :     structure A : sig
3961 :     type a
3962 :     end
3963 :     structure B : sig
3964 :     datatype b = B1 | B2 of A.a
3965 :     end
3966 :     structure C : sig
3967 :     datatype c = C1 | C2 of B.b
3968 :     end
3969 :     sharing type A.a = C.c
3970 :     end
3971 :    
3972 :     which could be matched by the structure
3973 :    
3974 :     structure S =
3975 :     struct
3976 :     datatype b = B1 | B2 of c
3977 :     and c = C1 | C2 of b
3978 :     structure A = struct
3979 :     type a = c
3980 :     end
3981 :     structure A = struct
3982 :     datatype b = datatype b
3983 :     end
3984 :     structure A = struct
3985 :     datatype c = datatype c
3986 :     end
3987 :     end
3988 :    
3989 :     I think it is clear that we don't want to force Instantiate
3990 :     to be this clever when attempting to create a realization.
3991 :    
3992 :     So how do we formulate a sharp condition that will disallow
3993 :     these kinds of recursion through sharing specs?
3994 :    
3995 :     Fix:
3996 :     Test: bug1259.1.sml, bug1259.2.sml, bug1259.3.sml
3997 :     Owner: dbm, Zhong
3998 :     Status: open
3999 :     ----------------------------------------------------------------------
4000 :     Number: 1260
4001 :     Title: Compiler bug (EntityEnv) when compiling ml-yacc
4002 :     Keywords:
4003 :     Submitter: John Reppy (jhr@research.bell-labs.com)
4004 :     Date: August 26, 1997
4005 :     Version: 109.30+
4006 :     System: all
4007 :     Severity: major
4008 :     Problem:
4009 :     I changed ml-yacc by replacing the three uses of "abstraction"
4010 :     with ":>". Now I get a compiler error on the file parser2.sml,
4011 :     which is one of the files I changed. I note that this file compiled
4012 :     okay in the context of the compiler, but not when trying to
4013 :     compile ml-yacc. Note, the changed file is accepted by 109.30,
4014 :     so this must have been introduced by one of the recent changes.
4015 :     Code:
4016 :     Transcript:
4017 :     [opening ../lib/parser2.sml]
4018 :     GC #0.0.0.1.3.62: (76 ms)
4019 :     lookEnt.1: expected STRent
4020 :     found entity: TYCent
4021 :     entpath: [#L.52,#L.1]
4022 :     Error: Compiler bug: EntityEnv: lookEnt.2
4023 :    
4024 :     uncaught exception TopLevelException [Error]
4025 :     raised at: util/errormsg.sml:54.14-54.19
4026 :     modules/instantiate.sml:1122.9
4027 :     elaborate/elabmod.sml:1119.8
4028 :     util/stats.sml:164.40
4029 :     build/evalloop.sml:123.38
4030 :     build/evalloop.sml:196.58
4031 :     build/evalloop.sml:289.46-289.49
4032 :    
4033 :     Comments:
4034 :     Zhong says:
4035 :     I found a fix for the bug. The bug was caused by Dave and Matthias's
4036 :     recent changes on turning off "pickling" in the top level (sigh ...).
4037 :     In fact, a more severe bug is the test case below.
4038 :    
4039 :     It turns out that the mkStamp function is making new stamp from 0
4040 :     when compiling each compilation unit (hmmm, not quite accurate, look
4041 :     when evalLoop is called in interact.sml). So t and s share the
4042 :     same stamp (L0).
4043 :    
4044 :     If we do pickling, s and t's stamps will be globalized during the
4045 :     pickling, so they will not be indentified.
4046 :    
4047 :     For the ML-Yacc, it is the similar reason. Because the stamp is not
4048 :     unique, the entity variable created for each signature component is
4049 :     not unique, this confuses the elaborator thus causing the bug.
4050 :    
4051 :     Fix:
4052 :     I make sure that the compiler never resets the global stamp
4053 :     counter --- notice that if the interactive loop is long enough
4054 :     (e.g., even after exportML,...); it is possible to run out of the stamps
4055 :     (i.e., overflow) --- especially the same stamp counter is now used
4056 :     for multiple purposes (stamp, entvar, ...). With pickling, the counter
4057 :     is reset each time and the pickler always globalize all the stamps
4058 :     (even hidden ones) with an external pid !
4059 :    
4060 :     Test:
4061 :     (* typing in each of the following at the top-level *)
4062 :    
4063 :     local datatype t = A
4064 :     in val x = A
4065 :     end;
4066 :    
4067 :     junk; (* this line is crucial; the purpose is to cause an error *)
4068 :    
4069 :     local datatype s = B
4070 :     in val y = B
4071 :     end;
4072 :    
4073 :     x = y;
4074 :    
4075 :     (* The compiler accepts the "x = y", and producing true. *)
4076 :    
4077 :     Owner: dbm, blume, zsh
4078 :     Status: fixed in 109.31
4079 :     ----------------------------------------------------------------------
4080 :     Number: 1261
4081 :     Title: explicit type parameter with "val rec" not supported
4082 :     Keywords: syntax, explicit type parameters
4083 :     Submitter: Dave MacQueen
4084 :     Date: 9/4/97
4085 :     Version: 109.30
4086 :     System: -
4087 :     Severity: minor
4088 :     Problem:
4089 :     Syntax "val 'a rec ..." not implemented.
4090 :     Transcript:
4091 :     - val 'a rec f = fn x : 'a => x;
4092 :     stdIn:14.8-14.15 Error: syntax error: deleting REC ID EQUALOP
4093 :     stdIn:14.16-14.22 Error: syntax error: deleting FN ID COLON
4094 :     stdIn:14.23-14.28 Error: syntax error: deleting TYVAR DARROW
4095 :     Comments:
4096 :     Fix:
4097 :     Test: bug1261.sml
4098 :     Owner: dbm, Appel
4099 :     Status: open
4100 :     ----------------------------------------------------------------------
4101 :     Number: 1262
4102 :     Title: literal ~0.0 reads as 0.0
4103 :     Keywords: floating point, literals
4104 :     Submitter: appel
4105 :     Date: August 19, 1997
4106 :     Version: 109.30
4107 :     System: any
4108 :     Severity: minor
4109 :     Problem: literal ~0.0 reads as 0.0
4110 :     Code: Real.copysign(1.0,~0.0)
4111 :     Transcript: val it = 1.0
4112 :     Comments:
4113 :     Fix: in first if-statement of ieeereal.sml
4114 :     Test: bug1262.sml
4115 :     Owner: Appel
4116 :     Status: open
4117 :     ----------------------------------------------------------------------
4118 :     Number: 1263
4119 :     Title: sqrt, ln incorrect on subnormal numbers
4120 :     Keywords: floating point, math
4121 :     Submitter: appel
4122 :     Date: August 19, 1997
4123 :     Version: 109.30
4124 :     System: any
4125 :     Severity: minor
4126 :     Problem: sqrt, ln incorrect on subnormal numbers
4127 :     Code: let val a = Math.sqrt(Real.minNormalPos * 0.1)
4128 :     in [Real.minNormalPos*0.1, a*a]
4129 :     end
4130 :     Transcript: val it = [2.22507385851e~309,1.22379062218e~308] : real list
4131 :     Comments: The scalb and logb functions in math64.sml
4132 :     called upon Assembly.A.scalb,logb,
4133 :     and were already augmented to handle a bigger range
4134 :     of cases than the assembly-lang primops,
4135 :     but I made them even fancier to handle subnormal
4136 :     inputs and outputs.
4137 :     Status: fixed in 109.31
4138 :     ----------------------------------------------------------------------
4139 :     Number: 1264
4140 :     Title: (spurious) dependency cycle in instantiate
4141 :     Keywords: modules, opaque signatures
4142 :     Submitter: manuel@cs.berkeleye.edu
4143 :     Date: 8/19/97
4144 :     Version: SML-109.27 + blume patch
4145 :     System: x86-linux, sparc-solaris2.5
4146 :     Severity: major
4147 :     Problem: Opaque signature matching fails when the structure
4148 :     contains a functor whose signature has where
4149 :     specifications. Produces uncaught exception Unbound and
4150 :     a message "dependency cycle in instantiate"
4151 :    
4152 :     Code:
4153 :     signature S =
4154 :     sig
4155 :     type genT
4156 :     type T
4157 :     val embed : T -> genT
4158 :     end;
4159 :    
4160 :     structure S =
4161 :     struct
4162 :     type genT = int
4163 :     type T = int
4164 :     val embed = fn x => x
4165 :     end;
4166 :    
4167 :     signature B =
4168 :     sig
4169 :     type genT
4170 :     functor mkS() : S where type genT = genT
4171 :     end;
4172 :    
4173 :     structure B :> B =
4174 :     struct
4175 :     type genT = S.genT
4176 :     functor mkS() = S
4177 :     end;
4178 :    
4179 :     Transcript:
4180 :    
4181 :     - use "bug_inst.sml";
4182 :     [opening bug_inst.sml]
4183 :     bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate
4184 :    
4185 :     uncaught exception Unbound
4186 :     raised at: elaborate/elabmod.sml:1060.15-1060.25
4187 :     util/stats.sml:164.40
4188 :     build/evalloop.sml:123.38
4189 :     build/evalloop.sml:196.58
4190 :     build/evalloop.sml:289.46-289.49
4191 :     -
4192 :     Comments: The idea behind this code is to create new structures
4193 :     using B.mkS(), each of which will share the type genT,
4194 :     but not the type T.
4195 :    
4196 :     The desired behavior can be obtained with the following
4197 :     code, which moves the opaque matching from B to the
4198 :     functor. The difference to the code above is in that genT
4199 :     is not opaque in B.
4200 :    
4201 :     signature S =
4202 :     sig
4203 :     type genT
4204 :     type T
4205 :    
4206 :     val embed : T -> genT
4207 :     val new : int -> T
4208 :     val show : genT -> unit
4209 :     end
4210 :    
4211 :     structure S =
4212 :     struct
4213 :     type genT = int
4214 :     type T = int
4215 :    
4216 :     val embed = fn x => x
4217 :    
4218 :     fun new x = x
4219 :     val show = fn x => print (Int.toString x ^"\n")
4220 :     end
4221 :    
4222 :     signature B =
4223 :     sig
4224 :     type genT
4225 :     functor mkS() : S where type genT = genT
4226 :     end
4227 :    
4228 :     structure B : B =
4229 :     struct
4230 :     type genT = S.genT
4231 :     functor mkS() :> S where type genT = genT = S
4232 :     end
4233 :    
4234 :     structure X = B.mkS;
4235 :     structure Y = B.mkS;
4236 :    
4237 :     val x = X.new 5;
4238 :     val y = Y.new 7;
4239 :    
4240 :     val xe = X.embed x;
4241 :     val ye = X.embed y;
4242 :    
4243 :     val _ = X.show ye; (* is accepted correctly *)
4244 :     val _ = Y.show xe; (* is accepted correctly *)
4245 :     val xf = Y.embed x; (* rejected correctly *)
4246 :     val yf = X.embed y; (* rejected correctly *)
4247 :    
4248 :     val _ = X.show 5; (* genT isn't opaque. *)
4249 :    
4250 :     Fix: <sorry>
4251 :     Test: bug1264.sml
4252 :     Owner: Zhong
4253 :     Status: fixed in 109.31 [Zhong, 8/21/97]
4254 :     ----------------------------------------------------------------------
4255 :     Number: 1265
4256 :     Title: uncaught Match exn in elabmod.sml:632.7
4257 :     Keywords: module elaboration, signature matching
4258 :     Submitter: manuel@cs.berkeley.edu
4259 :     Date: 8/19/97
4260 :     Version: 109.30 + Matthias Blume patch
4261 :     System: x86-linux, sparc-solaris2.5
4262 :     Severity: major
4263 :     Problem: Signature matching causes Match exception in compiler
4264 :     Code:
4265 :     structure J : S = K : T;
4266 :    
4267 :     Transcript:
4268 :     - structure J : S = K : T;
4269 :    
4270 :     uncaught exception in compiler: nonexhaustive match failure
4271 :     raised at: elaborate/elabmod.sml:632.7
4272 :     elaborate/elabmod.sml:1059.8
4273 :     util/stats.sml:164.40
4274 :     build/evalloop.sml:123.38
4275 :     build/evalloop.sml:196.58
4276 :     -
4277 :     Comments:
4278 :     Fix:
4279 :     Test: bug1265.sml
4280 :     Owner: Zhong, dbm
4281 :     Status: fixed in 109.31
4282 :     ----------------------------------------------------------------------
4283 :     Number: 1266
4284 :     Title: OS.Process.atExit does not agree with basis documentation
4285 :     Keywords: standard basis
4286 :     Submitter: Chris Stone, cstone+@cs.cmu.edu
4287 :     Perry Cheng, pscheng+@cs.cmu.edu
4288 :     Date: August 19, 1997
4289 :     Version: 109.30
4290 :     System: Alpha OSF/1 3.2
4291 :     Severity: minor
4292 :     Problem:
4293 :    
4294 :     From the on-line standard basis documentation for OS.Process.atExit:
4295 :    
4296 :     Calls to exit do not return, but should cause the remainder of the
4297 :     functions registered with atExit to be executed.
4298 :    
4299 :     The code does not have this behavior.
4300 :    
4301 :     Transcript:
4302 :    
4303 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
4304 :     - OS.Process.atExit (fn _ => print "1\n");
4305 :     val it = () : unit
4306 :     - OS.Process.atExit (fn _ => print "2\n");
4307 :     val it = () : unit
4308 :     - OS.Process.atExit (fn _ => print "3\n");
4309 :     val it = () : unit
4310 :     - ^D3
4311 :     2
4312 :     1
4313 :    
4314 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
4315 :     - OS.Process.atExit (fn _ => print "1\n");
4316 :     val it = () : unit
4317 :     - OS.Process.atExit (fn _ => OS.Process.exit 1);
4318 :     val it = () : unit
4319 :     - OS.Process.atExit (fn _ => print "3\n");
4320 :     val it = () : unit
4321 :     - ^D3
4322 :     3
4323 :     3
4324 :     3
4325 :     ...[infinite loop]
4326 :    
4327 :     Comments:
4328 :    
4329 :     A quick glance at the file NJ/cleanup.sml led us to initially expect
4330 :     that the call to exit would terminate the program immediately,
4331 :     skipping the third function registered with atExit. However, it turns
4332 :     out that since the "clean" function does not change the list "hooks"
4333 :     when called with the AtExit parameter, the call to exit starts
4334 :     re-invoking all of the functions registered with AtExit.
4335 :    
4336 :     Fix: *
4337 :     Test: *
4338 :     Owner: jhr
4339 :     Status: fixed in 109.31 [jhr, 8/19/97]
4340 :     ----------------------------------------------------------------------
4341 :     Number: 1267 (duplicate of bug 1259)
4342 :     Title: Mistakenly inadmissable signature.
4343 :     Keywords: modules, signatures, definition specs, datatype specs
4344 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
4345 :     Date: 8/19/97
4346 :     Version: 109.30
4347 :     System: x86-linux
4348 :     Severity: minor
4349 :     Problem: The following signature is not accepted by SML/NJ 109.30,
4350 :     even though it should be. SML/NJ 109.30 returns the message
4351 :     "Error: dependency cycle in instantiate". Earlier
4352 :     versions, such as 109.29, accepted this signature.
4353 :    
4354 :     signature SIG =
4355 :     sig
4356 :     type b'
4357 :     datatype a = A1 | A2 of b'
4358 :     datatype b = B1 | B2 of a
4359 :     sharing type b = b'
4360 :     end
4361 :    
4362 :     The signature is accepted when it directly constrains a
4363 :     structure, as in the following code.
4364 :    
4365 :     structure S : sig
4366 :     type b'
4367 :     datatype a = A1 | A2 of b'
4368 :     datatype b = B1 | B2 of a
4369 :     sharing type b = b'
4370 :     end =
4371 :     struct
4372 :     datatype a = A1 | A2 of b
4373 :     and b = B1 | B2 of a
4374 :     type b' = b
4375 :     end
4376 :    
4377 :     Code:
4378 :    
4379 :     Transcript:
4380 :     Comments:
4381 :     [Zhong, 8/21/97]
4382 :     |> In any case, both versions are wrong to reject the signature, since it
4383 :     |> can be instantiated by the structure I provided.
4384 :     |>
4385 :     |> structure S : sig
4386 :     |> type b'
4387 :     |> datatype a = A1 | A2 of b'
4388 :     |> datatype b = B1 | B2 of a
4389 :     |> sharing type b = b'
4390 :     |> end =
4391 :     |> struct
4392 :     |> datatype a = A1 | A2 of b
4393 :     |> and b = B1 | B2 of a
4394 :     |> type b' = b
4395 :     |> end
4396 :    
4397 :     I'd not say our implementation is wrong :-) I'd argue that it is the
4398 :     Definition that is wrong --- in fact, the Definition is vague on how
4399 :     the above signature will be elaborated --- if you follow what's said
4400 :     in the Definition, you will get a structure of the form
4401 :    
4402 :     structure SIG-INST =
4403 :     struct type b' = b
4404 :     datatype a = A1 | A2 of b
4405 :     datatype b = B1 | B2 of a
4406 :     end
4407 :    
4408 :     Notice I have no way to reorder the above into a valid ML structure.
4409 :     The best I can do is:
4410 :    
4411 :     structure SIG-INST =
4412 :     struct datatype a = A1 | A2 of b
4413 :     datatype b = B1 | B2 of a
4414 :     type b' = b
4415 :     end
4416 :    
4417 :     still type a and b are mutually recursive. To make it work, the
4418 :     signature elaboration has to make a and b mutually recursive:
4419 :    
4420 :     structure SIG-INST =
4421 :     struct datatype a = A1 | A2 of b
4422 :     and b = B1 | B2 of a
4423 :     type b' = b
4424 :     end
4425 :    
4426 :     This is non-trivial to generalize to cover other cases; for example,
4427 :     what if SIG is like the following:
4428 :    
4429 :     signature SIG' =
4430 :     sig type b'
4431 :     datatype a = A1 | A2 of b'
4432 :     structure S : sig
4433 :     datatype b = B1 | B2 of a
4434 :     end
4435 :     sharing type b' = S.b'
4436 :     end
4437 :    
4438 :     SIG' probably will not match any structure, but it is very hard
4439 :     to discover what is match-able and what is not.
4440 :    
4441 :     Because of all these, we decided to adopt a simpler algorithm
4442 :     in SML/NJ --- we'll only do reorganizations of all the specs,
4443 :     but we'll never merge two non-recursive datatype specs into
4444 :     mutually-recursive ones.
4445 :    
4446 :     Fix: -
4447 :     Test: -
4448 :     Owner: dbm, Zhong
4449 :     Status: not a bug
4450 :     ----------------------------------------------------------------------
4451 :     Number: 1268
4452 :     Title: logb of negative numbers on Sparc
4453 :     Keywords: floating point, logb
4454 :     Submitter: appel
4455 :     Date: 8/21/97
4456 :     Version: 109.30
4457 :     System: Sparc
4458 :     Severity: minor
4459 :     Problem: Assembly.A.logb gives bogus result for any negative number.
4460 :     Code: Assembly.A.logb ~1.0; (* this example from 109.29 *)
4461 :     Transcript: val it = 2048 : int
4462 :     Comments: broken since 109.26 or before
4463 :     [dbm, 11/11/97] Test case is obsolete in 109.32 because Assembly is
4464 :     not bound at top level. Needs to be tested indirectly by regression
4465 :     tests on Math, Real64 structures.
4466 :     Fix: in SPARC.prim.asm
4467 :     Test: bug1268.sml (obsolete)
4468 :     Owner: Appel
4469 :     Status: fixed in 109.31
4470 :     ----------------------------------------------------------------------
4471 :     Number: 1269
4472 :     Title: CM.set_path has no effect after CM.make
4473 :     Keywords: CM
4474 :     Submitter: John Reppy (jhr@research.bell-labs.com)
4475 :     Date: August 21, 1997
4476 :     Version: 109.30
4477 :     System: all
4478 :     Severity: minor
4479 :     Problem: One a CM.make command has been executed, changing the
4480 :     search path has no effect.
4481 :     Code:
4482 :     Transcript:
4483 :    
4484 :     - CM.make();
4485 :     [starting dependency analysis]
4486 :     [scanning sources.cm]
4487 :     [checking CM/mipseb-unix/sources.cm.stable ... not usable]
4488 :    
4489 :     !* CM error: smlnj-lib.cm: description file not found
4490 :     - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]);
4491 :     val it = [] : string list
4492 :     - CM.make();
4493 :     [starting dependency analysis]
4494 :    
4495 :     !* CM error: smlnj-lib.cm: description file not found
4496 :     -
4497 :    
4498 :     whereas, if I change the path first, it works fine.
4499 :    
4500 :     - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]);
4501 :     val it = [] : string list
4502 :     - CM.make();
4503 :     [starting dependency analysis]
4504 :     [scanning sources.cm]
4505 :     [checking CM/mipseb-unix/sources.cm.stable ... not usable]
4506 :     [scanning /home/sml/Dev/jhr/109.x/lib/smlnj-lib.cm -> /n/stew/home/sml/Dev/jhr/109.x/src/smlnj-lib/Util/sources.cm]
4507 :     ...
4508 :    
4509 :     Comments:
4510 :     Fix:
4511 :     Test:
4512 :     Owner: Blume
4513 :     Status: open?
4514 :     ----------------------------------------------------------------------
4515 :     Number: 1270
4516 :     Title: EntityEnv.Unbound raised while compiling functor
4517 :     Keywords: modules, functors, signature matching
4518 :     Submitter: Lal George
4519 :     Date: 9/8/97
4520 :     Version: 109.31
4521 :     System: -
4522 :     Severity: major
4523 :     Problem:
4524 :     EntityEnv.Unbound raised while compiling functor
4525 :     Code:
4526 :     (* bug1270.sml *)
4527 :    
4528 :     signature S2 =
4529 :     sig
4530 :     structure A : sig type s end
4531 :     val x : A.s
4532 :     end;
4533 :    
4534 :     signature S3 =
4535 :     sig
4536 :     type u
4537 :     val y : u
4538 :     end;
4539 :    
4540 :     functor F (structure X: S3) = (* "structure" necessary *)
4541 :     struct
4542 :     type s = X.u
4543 :     end;
4544 :    
4545 :     functor G (U: S3) (V: S2) : S2 = (* ": S2" necessary *)
4546 :     struct
4547 :     structure A = F (structure X = U)
4548 :     val x = U.y
4549 :     end;
4550 :     Transcript:
4551 :     - use "bug1270.sml";
4552 :     [opening bug1270.sml]
4553 :     signature S2 =
4554 :     sig
4555 :     structure A : sig type s end
4556 :     val x : A.s
4557 :     end
4558 :     signature S3 =
4559 :     sig
4560 :     type u
4561 :     val y : u
4562 :     end
4563 :     functor F : <sig>
4564 :    
4565 :     uncaught exception Unbound
4566 :     raised at: elaborate/elabmod.sml:1225.39-1225.49
4567 :     util/stats.sml:164.40
4568 :     build/evalloop.sml:123.38
4569 :     build/evalloop.sml:196.58
4570 :     build/evalloop.sml:292.19-292.22
4571 :    
4572 :     Comments:
4573 :     Regression failure for bug 922.
4574 :     Fix:
4575 :     Test: bug1270.sml
4576 :     Owner: dbm, Zhong
4577 :     Status: open
4578 :     ----------------------------------------------------------------------
4579 :     Number: 1271
4580 :     Title: uncaught Unbound while compiling open
4581 :     Keywords: modules, functors, open
4582 :     Submitter: Lal George
4583 :     Date: 9/8/97
4584 :     Version: 109.31
4585 :     System: -
4586 :     Severity: major
4587 :     Problem: uncaught Unbound while compiling open
4588 :     Code:
4589 :     signature SIG1 =
4590 :     sig
4591 :     type t
4592 :     val x: t
4593 :     end;
4594 :    
4595 :     signature SIG2 =
4596 :     sig
4597 :     functor Foo(X:SIG1) : sig val w: X.t end
4598 :     end;
4599 :    
4600 :     structure B : SIG2 = (* ": SIG2" is necessary *)
4601 :     struct
4602 :     functor Foo(X:SIG1) =
4603 :     struct
4604 :     val w = X.x
4605 :     end
4606 :     end;
4607 :    
4608 :     open B;
4609 :    
4610 :     Transcript:
4611 :     - use "bug1271.sml";
4612 :     [opening bug1271.sml]
4613 :     signature SIG1 =
4614 :     sig
4615 :     type t
4616 :     val x : t
4617 :     end
4618 :     signature SIG2 =
4619 :     sig functor Foo : (<paramname>: <sig>) : <sig> end
4620 :     structure B :
4621 :     SIG2
4622 :    
4623 :     uncaught exception Unbound
4624 :     raised at: translate/transmodules.sml:80.33-80.43
4625 :     util/stats.sml:164.40
4626 :     build/evalloop.sml:196.58
4627 :     build/evalloop.sml:292.19-292.22
4628 :     Comments:
4629 :     Regression failure for bug 641.
4630 :    
4631 :     The SIG2 signature constraint on B is necessary for the
4632 :     bug to occur.
4633 :    
4634 :     Other references to B.Foo, such as
4635 :    
4636 :     functor F = B.Foo
4637 :    
4638 :     or
4639 :    
4640 :     structure XX = B.Foo(struct type t = int val x = 3 end);
4641 :    
4642 :     will also cause an uncaught Unbound exception.
4643 :     Fix:
4644 :     Test: bug1271.sml
4645 :     Owner: dbm, Zhong
4646 :     Status: open
4647 :     ----------------------------------------------------------------------
4648 :     Number: 1272
4649 :     Title: Match exception raised in instantiate while elaborating sig
4650 :     Keywords: modules, signatures, definition specs, sharing
4651 :     Submitter: Lal George
4652 :     Date: 9/8/97
4653 :     Version: 109.31
4654 :     System: -
4655 :     Severity: major
4656 :     Problem:
4657 :     Match exception raised in instantiate while elaborating sig
4658 :     Code: (bug1272.sml)
4659 :     signature Z = sig end;
4660 :    
4661 :     signature S =
4662 :     sig
4663 :     structure A: Z
4664 :     end;
4665 :    
4666 :     signature T1 =
4667 :     sig
4668 :     structure B: S
4669 :     structure A : Z = B.A
4670 :     end;
4671 :    
4672 :     signature T2 =
4673 :     sig
4674 :     structure B: S
4675 :     structure A : Z = B.A
4676 :     end;
4677 :    
4678 :     signature V =
4679 :     sig
4680 :     structure C: T1
4681 :     structure D: T2
4682 :     sharing C = D
4683 :     end;
4684 :    
4685 :     Transcript:
4686 :     uncaught exception Match [nonexhaustive match failure]
4687 :     raised at: modules/instantiate.sml:706.6
4688 :     modules/instantiate.sml:802.29
4689 :     modules/instantiate.sml:1164.55