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 944 - (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 :     (* $Id$ *)
1794 :    
1795 :     val pi = 3.14159265358979323846
1796 :    
1797 :     val tpi = 2.0 * pi
1798 :    
1799 :     fun for(start,stop,f) =
1800 :     let fun loop i = if i > stop then () else (f i; loop (i+1))
1801 :     in
1802 :     loop start
1803 :     end
1804 :    
1805 :     val print_string : string -> unit = print
1806 :     val print_int : int -> unit = print_string o Int.toString
1807 :     val print_newline : unit -> unit = fn _ => print_string "\n"
1808 :    
1809 :     fun dump pxr pxi =
1810 :     for(0,15,fn i =>
1811 :     (print_int i;
1812 :     print " ";
1813 :     print_real (sub(pxr,i+1));
1814 :     print " ";
1815 :     print_real (sub(pxi,i+1));
1816 :     print_newline()))
1817 :    
1818 :    
1819 :     fun fft px py np =
1820 :     let val i = ref 2
1821 :     val m = ref 1
1822 :    
1823 :     val _ =
1824 :     while (!i < np) do
1825 :     (i := !i + !i;
1826 :     m := !m + 1)
1827 :     val n = !i
1828 :     in
1829 :     if n <> np then (
1830 :     for (np+1,n,fn i=>
1831 :     (update(px,i,0.0);
1832 :     update(py,i,0.0)));
1833 :     print_string "Use "; print_int n;
1834 :     print_string " point fft"; print_newline()
1835 :     ) else ();
1836 :    
1837 :     let val n2 = ref(n+n)
1838 :     in
1839 :     for(1,!m-1,fn k =>
1840 :     let val _ = n2 := !n2 div 2
1841 :     val n4 = !n2 div 4
1842 :     val e = tpi / (real (!n2 ))
1843 :     in
1844 :     for(1,n4,fn j =>
1845 :     let val a = e * real(j - 1)
1846 :     val a3 = 3.0 * a
1847 :     val cc1 = cos(a)
1848 :     val ss1 = sin(a)
1849 :     val cc3 = cos(a3)
1850 :     val ss3 = sin(a3)
1851 :     val is = ref j
1852 :     val id = ref(2 * !n2)
1853 :     in
1854 :     while !is < n do
1855 :     let val i0r = ref (!is)
1856 :     in
1857 :     while !i0r < n do
1858 :     let val i0 = !i0r
1859 :     val i1 = i0 + n4
1860 :     val i2 = i1 + n4
1861 :     val i3 = i2 + n4
1862 :     val r1 = sub(px,i0) - sub(px,i2)
1863 :     val _ = update(px,i0,sub(px,i0) + sub(px,i2))
1864 :     val r2 = sub(px,i1) - sub(px,i3)
1865 :     val _ = update(px,i1,sub(px,i1) + sub(px,i3))
1866 :     val s1 = sub(py,i0) - sub(py,i2)
1867 :     val _ = update(py,i0,sub(py,i0) + sub(py,i2))
1868 :     val s2 = sub(py,i1) - sub(py,i3)
1869 :     val _ = update(py,i1,sub(py,i1) + sub(py,i3))
1870 :     val s3 = r1 - s2
1871 :     val r1 = r1 + s2
1872 :     val s2 = r2 - s1
1873 :     val r2 = r2 + s1
1874 :     in
1875 :     update(px,i2,r1*cc1 - s2*ss1);
1876 :     update(py,i2,~s2*cc1 - r1*ss1);
1877 :     update(px,i3,s3*cc3 + r2*ss3);
1878 :     update(py,i3,r2*cc3 - s3*ss3);
1879 :     i0r := i0 + !id
1880 :     end;
1881 :     is := 2 * !id - !n2 + j;
1882 :     id := 4 * !id
1883 :     (* ; dump px py *)
1884 :     end
1885 :     end)
1886 :     end)
1887 :     end;
1888 :    
1889 :     (************************************)
1890 :     (* Last stage, length=2 butterfly *)
1891 :     (************************************)
1892 :    
1893 :     let val is = ref 1
1894 :     val id = ref 4
1895 :     in
1896 :     while !is < n do
1897 :     let val i0r = ref (!is)
1898 :     in
1899 :     while !i0r <= n do
1900 :     let val i0 = !i0r
1901 :     val i1 = i0 + 1
1902 :     val r1 = sub(px,i0)
1903 :     val _ = update(px,i0,r1 + sub(px,i1))
1904 :     val _ = update(px,i1,r1 - sub(px,i1))
1905 :     val r1 = sub(py,i0)
1906 :     in
1907 :     update(py,i0,r1 + sub(py,i1));
1908 :     update(py,i1,r1 - sub(py,i1));
1909 :     i0r := i0 + !id
1910 :     end;
1911 :     is := 2 * !id - 1;
1912 :     id := 4 * !id
1913 :     end
1914 :     end;
1915 :     (*
1916 :     print "\nbutterfly\n";
1917 :     dump px py;
1918 :     *)
1919 :     (*************************)
1920 :     (* Bit reverse counter *)
1921 :     (*************************)
1922 :    
1923 :     let val j = ref 1
1924 :     in
1925 :     for (1,n-1,fn i =>
1926 :     (if i < !j then (
1927 :     let val xt1 = sub(px,!j)
1928 :     val xt2 = sub(px,i)
1929 :     val _ = update(px,!j,xt2)
1930 :     val _ = update(px,i,xt1)
1931 :     val yt1 = sub(py,!j)
1932 :     val yt2 = sub(py,i)
1933 :     in
1934 :     update(py,!j,yt2);
1935 :     update(py,i,yt1)
1936 :     end)
1937 :     else ();
1938 :     let val k = ref(n div 2)
1939 :     in
1940 :     while !k < !j do (j := !j - !k; k := !k div 2);
1941 :     j := !j + !k
1942 :     end));
1943 :     (*
1944 :     print "\nbit reverse\n";
1945 :     dump px py;
1946 :     *)
1947 :     n
1948 :     end
1949 :     end;
1950 :    
1951 :     fun test np =
1952 :     (print_int np; print_string "... ";
1953 :     let val enp = real np
1954 :     val npm = np div 2 - 1
1955 :     val pxr = array ((np+2), 0.0)
1956 :     val pxi = array ((np+2), 0.0)
1957 :     val t = pi / enp
1958 :     val _ = update(pxr,1,(enp - 1.0) * 0.5)
1959 :     val _ = update(pxi,1,0.0)
1960 :     val n2 = np div 2
1961 :     val _ = update(pxr,n2+1,~0.5)
1962 :     val _ = update(pxi,n2+1,0.0)
1963 :     in
1964 :     for (1,npm,fn i =>
1965 :     let val j = np - i
1966 :     val _ = update(pxr,i+1,~0.5)
1967 :     val _ = update(pxr,j+1,~0.5)
1968 :     val z = t * (real i)
1969 :     val y = ~0.5 * (cos(z)/sin(z))
1970 :     in
1971 :     update(pxi,i+1,y);
1972 :     update(pxi,j+1,~y)
1973 :     end);
1974 :     (*
1975 :     print "\n"; print "before fft: \n";
1976 :     dump pxr pxi;
1977 :     *)
1978 :     fft pxr pxi np;
1979 :     (*
1980 :     print "\n"; print "after fft: \n";
1981 :     dump pxr pxi;
1982 :     *)
1983 :     let val zr = ref 0.0
1984 :     val zi = ref 0.0
1985 :     val kr = ref 0
1986 :     val ki = ref 0
1987 :     in
1988 :     for (0,np-1,fn i =>
1989 :     let val a = abs_real(sub(pxr,i+1) - (real i))
1990 :     in
1991 :     if !zr < a then
1992 :     (zr := a;
1993 :     kr := i)
1994 :     else ();
1995 :     let val a = abs_real(sub(pxi,i+1))
1996 :     in
1997 :     if !zi < a then
1998 :     (zi := a;
1999 :     ki := i)
2000 :     else ()
2001 :     end
2002 :     end);
2003 :     let val zm = if abs_real (!zr) < abs_real (!zi) then !zi else !zr
2004 :     in
2005 :     print_real zm; print_newline()
2006 :     end
2007 :     end
2008 :     end)
2009 :    
2010 :     fun doit() =
2011 :     let val np = ref 16
2012 :     in for(1,13,fn i => (test (!np); np := (!np)*2))
2013 :     end
2014 :    
2015 :     in
2016 :     val _ = doit()
2017 :     end
2018 :    
2019 :     Transcript:
2020 :    
2021 :     Standard ML of New Jersey, Version 109.28, May 23, 1997 [CM&CMB]
2022 :     val it = () : unit
2023 :     - use "/afs/cs/user/pscheng/bug.sml";
2024 :     [opening /afs/cs/user/pscheng/bug.sml]
2025 :     GC #0.0.0.0.1.6: (10 ms)
2026 :     GC #0.0.0.0.2.24: (14 ms)
2027 :     GC #0.0.0.1.3.40: (23 ms)
2028 :     GC #0.0.0.1.4.51: (16 ms)
2029 :     GC #0.0.1.2.5.60: (55 ms)
2030 :     GC #0.0.1.3.6.96: (12 ms)
2031 :     GC #0.0.1.3.7.120: (23 ms)
2032 :     16... 8.881784197e~16
2033 :     32... 3.5527136788e~15
2034 :     64... 1.06581410364e~14
2035 :     128... 2.84217094304e~14
2036 :     256... 5.68434188608e~14
2037 :     512... 1.16795462191e~13
2038 :     1024... GC #0.0.1.4.8.130: (1 ms)
2039 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c205c pc=2b439f4 ra=2b43994
2040 :     type=stt
2041 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c2064 pc=2b43a28
2042 :     ra=ffffffffffffffff type=stt
2043 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c206c pc=2b439f4
2044 :     ra=ffffffffffffffff type=stt
2045 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c2074 pc=2b43a28
2046 :     ra=ffffffffffffffff type=stt
2047 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c207c pc=2b439f4
2048 :     ra=ffffffffffffffff type=stt
2049 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c2084 pc=2b43a28
2050 :     ra=ffffffffffffffff type=stt
2051 :     Unaligned access pid=1001 <run.alpha32x-osf> va=31c208c pc=2b439f4
2052 :     ra=ffffffffffffffff type=stt
2053 :    
2054 :     Comments: This works correctly in 109.25.
2055 :     [Zhong, 6/26/97]
2056 :     This seems to be an Alpha-specific bug, as the above code work
2057 :     fine on my SPARC. Do we align all floating-point numbers on Alpha ?
2058 :     [jhr, 6/26/97]
2059 :     I suspect that it must be a bug in the code generator. The run-time
2060 :     system and garbage collector aligns all real and real array objects
2061 :     on 64-bit boundries on all machines.
2062 :    
2063 :     BTW, I hope this code is not being used for benchmarking. It uses
2064 :     int refs to do iteration, instead of the more natural (and more
2065 :     efficient) tail recursive form.
2066 :    
2067 :     [Lal, 6/29/97]
2068 :     The bug is in the runtime system, in the routine
2069 :     runtime/gc/ml-object.c:ML_AllocRealdarray.
2070 :    
2071 :     If garbage collection is invoked there is no guarantee that the
2072 :     next word in the STRING arena is properly aligned.
2073 :    
2074 :     ------
2075 :     ml_val_t ML_AllocRealdarray (ml_state_t *msp, int len)
2076 :     {
2077 :     int nwords = DOUBLES_TO_WORDS(len);
2078 :     if (nwords > SMALL_OBJ_SZW) {
2079 :     arena_t *ap = msp->ml_heap->gen[0]->arena[STRING_INDX];
2080 :     BEGIN_CRITICAL_SECT(MP_GCGenLock)
2081 :     #ifdef ALIGN_REALDS
2082 :     /* Force REALD_SZB alignment (descriptor is off by one word) */
2083 :     ap->nextw = (ml_val_t *)((Addr_t)(ap->nextw) | WORD_SZB);
2084 :     #endif
2085 :     IFGC (ap, (WORD_SZB*(nwords + 1))+msp->ml_heap->allocSzB) {
2086 :     /* we need to do a GC */
2087 :     ap->reqSizeB += WORD_SZB*(nwords + 1);
2088 :     RELEASE_LOCK(MP_GCGenLock);
2089 :     InvokeGC (msp, 1);
2090 :     ACQUIRE_LOCK(MP_GCGenLock);
2091 :     }
2092 :     *(ap->nextw++) = desc; <<<<<< not aligned.
2093 :     res = PTR_CtoML(ap->nextw);
2094 :     ap->nextw += nwords;
2095 :    
2096 :     ----
2097 :    
2098 :     A crude fix to get you going is to replicate the
2099 :     #ifdef ALIGN_REALDS ... #endif
2100 :    
2101 :     just before the line containing:
2102 :    
2103 :     *(ap->nextw++) = desc; <<<<<< not aligned.
2104 :    
2105 :     p.s. This bug manifested on the HPPA, and this fix solved the
2106 :     problem. I have not tested this on the alpha, so please let me know if
2107 :     it works on the alpha as well. Thanks.
2108 :     Fix:
2109 :     Test:
2110 :     Owner: Lal, jhr
2111 :     Status: fixed in 109.30
2112 :     ----------------------------------------------------------------------
2113 :     Number: 1228
2114 :     Title: various Real functions on Alpha
2115 :     Keywords: Floating point, Real
2116 :     Submitter: Andrew.Kennedy@persimmon.co.uk, George Russell <george@persimmon.co.uk>
2117 :     Date: 7/7/97
2118 :     Version: 109.29
2119 :     System: Alpha, OSF 4.0
2120 :     Severity: Minor
2121 :     Problem:
2122 :     1. Real.ceil and Real.floor cause segmentation fault on reals
2123 :     whose integer equivalent is out of range
2124 :     2. Real.signBit (~0.0);
2125 :     returns false on both Alpha/OSF 4.0 and Linux/i386.
2126 :     3. Real.fromManExp{exp=0,man=1.5};
2127 :     causes SML/NJ 109.29 to hang forever (well, 8 GCs so far and counting)
2128 :     on Alpha/Digital Unix 4 and i686/Linux
2129 :     4. Real.toManExp(1.0);
2130 :     returns
2131 :     {exp=0,man=1.0}
2132 :     for both Alpha/Digital Unix 4.0 and Linux/i686. However by my version
2133 :     of the standard this is wrong because we should have
2134 :     0.5<=man<1.0. The correct answer is {exp=1,man=0.5}. The local
2135 :     version of frexp gets this right, incidentally.
2136 :     5. Real.isNormal 0.0
2137 :     ought to return false.
2138 :    
2139 :     Code: Real.floor 1073741824.0
2140 :     Transcript:
2141 :     Comments:
2142 :     [Kennedy] NB Real.ceil 1073741823.1 correctly raises Overflow
2143 :     [jhr, 7/7/97]
2144 :     > Real.signBit (~0.0);
2145 :     > returns false on both Alpha/OSF 4.0 and Linux/i386.
2146 :    
2147 :     Actually, this is a feature of the IEEE 754-1985 specification.
2148 :     The negation of zero is negative zero, only when the rounding
2149 :     mode is set to TO_NEGINF.
2150 :    
2151 :     I don't know if the SML specification says anything about how
2152 :     the literal ~0.0 should be interpreted (is it the same as
2153 :     Real.~(0.0) in default rounding mode)?
2154 :     [appel, 9/17/97]
2155 :     No, this is not true. The IEEE specification calls for the
2156 :     negation of 0.0 to be ~0.0 regardless of rounding mode.
2157 :    
2158 :     [jhr, 7/7/97]
2159 :     I've tried the various FP bugs on canna, and here is some more info:
2160 :    
2161 :     1) The Real.floor and Real.ceil of 1073741824.0 work correctly. This
2162 :     is probably a bug in the assembly code for floor.
2163 :    
2164 :     2) Real.signBit(~0.0) returns false, but Real.signBit(0.0/ ~1.0) returns
2165 :     true. This is probably not a bug, but a feature of the IEEE specification.
2166 :    
2167 :     3) Real.fromManExp{exp=0,man=1.5} goes to lunch on the MIPS too. I suspect
2168 :     this is a bug in the Real.fromManExp function (written by Andrew, I think).
2169 :    
2170 :     Fix: [for which part?]
2171 :     [Lal, 7/7/97]
2172 :     Thanks for the bug report. In the file
2173 :     src/runtime/mach-dep/ALPHA32-prim.asm
2174 :    
2175 :     there are two labels called floor_overflow that require a trapb
2176 :     instruction at the end. The first floor_overflow label should look
2177 :     like:
2178 :    
2179 :     floor_overflow:
2180 :     ldl ATMP1, ovfl_MAXINT
2181 :     addlv ATMP1, ATMP1, ATMP1
2182 :     trapb
2183 :    
2184 :     and the second should look like:
2185 :    
2186 :     floor_overflow:
2187 :     addq $30, 16, $30
2188 :     ldl ATMP1, ovfl_MAXINT
2189 :     addlv ATMP1, ATMP1, ATMP1
2190 :     trapb
2191 :    
2192 :     The stack deallocation must be added to the second label as well.
2193 :    
2194 :     Making this change and recompiling the runtime system fixes this
2195 :     problem.
2196 :     Test: *
2197 :     Owner: jhr, Lal
2198 :     Status: fixed in 109.31 [Lal, Andrew]
2199 :     ----------------------------------------------------------------------
2200 :     Number: 1229
2201 :     Title: Bugs in unionWith, unionWithi of smlnj-lib
2202 :     Keywords: smlnj-lib, binary-set-map
2203 :     Submitter: Yasuhiko Minamide, nan@kurims.kyoto-u.ac.jp
2204 :     Date: 7/11/1997
2205 :     Version: 109.29
2206 :     System: any
2207 :     Severity: minor
2208 :     Problem:
2209 :    
2210 :     The behaviour of unionWith and unionWithi of smlnj-lib seems wrong.
2211 :    
2212 :     Code:
2213 :    
2214 :     let open IntBinaryMap
2215 :     val x = insert (insert (empty, 1,1), 2, 2)
2216 :     val y = insert (empty, 1, 0)
2217 :     val z = unionWith (fn (x,y) => x) (x, y)
2218 :     in
2219 :     listItemsi z
2220 :     end
2221 :    
2222 :     Transcript:
2223 :    
2224 :     The code above returns
2225 :    
2226 :     val it = [(1,0),(2,2)] : (int * int) list
2227 :    
2228 :     I think that this should be
2229 :    
2230 :     val it = [(1,1),(2,2)] : (int * int) list
2231 :    
2232 :     Test: *
2233 :     Owner: jhr
2234 :     Status: fixed in 109.30 [jhr, 7/14/97]
2235 :     ----------------------------------------------------------------------
2236 :     Number: 1230
2237 :     Title: bus-error due to representation problem
2238 :     Keywords: bus-error
2239 :     Submitter: manuel@cs.berkeley.edu
2240 :     Date: July 12
2241 :     Version: 109.26 and 109.29
2242 :     System: Solaris Ultrasparc and Linux i686
2243 :     Severity: severe
2244 :     Problem: Small test program crashes sml process
2245 :     Code:
2246 :     signature CONS =
2247 :     sig
2248 :     type 'a sign
2249 :     type 'a constructor
2250 :    
2251 :     val new : {name : string,
2252 :     signa : 'a sign} -> 'a constructor
2253 :    
2254 :     end
2255 :    
2256 :     structure Cons : CONS =
2257 :     struct
2258 :    
2259 :     datatype sort =
2260 :     SUB
2261 :     | CSUB
2262 :    
2263 :     datatype datacon = DCON of {name : string,
2264 :     arity : int,
2265 :     sign : sort list,
2266 :     sort : sort,
2267 :     strict : bool}
2268 :    
2269 :     type 'a constructor = datacon
2270 :     type 'a sign = {sign : sort list, sort : sort, strict : bool}
2271 :    
2272 :     fun new {name,signa={sign,sort,strict}} =
2273 :     DCON {name=name,
2274 :     arity=List.length sign,
2275 :     sign=sign,
2276 :     sort=sort,
2277 :     strict=strict
2278 :     }
2279 :    
2280 :     end
2281 :    
2282 :     Transcript:
2283 :     [Solaris,UltraSparc]
2284 :     Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
2285 :     - [opening /tmp/mla002oZ]
2286 :     signature CONS =
2287 :     sig
2288 :     type 'a sign
2289 :     type 'a constructor
2290 :     val new : {name:string, signa:'a sign} -> 'a constructor
2291 :     end
2292 :     structure Cons :
2293 :     CONS?
2294 :     val it = () : unit
2295 :     - Cons.new;
2296 :    
2297 :     Process sml bus error
2298 :    
2299 :     [Linux i686]
2300 :     Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
2301 :     use "/tmp/mla32088";^M
2302 :     - [opening /tmp/mla32088]
2303 :     signature CONS =
2304 :     sig
2305 :     type 'a sign
2306 :     type 'a constructor
2307 :     val new : {name:string, signa:'a sign} -> 'a constructor
2308 :     end
2309 :     structure Cons :
2310 :     CONS?
2311 :     val it = () : unit
2312 :     - Cons.new;
2313 :     /disks/orodruin/aa/home/manuel/Projects/sml-109.26/bin/.run/run.x86-linux:
2314 :     Fatal error --\
2315 :     unexpected fault, signal = 11, code = 0x4081346b
2316 :    
2317 :     Process sml exited abnormally with code 1
2318 :    
2319 :     Comments:
2320 :     I tried to make the example as short as possible. It seems important
2321 :     that the datatype DCON have at least 5 fields in the record, and that
2322 :     new takes 2 arguments.
2323 :    
2324 :     Fix:
2325 :     Test: bug1230.sml
2326 :     Owner: Zhong
2327 :     Status: fixed in 109.30 [Zhong]
2328 :     ----------------------------------------------------------------------
2329 :     Number: 1231
2330 :     Title: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
2331 :     Keywords: secondary error, error recovery
2332 :     Submitter: manuel@cs.berkeley.edu
2333 :     Date: July 12
2334 :     Version: 109.29
2335 :     System: Solaris Ultrasparc
2336 :     Severity: severe
2337 :     Problem: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
2338 :     Code:
2339 :     signature CONS =
2340 :     sig
2341 :     type 'a sign
2342 :     type 'a constructor
2343 :    
2344 :     val new : {name : string,
2345 :     signa : 'a sign} -> 'a constructor
2346 :    
2347 :     end
2348 :    
2349 :     structure Cons : CONS =
2350 :     struct
2351 :    
2352 :     datatype sort =
2353 :     SUB
2354 :     | CSUB
2355 :    
2356 :     datatype datacon = DCON of {name : string,
2357 :     arity : int,
2358 :     sign : sort list,
2359 :     sort : sort,
2360 :     strict : bool}
2361 :    
2362 :     type 'a constructor = datacon
2363 :     datatype 'a sign = Sign of {sign : sort list, sort : sort, strict : bool}
2364 :    
2365 :     fun new {name,signa=Sign{sign,sort,strict}} =
2366 :     DCON {name=name,
2367 :     arity=List.length sign,
2368 :     sign=sign,
2369 :     sort=sort,
2370 :     strict=strict
2371 :     }
2372 :    
2373 :     end
2374 :    
2375 :     signature B =
2376 :     sig
2377 :     structure Cons : Cons
2378 :     end
2379 :    
2380 :     structure B :> B =
2381 :     struct
2382 :     structure Cons = Cons
2383 :     end
2384 :    
2385 :     Transcript:
2386 :     Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled]
2387 :     - [opening /tmp/mla002oZ]
2388 :     /tmp/mla002oZ:39.2-40.5 Error: unbound signature: Cons
2389 :     Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
2390 :    
2391 :     uncaught exception Error
2392 :     raised at: util/errormsg.sml:51.14-51.19
2393 :     modules/sigmatch.sml:807.24
2394 :     elaborate/elabmod.sml:1039.8
2395 :     util/stats.sml:164.40
2396 :     build/evalloop.sml:120.38
2397 :     build/evalloop.sml:192.58
2398 :     build/evalloop.sml:284.46-284.49
2399 :     -
2400 :     Comments:
2401 :     Fix:
2402 :     Test: bug1231.sml
2403 :     Owner: Zhong
2404 :     Status: fixed in 109.30
2405 :     ----------------------------------------------------------------------
2406 :     Number: 1232
2407 :     Title: consistent definitional specs seen as inconsistent
2408 :     Keywords: modules, signatures, definitional specs, where definitions
2409 :     Submitter: Norman Ramsey <nr@cs.virginia.edu>
2410 :     Date: 6/19/97
2411 :     Version: 109.29
2412 :     System: -
2413 :     Severity: major
2414 :     Problem:
2415 :     Definitional specs are rejected as inconsistent when they are not.
2416 :     Code:
2417 :     signature SIG1 =
2418 :     sig
2419 :     type t = int
2420 :     end
2421 :    
2422 :     signature SIG2 =
2423 :     sig
2424 :     structure N : SIG1
2425 :     end
2426 :    
2427 :     functor Bad(structure X : SIG1
2428 :     structure Y : SIG2 where N = X) =
2429 :     struct end;
2430 :    
2431 :     Transcript:
2432 :     - use "foo.sml";
2433 :     [opening foo.sml]
2434 :     foo.sml:11.9-13.11 Error: Inconsistent defining constraints : type t = t
2435 :    
2436 :     uncaught exception Error
2437 :     raised at: build/evalloop.sml:103.44-103.52
2438 :     build/evalloop.sml:120.38
2439 :     build/evalloop.sml:193.58
2440 :     build/evalloop.sml:285.46-285.49
2441 :    
2442 :     Comments:
2443 :     Confusing error message too.
2444 :     Fix:
2445 :     Remove consistency checking for multiple definitions in
2446 :     Instantiate.builtTycClass.constrain when one or both definitions
2447 :     are not instantiated (NOTINST tyc).
2448 :     Test: bug1232.sml
2449 :     Owner: dbm
2450 :     Status: fixed in 109.30 [dbm, 7/16/97]
2451 :     ----------------------------------------------------------------------
2452 :     Number: 1233
2453 :     Title: funny printing of multiple bindings in a declaration
2454 :     Keywords: printing, duplicate binding
2455 :     Submitter: Walid Taha
2456 :     Date: 7/16/97
2457 :     Version: 109.29
2458 :     System: -
2459 :     Severity: minor
2460 :     Problem:
2461 :     The top level prints an odd message when a value variable is bound twice
2462 :     in a declaration.
2463 :     Transcript:
2464 :     - val c = 1 val c = 2;
2465 :     val c = <hidden-value> : int
2466 :     val c = 2 : int
2467 :     Comments:
2468 :     It would be preferable to just print
2469 :    
2470 :     val c = 2 : int
2471 :    
2472 :     as the result of the declaration.
2473 :     Fix:
2474 :     Test: bug1233.sml
2475 :     Owner: Zhong?
2476 :     Status: open
2477 :     ----------------------------------------------------------------------
2478 :     Number: 1234
2479 :     Title: EntityEnv.Unbound raised in functor application
2480 :     Keywords: modules, translation, hidden types
2481 :     Submitter: Dave MacQueen
2482 :     Date: 7/21/97
2483 :     Version: 109.30 (+ bug 1206 fix)
2484 :     System: -
2485 :     Severity: major
2486 :     Problem:
2487 :     EntityEnv.Unbound exception raised in function specLty when compiling
2488 :     legal functor application.
2489 :     Code:
2490 :     functor F(type t val x : t) =
2491 :     struct
2492 :     structure U : sig type u val y : u end =
2493 :     struct
2494 :     datatype u = K of t
2495 :     type u = u list
2496 :     val y = [K x]
2497 :     end
2498 :     val z = hd U.y
2499 :     end;
2500 :    
2501 :     structure A = T(type t = int val x = 3);
2502 :     Transcript:
2503 :     - use "bug1234.sml";
2504 :     [opening bug1234.sml]
2505 :     functor F : <sig>
2506 :    
2507 :     uncaught exception Unbound
2508 :     raised at: translate/transmodules.sml:79.33-79.43
2509 :     util/stats.sml:164.40
2510 :     build/evalloop.sml:193.58
2511 :     build/evalloop.sml:285.46-285.49
2512 :     Comments:
2513 :     [dbm]
2514 :     This is after incorporating the fix for bug 1206.
2515 :     If the signature on U is removed, the code works.
2516 :    
2517 :     Looking at the functor representation and the bad entityEnv with
2518 :     debugging on, it looks like signature matching is introducing an extra
2519 :     level of structure nesting. The path to the hidden datatype u should
2520 :     be of length 2, but in the entityEnv, the datatype is nested inside an
2521 :     extra intermediate structure, so the length two path doesn't reach it.
2522 :     I presume that sigmatch is creating the extra intermediate structure
2523 :     level.
2524 :    
2525 :     Fix:
2526 :     Test: bug1234.sml
2527 :     Owner: dbm, Zhong
2528 :     Status: Fixed in 109.31 [Zhong]
2529 :     ----------------------------------------------------------------------
2530 :     Number: 1235
2531 :     Title: Argument type constraint changes behavior of a function
2532 :     Keywords: types
2533 :     Submitter: Sam Kamin, s-kamin@uiuc.edu
2534 :     Date: 7/21/97
2535 :     Version: Version 109.29, June 13, 1997 [CM&CMB]
2536 :     System: sparc-solaris, don't know what version offhand
2537 :     Severity: major
2538 :     Problem: Function defined as fun f x = ... type-checks, but then
2539 :     crashes. When defined as fun f (x:T) = ..., it works
2540 :     fine.
2541 :     Code: I'm not going to send enough to reproduce the error,
2542 :     because it's too much. If this turns out to be an
2543 :     interesting problem, I can send it. Anyway, the specific
2544 :     problem is demonstrated in this function:
2545 :    
2546 :     fun mkseqlist seqop [] = empty
2547 :     | mkseqlist seqop [p:Picture] = p
2548 :     | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
2549 :    
2550 :     If the ":Picture" in the second clause is omitted, the
2551 :     function type-checks but crashes when used.
2552 :    
2553 :     Transcript: In this transcript, "seq" is an infix operator. As I said,
2554 :     I haven't come up with a simpler example, and I don't
2555 :     think you want all the code (especially not if this turns
2556 :     out to be something simple).
2557 :    
2558 :     - fun mkseqlist seqop [] = empty
2559 :     | mkseqlist seqop [p] = p
2560 :     | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
2561 :     = = val mkseqlist = fn
2562 :     : ((('a -> string) * Environment) * (('a -> string) * Environment)
2563 :     -> ('a -> string) * Environment)
2564 :     -> (('a -> string) * Environment) list -> ('a -> string) *
2565 :     Environment
2566 :     - val seqlist = mkseqlist (op seq);
2567 :     val seqlist = fn
2568 :     : ((GraphicsContext -> string) * Environment) list
2569 :     -> (GraphicsContext -> string) * Environment
2570 :     - draw (seqlist [text "a"]) "test";
2571 :     ~2.34725596609e228, ~2.34705354077e228
2572 :     uncaught exception Overflow [overflow]
2573 :     - fun mkseqlist seqop [] = empty
2574 :     | mkseqlist seqop [p:Picture] = p
2575 :     | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
2576 :     = = val mkseqlist = fn
2577 :     : (Picture * ((GraphicsContext -> string) * Environment)
2578 :     -> (GraphicsContext -> string) * Environment)
2579 :     -> Picture list -> (GraphicsContext -> string) * Environment
2580 :     - val seqlist = mkseqlist (op seq);
2581 :     val seqlist = fn : Picture list -> (GraphicsContext -> string) *
2582 :     Environment
2583 :     - draw (seqlist [text "a"]) "test";
2584 :     1.0, 0.0(1.0, 1.0)(0.0, 0.0)val it = () : unit
2585 :     -
2586 :    
2587 :     Comments: I'm not sure if this is really a bug, but it seems to me
2588 :     that adding type declarations is not supposed to matter.
2589 :     And it's a heck of a difficult error to track down.
2590 :     Fix:
2591 :     Test: ?
2592 :     Owner: Zhong
2593 :     Status: fixed in 109.30
2594 :     ----------------------------------------------------------------------
2595 :     Number: 1236
2596 :     Title: TextIO.outputSubstr doesn't work on substrings containing \n
2597 :     Keywords: IO, TextIO, outputSubstr
2598 :     Submitter: Konrad.Slind@cl.cam.ac.uk
2599 :     Date: 7/23/97
2600 :     Version: 109.30
2601 :     System: sparc/solaris 2.5.5
2602 :     Severity: major
2603 :     Problem:
2604 :     TextIO.outputSubstr doesn't seem to handle substrings with "\n" in
2605 :     them. For example:
2606 :    
2607 :     - TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n"));
2608 :     val it = () : unit
2609 :    
2610 :     This behaviour contradicts the description in the basis documentation.
2611 :    
2612 :     Code:
2613 :     TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n"));
2614 :     Comments:
2615 :     Fix:
2616 :     Test: bug1236.sml
2617 :     Owner: jhr, erg
2618 :     Status: fixed in 109.32 [jhr, 7/24/97]
2619 :     ----------------------------------------------------------------------
2620 :     Number: 1237
2621 :     Title: ml-yacc doesn't handle constructors with long names
2622 :     Keywords: ml-yacc, constructor names
2623 :     Submitter: Konrad.Slind@cl.cam.ac.uk
2624 :     Date: 7/23/97
2625 :     Version: 109.30
2626 :     System: -
2627 :     Severity: major
2628 :     Problem:
2629 :     ml-yacc emits bogus string literals from constructors with long
2630 :     names. The following input will generate a file where, on about line
2631 :     104, a mangled string literal is produced.
2632 :     Code:
2633 :     %%
2634 :     %term I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild
2635 :     | EOLEX
2636 :     | EOF
2637 :    
2638 :     %nonterm START of unit
2639 :    
2640 :     %start START
2641 :     %eop EOF EOLEX
2642 :     %pos int
2643 :     %header (functor ELrValsFun (structure Token : TOKEN))
2644 :     %name E
2645 :     %noshift EOF
2646 :     %pure
2647 :     %%
2648 :    
2649 :     START : I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild()
2650 :     Transcript:
2651 :     Comments:
2652 :     Fix:
2653 :     Test:
2654 :     Owner: appel
2655 :     Status: fixed in 109.32
2656 :     ----------------------------------------------------------------------
2657 :     Number: 1238
2658 :     Title: Elaboration error involving where structure
2659 :     Keywords: where structure
2660 :     Submitter: Perry Cheng (pscheng@cs.cmu.edu)
2661 :     Date: 7/23/97
2662 :     Version: 109.30
2663 :     System: Digital Unix 4.0
2664 :     Severity: major
2665 :     Problem: Where structure construct causes strange error message.
2666 :     Code:
2667 :     signature MA =
2668 :     sig
2669 :     type t
2670 :     end;
2671 :    
2672 :     signature MU =
2673 :     sig
2674 :     structure M : MA
2675 :     end;
2676 :    
2677 :     signature DA =
2678 :     sig
2679 :     type t
2680 :     end;
2681 :    
2682 :     (* ------------ this one works ---------------------- *)
2683 :     functor Good(structure D : DA
2684 :     structure Mu : MU
2685 :     where type M.t = D.t)
2686 :     = struct end;
2687 :    
2688 :     (* ------------ this one fails ---------------------- *)
2689 :     functor Bad(structure D : DA
2690 :     structure Mu : MU where M = D)
2691 :     = struct end;
2692 :    
2693 :     Transcript:
2694 :     - use "bug1238.sml";
2695 :     [opening bug1238.sml]
2696 :     signature MA =
2697 :     sig type t end
2698 :     signature MU =
2699 :     sig structure M : sig type t end end
2700 :     signature DA =
2701 :     sig type t end
2702 :     functor Good : <sig>
2703 :    
2704 :     uncaught exception Unbound
2705 :     raised at: elaborate/elabmod.sml:1164.39-1164.49
2706 :     util/stats.sml:164.40
2707 :     build/evalloop.sml:120.38
2708 :     build/evalloop.sml:193.58
2709 :     build/evalloop.sml:285.46-285.49
2710 :    
2711 :     Comments:
2712 :     Minor modification to the code will make the bug go away.
2713 :     This bug is related to bug 1232.
2714 :     On a related note, sometime a functor definition that involves
2715 :     "where structure" generates a functor which, when instantiated,
2716 :     gives the same error message even though the code is correct.
2717 :    
2718 :     [dbm, 7/23/97]
2719 :     If DA is replaced by MA in Bad, the code compiles ok. So the problem
2720 :     is caused by the difference in signatures (DA vs MA).
2721 :     Fix:
2722 :     Modified entityInfo datatype in Instantiate so that GENERATE_ENT
2723 :     carries a boolean value indicating whether there was a VARstrDef
2724 :     with signature that does not agree with the spec.
2725 :     Test: bug1238.sml
2726 :     Owner: dbm
2727 :     Status: fixed in 109.31 [dbm, 8/13/97]
2728 :     ----------------------------------------------------------------------
2729 :     Number: 1239
2730 :     Title: Subscript-out-of-bounds error when opening a structure
2731 :     Keywords: pretty printing, compiler
2732 :     Submitter: Jon Riecke, riecke@bell-labs.com
2733 :     Date: 07/25/97
2734 :     Version: 109.30
2735 :     System: Linux and Irix
2736 :     Severity: major
2737 :     Problem:
2738 :     When opening the CML structure, a "subscript out of bounds" exn is raised.
2739 :     Code: CML standard library
2740 :     Transcript:
2741 :     - open CML;
2742 :     GC #0.0.0.1.3.57: (43 ms)
2743 :     open CML
2744 :     val version = {date="June 11, 1997",system="Concurrent ML",version_id=[1,0,7]}
2745 :     : {date:string, system:string, version_id:int list}
2746 :     val banner = "Concurrent ML, Version 1.0.7, June 11, 1997" : string
2747 :     val getTid = fn : unit -> thread_id
2748 :     val sameTid = fn : thread_id * thread_id -> bool
2749 :     val compareTid = fn : thread_id * thread_id -> order
2750 :     val hashTid = fn : thread_id -> word
2751 :     val tidToString = fn : thread_id -> string
2752 :     val spawnc = fn : ('a -> unit) -> 'a -> thread_id
2753 :     val spawn = fn : (unit -> unit) -> thread_id
2754 :     val exit = fn : unit -> 'a
2755 :     val joinEvt = fn : thread_id -> unit event
2756 :     val yield = fn : unit -> unit
2757 :     val channel = fn : unit -> 'a chan
2758 :     val sameChannel = fn : 'a chan * 'a chan -> bool
2759 :     val send = fn : 'a chan * 'a -> unit
2760 :     val recv = fn : 'a chan -> 'a
2761 :     val sendEvt = fn : 'a chan * 'a -> unit event
2762 :     val recvEvt = fn : 'a chan -> 'a event
2763 :     val sendPoll = fn : 'a chan * 'a -> bool
2764 :     val recvPoll = fn : 'a chan -> 'a option
2765 :    
2766 :     uncaught exception in compiler: subscript out of bounds
2767 :     raised at: print/ppobj.sml:89.24-89.29
2768 :     print/ppobj.sml:349.20
2769 :     print/ppobj.sml:349.20
2770 :     print/ppobj.sml:349.20
2771 :     util/pp.sml:545.6
2772 :     build/evalloop.sml:193.58
2773 :    
2774 :     Comments:
2775 :     [jhr, 7/30/97]
2776 :     Appears to be the same as bug 1241, which is fixed in 109.31.
2777 :     Fix:
2778 :     Test: *
2779 :     Owner: Zhong
2780 :     Status: fixed in 109.31 [Zhong, 7/29/97]
2781 :     ----------------------------------------------------------------------
2782 :     Number: 1240
2783 :     Title: Can't form pairs of reals
2784 :     Keywords: reals
2785 :     Submitter: Sam Kamin, kamin@cs.uiuc.edu
2786 :     Date: 7/25/97
2787 :     Version: 109.30
2788 :     System: sparc-solaris
2789 :     Severity: Critical
2790 :     Problem: Attempt to create tuples containing only real numbers
2791 :     results in "uncaught exception in compiler: Representation"
2792 :     Code: (0.0,0.0)
2793 :     Transcript: Here are a couple of more examples:
2794 :    
2795 :     - (0.0, 0.0);
2796 :    
2797 :     uncaught exception in compiler: Representation
2798 :     raised at: boot/Unsafe/object.sml:58.19-58.33
2799 :     print/ppobj.sml:349.20
2800 :     print/ppobj.sml:349.20
2801 :     util/pp.sml:545.6
2802 :     build/evalloop.sml:193.58
2803 :     - (real 0, real 0);
2804 :    
2805 :     uncaught exception in compiler: Representation
2806 :     raised at: boot/Unsafe/object.sml:58.19-58.33
2807 :     print/ppobj.sml:349.20
2808 :     print/ppobj.sml:349.20
2809 :     util/pp.sml:545.6
2810 :     build/evalloop.sml:193.58
2811 :     - ((fn x => (x,x)) 0.0);
2812 :    
2813 :     uncaught exception in compiler: Representation
2814 :     raised at: boot/Unsafe/object.sml:58.19-58.33
2815 :     print/ppobj.sml:349.20
2816 :     print/ppobj.sml:349.20
2817 :     util/pp.sml:545.6
2818 :     build/evalloop.sml:193.58
2819 :    
2820 :     - (0.0, 0);
2821 :     val it = (0.0,0) : real * int
2822 :     - (0.0, "abc");
2823 :     val it = (0.0,"abc") : real * string
2824 :    
2825 :    
2826 :     Comments:
2827 :     Fix:
2828 :     Test: bug1240.sml
2829 :     Owner: jhr, Zhong
2830 :     Status: fixed in 109.31 [jhr, 7/28/97]
2831 :     ----------------------------------------------------------------------
2832 :     Number: 1241
2833 :     Title: confused datatype constructors
2834 :     Keywords: datatype
2835 :     Submitter: Elsa L. Gunter, elsa@research.bell-labs.com
2836 :     Date: July 25, 1997
2837 :     Version: 109.30
2838 :     System: x86 - linux 2.0
2839 :     Severity: critical
2840 :     Problem: In a datatype with two constructors, the constructors get
2841 :     swapped
2842 :     Code:
2843 :    
2844 :     datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1;
2845 :    
2846 :     datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0;
2847 :    
2848 :     norfolk% sml
2849 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
2850 :     - datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1;
2851 :     datatype 'a t1 = A1 | B1 of 'a list
2852 :     val i1 = B1 [] : 'a t1
2853 :     - datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0;
2854 :     datatype 'a t2 = A2 of int | B2 of 'a list
2855 :    
2856 :     uncaught exception in compiler: subscript out of bounds
2857 :     raised at: print/ppobj.sml:89.24-89.29
2858 :     print/ppobj.sml:349.20
2859 :     print/ppobj.sml:349.20
2860 :     util/pp.sml:545.6
2861 :     build/evalloop.sml:193.58
2862 :     -
2863 :     Comments: Notice that in the first datatype declaration, I assign, i1
2864 :     to be A1, but it gives me back that it is B1 []. In the second case,
2865 :     it raises an exception (I think because it is trying to apply B2 [] to
2866 :     0.).
2867 :    
2868 :     Fix: change to ppobj.sml
2869 :     Test: bug1241.sml
2870 :     Owner: Zhong
2871 :     Status: fixed in 109.31 [Zhong]
2872 :     ----------------------------------------------------------------------
2873 :     Number: 1242
2874 :     Title: error recovery in open could be better
2875 :     Keywords: open error recovery
2876 :     Submitter: manuel@cs.berkeley.edu
2877 :     Date: July 29/97
2878 :     Version: 109.29
2879 :     System: all
2880 :     Severity: low
2881 :     Problem: If one structure is undefined in an open declarations with
2882 :     multiple structures, the non-constant constructors made visible from
2883 :     opening preceding structures are not bound. Results in weird spurious
2884 :     error messages.
2885 :    
2886 :     Code:
2887 :     structure A =
2888 :     struct
2889 :     datatype at = A | B | C of int
2890 :     end
2891 :    
2892 :     local
2893 :     open A Foo
2894 :     in
2895 :     fun toString A = "A"
2896 :     | toString B = "B"
2897 :     | toString (C i) = "C " ^ Int.toString i
2898 :     end
2899 :    
2900 :     Transcript:
2901 :     - [opening /tmp/mla003Cy]
2902 :     /tmp/mla003Cy:7.5-7.15 Error: unbound structure: Foo
2903 :     /tmp/mla003Cy:9.9-11.47 Error: non-constructor applied to argument in pattern: C
2904 :    
2905 :     uncaught exception Error
2906 :     raised at: build/evalloop.sml:103.44-103.52
2907 :     build/evalloop.sml:120.38
2908 :     build/evalloop.sml:192.58
2909 :     build/evalloop.sml:284.46-284.49
2910 :     -
2911 :    
2912 :     Comments:
2913 :     The C constructor isn't visible, even though A and B
2914 :     are. Removing the Foo structure from the open declaration
2915 :     makes the second error disappear.
2916 :     [dbm, 7/29/97]
2917 :     The reason there is no error message complaining about A and B
2918 :     in the first two clauses of toString is that since these are not
2919 :     bound as constructors they are interpreted as variables.
2920 :    
2921 :     It should be possible to have the open take effect on the structures
2922 :     that are defined, which would cut down on secondary errors like
2923 :     this one.
2924 :     [manuel, 7/29/97]
2925 :     Yes, you are right about the constant constructors. I didn't think of
2926 :     that. But what is strange is that only constructors seem to be missing
2927 :     from the environment. Value bindings are visible in the same context.
2928 :     Fix:
2929 :     Test: bug1242.sml
2930 :     Owner: dbm
2931 :     Status: open
2932 :     ----------------------------------------------------------------------
2933 :     Number: 1243
2934 :     Title: Application of functor to different representations
2935 :     Keywords: functor application, polymorphism, representation analysis
2936 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
2937 :     Date: 7/28/97
2938 :     Version: 109.30
2939 :     System: x86-linux
2940 :     Severity: major
2941 :     Problem: compiler bug tickled by application of functor
2942 :     to two different polymorphic representations
2943 :     Code:
2944 :    
2945 :     local
2946 :     functor Foo(type 'a t
2947 :     val destruct : 'a t -> ('a * 'a t) option) =
2948 :     struct
2949 :     fun first s =
2950 :     case destruct s of
2951 :     SOME(x,_) => x
2952 :     end
2953 :    
2954 :     structure Foo1 =
2955 :     Foo(type 'a t = 'a list
2956 :     fun destruct _ = let exception E in raise E end)
2957 :    
2958 :     structure Foo2 =
2959 :     Foo(datatype 'a t = T of ('a * 'a t) option
2960 :     fun destruct _ = let exception E in raise E end)
2961 :    
2962 :     in
2963 :     val _ = 13
2964 :     end
2965 :    
2966 :     Transcript:
2967 :    
2968 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
2969 :    
2970 :     stdIn:36.6-37.23 Warning: match nonexhaustive
2971 :     SOME (x,_) => ...
2972 :    
2973 :     for the type:
2974 :     I
2975 :     Error: Compiler bug: LambdaType: unexpected case in tcd_arw
2976 :     -
2977 :    
2978 :     Comments:
2979 :     Fix: change to translate/specialize.sml
2980 :     Test: bug1243.sml
2981 :     Owner: Zhong
2982 :     Status: fixed in 109.31 [Zhong, 7/29/97]
2983 :     ----------------------------------------------------------------------
2984 :     Number: 1244
2985 :     Title: Explicitly scoped type variable with 'val ... and' declaration
2986 :     Keywords: translate, lambda types
2987 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
2988 :     Date: 8/1/97
2989 :     Version: 109.30, 109.30+
2990 :     System: x86-linux
2991 :     Severity: minor
2992 :     Problem: Compiler bug caused by use of an explicitly scoped type
2993 :     variable in multiple val declarations.
2994 :     Code:
2995 :    
2996 :     val 'a f = fn x : 'a => x
2997 :     and g = fn y : 'a => y
2998 :    
2999 :     Transcript:
3000 :    
3001 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3002 :     - val 'a f = fn x : 'a => x
3003 :     and g = fn y : 'a => y
3004 :     = = ;
3005 :     Error: Compiler bug: Translate: unexpected tyvar INSTANTIATED in mkPE
3006 :     -
3007 :    
3008 :     Comments:
3009 :     Fix:
3010 :     Test: bug1244.sml
3011 :     Owner: Zhong, dbm
3012 :     Status: fixed in 109.31
3013 :     ----------------------------------------------------------------------
3014 :     Number: 1245
3015 :     Title: Pretty printer bug
3016 :     Keywords:
3017 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3018 :     Date: 8/4/97
3019 :     Version: 109.30
3020 :     System: x86-linux
3021 :     Severity: minor
3022 :     Problem: Error raised when attempting to print the binding of a
3023 :     pair of empty lists in the REPL.
3024 :    
3025 :     Code: val (x,y) = ([],[])
3026 :    
3027 :     Transcript:
3028 :    
3029 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3030 :     val it = () : unit
3031 :     - val (x,y) = ([],[]);
3032 :    
3033 :     uncaught exception in compiler: subscript out of bounds
3034 :     raised at: print/ppobj.sml:422.28-422.33
3035 :     print/ppobj.sml:349.20
3036 :     print/ppobj.sml:349.20
3037 :     util/pp.sml:545.6
3038 :     build/evalloop.sml:193.58
3039 :     -
3040 :     Comments:
3041 :     Fix:
3042 :     Test: bug1245.sml
3043 :     Owner: Zhong
3044 :     Status: fixed in 109.31
3045 :     ----------------------------------------------------------------------
3046 :     Number: 1246
3047 :     Title: Explicit scoping of type variables does not obey the standard.
3048 :     Keywords: explicity scoped type variable
3049 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3050 :     Date: 8/4/97
3051 :     Version: 109.30
3052 :     System: x86-linux
3053 :     Severity: minor
3054 :     Problem:
3055 :    
3056 :     The following definition does not typecheck.
3057 :    
3058 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3059 :     fn z => z:'a)
3060 :    
3061 :     The following definition does typecheck.
3062 :    
3063 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3064 :     fn z => z:'b)
3065 :    
3066 :     I believe that, according to the standard, they both should typecheck.
3067 :     It appears that the first example is failing because the typechecker
3068 :     is changing the scope of the explicitly scoped 'a, whereas the
3069 :     standard only specifies how to determine the scope of implicitly
3070 :     scoped type variables -- the scope of explicitly scoped type variables
3071 :     should not change. As the second example demonstrates, the problem
3072 :     appears to occur because a bound type variable happens to have the
3073 :     same name as a free type variable.
3074 :    
3075 :     Code:
3076 :    
3077 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3078 :     fn z => z:'a)
3079 :     fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3080 :     fn z => z:'b)
3081 :    
3082 :     Transcript:
3083 :    
3084 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3085 :     val it = () : unit
3086 :     - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3087 :     fn z => z:'a);
3088 :     = stdIn:13.12-13.60 Error: operator and operand don't agree [UBOUND match]
3089 :     operator domain: 'a
3090 :     operand: 'a -> 'a
3091 :     in expression:
3092 :     id id
3093 :     - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end,
3094 :     fn z => z:'b);
3095 :     = val f = fn : unit -> ('a -> 'a) * ('b -> 'b)
3096 :     -
3097 :    
3098 :     Another example from Andrew Tolmach [8/18/97]
3099 :    
3100 :     - val 'a f = fn (x:'a) => let val 'a g = fn (y:'a) => (y,y) in g (x,x) end;
3101 :     stdIn:15.25-15.73 Error: operator and operand don't agree [UBOUND match]
3102 :     operator domain: 'a
3103 :     operand: 'a * 'a
3104 :     in expression:
3105 :     g (x,x)
3106 :    
3107 :     Comments:
3108 :     [Andrew Kennedy, 3/20/98]
3109 :     I have a small query concerning explicit type variables: the final
3110 :     syntactic restriction listed in Section 2.9 (page 9) of the Definition
3111 :     seems unnecessary and isn't enforced by SML/NJ. Was it a mistake? In
3112 :     particular, the Tolmach example cited on your bug list
3113 :    
3114 :     val 'a f = fn (x:'a) =>
3115 :     let val 'a g = fn (y:'a) => (y,y) in g (x,x)
3116 :     end
3117 :    
3118 :     would appear (to me) not to obey this restriction, and yet is perfectly
3119 :     sensible if val 'a is essentially `big lambda'. Surely a desirable
3120 :     property of the SML is that a declaration such as
3121 :    
3122 :     val 'a id = fn x : 'a => x
3123 :    
3124 :     can be plugged into an arbitrary program context without breaking any
3125 :     restrictions.
3126 :    
3127 :    
3128 :     Fix: in elabcore.sml, revised calculations of updt in the presence of
3129 :     etvs (explicitly bound type variables) to avoid inappropriate instantiations
3130 :     of explicit variables.
3131 :     Test: bug1246.sml, bug1246.1.sml
3132 :     Owner: dbm
3133 :     Status: fixed in 109.31 [dbm, 9/4/97]
3134 :     ----------------------------------------------------------------------
3135 :     Number: 1247
3136 :     Title: IntSet library module is wrong
3137 :     Keywords: smlnj-lib, IntSet, ListSet
3138 :     Submitter: Andrew Kennedy <andrew@persimmon.co.uk>
3139 :     Date: 8/4/97
3140 :     Version: 109.30
3141 :     System: -
3142 :     Severity: major
3143 :     Problem:
3144 :     A while back I reported some bugs in the ListSet functor. They were
3145 :     fixed but unfortunately the fix doesn't appear to have been applied to
3146 :     the IntSet specialised version. (Just compare the source files: they're
3147 :     are some missing primes on variable names in some functions).
3148 :     Comments:
3149 :     Fix:
3150 :     Test: ?
3151 :     Owner: jhr, Emden
3152 :     Status: Fixed in 109.31
3153 :     ----------------------------------------------------------------------
3154 :     Number: 1248
3155 :     Title: blastWrite failures
3156 :     Keywords: blastRead, blastWrite
3157 :     Submitter: Chris Paris <cap@cmu.edu>
3158 :     Date: 8/5/97
3159 :     Version: 109.30
3160 :     System: ?
3161 :     Severity: major
3162 :     Problem: blastwrite fails catastrophically
3163 :     Code:
3164 :     Transcript:
3165 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3166 :     val it = () : unit
3167 :     - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);val blastWrite = fn : 'a -> Word8Vector.vector
3168 :     - blastWrite (Word8Array.array (516000, 0w0));
3169 :     GC #0.0.0.0.1.4: (0 ms)
3170 :     GC #0.0.0.0.2.6: (10 ms)
3171 :     val it = - : Word8Vector.vector
3172 :     - blastWrite (Word8Array.array (516001, 0w0));
3173 :     GC #0.0.0.1.3.7: (0 ms)
3174 :     GC #0.0.0.1.4.8: (0 ms)
3175 :     ./sml: Fatal error -- blasting out of 516096 bytes not supported yet! Increase allocation arena size.
3176 :    
3177 :     But perhaps blasting one large atomic object presents a problem that
3178 :     blasting a collection of small objects wouldn't, so here's another
3179 :     example.
3180 :    
3181 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3182 :     val it = () : unit
3183 :     - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);
3184 :     val blastWrite = fn : 'a -> Word8Vector.vector
3185 :     - fun iter 0 = []
3186 :     = | iter n = n :: (iter (n-1));
3187 :     val iter = fn : int -> int list
3188 :     - blastWrite (iter 10);
3189 :     val it = - : Word8Vector.vector
3190 :     - blastWrite (iter 100);
3191 :     val it = - : Word8Vector.vector
3192 :     - blastWrite (iter 1000);
3193 :     val it = - : Word8Vector.vector
3194 :     - blastWrite (iter 10000);
3195 :     GC #0.0.0.0.1.13: (20 ms)
3196 :     val it = - : Word8Vector.vector
3197 :     - blastWrite (iter 100000);
3198 :     GC #0.0.0.1.2.16: (110 ms)
3199 :     GC #0.0.0.2.3.17: (140 ms)
3200 :     Segmentation fault
3201 :    
3202 :     Comments:
3203 :     [Chris Paris, 8/5/97]
3204 :     In last night's message, I meant to make another comment about
3205 :     blastWrite but forgot. I find it limiting that the size of the object
3206 :     blastWrite can handle is limited by the allocation arena size. I'm
3207 :     already running with a doubled allocation arena size to accomodate our
3208 :     growing data, but I understand that I can't just keep increasing it
3209 :     indefinitely and expect to retain reasonable performance. The end of
3210 :     blast-out.c mentions allocating space in the big-object arena as an
3211 :     alternative implementation. I'm wondering if this would be an easy
3212 :     change to make that hasn't been done simply due to lack of demand, or
3213 :     whether there are difficult issues to overcome in order to remove the
3214 :     current limitation.
3215 :     Fix:
3216 :     Test: bug1248.1.sml, bug1248.2.sml
3217 :     Owner: jhr
3218 :     Status: fixed in 109.31 [jhr, 8/12/97]
3219 :     ----------------------------------------------------------------------
3220 :     Number: 1249
3221 :     Title: Time.time type too small
3222 :     Keywords: Time.time
3223 :     Submitter: Chris Paris <cap@cmu.edu>
3224 :     Date: 8/5/97
3225 :     Version: 109.30
3226 :     System: -
3227 :     Severity: minor
3228 :     Problem:
3229 :     The project I'm working on uses the Time.time type for some
3230 :     things. Today we ran into some data that required 32 bits in the sec
3231 :     field. We had to write our own time type to handle this. I'm not
3232 :     saying the system Time type should definitely be changed, but I
3233 :     thought you'd like to know that someone needed more than 31 bits
3234 :     there.
3235 :     Comments:
3236 :     The SML Basis now specifies a LargeInt.int representation for
3237 :     the seconds field. -- jhr
3238 :     Fix:
3239 :     Test:
3240 :     Owner: jhr?
3241 :     Status: Fixed in 109.31 [jhr, 7/31/97]
3242 :     ----------------------------------------------------------------------
3243 :     Number: 1250
3244 :     Title: Bind exception delayed by polymorphic generalization
3245 :     Keywords: Bind exception
3246 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3247 :     Date: 8/5/97
3248 :     Version: 109.30
3249 :     System: x86-linux
3250 :     Severity: minor
3251 :     Problem: A Bind exception is not raised in a value declaration
3252 :     when the variable being defined is polymorphically
3253 :     generalized. I suspect that the raise is getting wrapped
3254 :     in a _/\_ in the translation into the typed IL.
3255 :     The exception is raised later if the polymorphic value
3256 :     is applied.
3257 :    
3258 :     Code: datatype 'a foo = Foo1 of 'a | Foo2 of 'a
3259 :     val Foo1 f = Foo2(fn x => x);
3260 :     f 13;
3261 :     Transcript:
3262 :    
3263 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3264 :     - datatype 'a foo = Foo1 of 'a | Foo2 of 'a
3265 :     val Foo1 f = Foo2(fn x => x);
3266 :     = stdIn:<nullRegion> Warning: binding not exhaustive
3267 :     Foo1 f = ...
3268 :     datatype 'a foo = Foo1 of 'a | Foo2 of 'a
3269 :     val f = fn : 'a -> 'a
3270 :     - f 13;
3271 :    
3272 :     uncaught exception Bind [nonexhaustive binding failure]
3273 :     raised at: stdIn:<nullRegion>
3274 :    
3275 :     Comments:
3276 :     [Zhong, 8/5/97]
3277 :     Thanks for the bug report. This bug is actually related to the
3278 :     pretty-printing. As you observed, binding f to _/\_ does not
3279 :     raise the exception; the exception should be raised when
3280 :     printing f in the top-level (however, the pretty-printing in
3281 :     109.30 was broken, so the exception is not raised).
3282 :    
3283 :     Our fixes for the other pretty-printing bugs (which have been
3284 :     incorporated into 109.31) should correctly raise the exception,
3285 :     however, the exception name is not printed out correctly still.
3286 :     Fix:
3287 :     Test: bug1250.sml
3288 :     Owner: Zhong
3289 :     Status: Fixed in 109.31 [Zhong]
3290 :     ----------------------------------------------------------------------
3291 :     Number: 1251
3292 :     Title: where specs cause exception Unbound
3293 :     Keywords: where Unbound
3294 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3295 :     Date: 8/6/97
3296 :     Version: 109.30
3297 :     System: x86-linux
3298 :     Severity: minor
3299 :     Problem: The use of a where spec can cause exception Unbound to be
3300 :     raised by the elaborator.
3301 :     Code:
3302 :    
3303 :     structure S : sig
3304 :     structure A : sig end
3305 :     structure B : sig structure C : sig end end where C = A
3306 :     end =
3307 :     struct
3308 :     structure A = struct end
3309 :     structure B = struct structure C = A end
3310 :     end
3311 :    
3312 :     Transcript:
3313 :    
3314 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3315 :     - structure S : sig
3316 :     structure A : sig end
3317 :     structure B : sig structure C : sig end end where C = A
3318 :     end =
3319 :     struct
3320 :     structure A = struct end
3321 :     structure B = struct structure C = A end
3322 :     end;
3323 :    
3324 :    
3325 :     uncaught exception in compiler: Unbound
3326 :     raised at: elaborate/elabmod.sml:1050.15-1050.25
3327 :     util/stats.sml:164.40
3328 :     build/evalloop.sml:120.38
3329 :     build/evalloop.sml:193.58
3330 :    
3331 :     Comments:
3332 :     [Zhong, 8/6/97]
3333 :     Thanks for the bug report. I encountered this same bug while
3334 :     trying to fix bug 1205. It happens only if the righthand side
3335 :     of the where clause is a "flexible" structure (i.e., locally
3336 :     defined structure). Dave and I will try to get a fix into 109.31.
3337 :     Fix: change strEntEnv to entEnv around line 545 of sigmatch.sml
3338 :     Test: bug1251.sml
3339 :     Owner: Zhong, dbm
3340 :     Status: fixed in 109.31 [Zhong, dbm]
3341 :     ----------------------------------------------------------------------
3342 :     Number: 1252
3343 :     Title: Unbound exception on functor application
3344 :     Keywords: modules, functors
3345 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3346 :     Date: 8/6/97
3347 :     Version: 109.30
3348 :     System: x86-linux
3349 :     Severity: minor
3350 :     Problem: A compiler bug is raised on the following code.
3351 :    
3352 :     Code:
3353 :    
3354 :     functor F(type t) =
3355 :     let structure S : sig
3356 :     type v
3357 :     val x : v
3358 :     end =
3359 :     struct
3360 :     datatype 'a u = U of (t * 'a) list
3361 :     type v = t u
3362 :     val x = U[]
3363 :     end
3364 :     in struct
3365 :     datatype t = T of S.v
3366 :     val x = T S.x
3367 :     end
3368 :     end;
3369 :    
3370 :     structure S = F(type t = int);
3371 :    
3372 :     Transcript:
3373 :    
3374 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3375 :     - functor F(type t) =
3376 :     let structure S : sig
3377 :     type v
3378 :     val x : v
3379 :     end =
3380 :     struct
3381 :     datatype 'a u = U of (t * 'a) list
3382 :     type v = t u
3383 :     val x = U[]
3384 :     end
3385 :     in struct
3386 :     datatype t = T of S.v
3387 :     val x = T S.x
3388 :     end
3389 :     end;
3390 :    
3391 :     - structure S = F(type t = int);
3392 :     functor F : <sig>
3393 :     Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
3394 :    
3395 :     [dbm: In 109.31-, the behavior is different. Unbound (EE.Unbound?) is
3396 :     raised instead: ]
3397 :    
3398 :     - use "test/bugs/bug1252.sml";
3399 :     [opening test/bugs/bug1252.sml]
3400 :     functor F : <sig>
3401 :    
3402 :     uncaught exception Unbound
3403 :     raised at: elaborate/elabmod.sml:1060.15-1060.25
3404 :     util/stats.sml:164.40
3405 :     build/evalloop.sml:123.38
3406 :     build/evalloop.sml:196.58
3407 :     build/evalloop.sml:289.46-289.49
3408 :    
3409 :     Comments:
3410 :     [Zhong]
3411 :     This seems to be the same as bug 1234.
3412 :     Fix:
3413 :     Test: bug1252.sml, bug1252.1.sml
3414 :     Owner: Zhong, dbm
3415 :     Status: Fixed in 109.31 [Zhong]
3416 :     ----------------------------------------------------------------------
3417 :     Number: 1253
3418 :     Title: pretty printing nested polymorphic records
3419 :     Keywords: pretty printing, representations
3420 :     Submitter: Chris Page <cap@cmu.edu>
3421 :     Date: 8/6/97
3422 :     Version: 109.30
3423 :     System: -
3424 :     Severity: major
3425 :     Problem:
3426 :     The code in the printer that tries to avoid printing
3427 :     polymorphic records doesn't work when the record is wrapped in another
3428 :     (non-record) type.
3429 :     Transcript:
3430 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
3431 :     val it = () : unit
3432 :     - (NONE, ());
3433 :     val it = <poly-record> : 'a option * unit
3434 :     - SOME (NONE, ());
3435 :    
3436 :     uncaught exception in compiler: Representation
3437 :    
3438 :     Comments:
3439 :     [Zhong, 4/4/98]
3440 :     By the way, in 110.4, I have fixed the pretty printing of poly record.
3441 :     So typing things such as:
3442 :    
3443 :     val x = (nil, nil)
3444 :    
3445 :     or
3446 :    
3447 :     val x = (nil, 3)
3448 :    
3449 :     will print the expected values rather than <poly-record>.
3450 :    
3451 :     Fix:
3452 :     Test: bug1253.sml
3453 :     Owner: Zhong
3454 :     Status: fixed in 109.31
3455 :     ----------------------------------------------------------------------
3456 :     Number: 1254
3457 :     Title: Disagreements between SML/NJ and Defn: datatype replication
3458 :     Keywords: datatype replication
3459 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3460 :     Date: 8/11/97
3461 :     Version: 109.30
3462 :     System: x86-linux
3463 :     Severity: minor
3464 :     Problem:
3465 :     (1) I believe that the Standard says that the following
3466 :     program is legal, and should make 's' an abbreviation for
3467 :     'int'. However, SML/NJ responds with "Error: rhs of
3468 :     datatype replication not a datatype".
3469 :    
3470 :     type t = int
3471 :     datatype s = datatype t
3472 :    
3473 :     SML/NJ and the Standard both accept the following program,
3474 :     but I believe they do so for different reasons.
3475 :    
3476 :     (2)
3477 :     structure S : sig type t end =
3478 :     struct
3479 :     datatype t = T
3480 :     end
3481 :    
3482 :     datatype u = datatype S.t
3483 :    
3484 :     After the above program is entered, I believe that the
3485 :     Standard says that the following declaration is illegal,
3486 :     whereas SML/NJ accepts it.
3487 :    
3488 :     val x = T
3489 :    
3490 :     My reading of the Standard is that the signature
3491 :     constraint on 'S' should hide the constructors associated
3492 :     with type 't' and that the declaration of 'u' should
3493 :     declare 'u' as an abbreviation of 't', but not be able to
3494 :     access t's constructors, since they were hidden by the
3495 :     signature.
3496 :    
3497 :     Comments:
3498 :     [dbm, 8/14/97]
3499 :     Part (1) is considered an omission in the Definition.
3500 :     Part (2) is a bug because of rule (80), which says that
3501 :     the constructor environment component of t is stipped out
3502 :     by signature matching. This should really cause the
3503 :     subsequent datatype replication declaration
3504 :    
3505 :     datatype u = datatype S.t
3506 :    
3507 :     to fail, because there is no constructor environment for
3508 :     u to inherit from S.t, and a datatype without a constructor
3509 :     environment is not a proper datatype.
3510 :     Fix:
3511 :     Test: bug1254.sml
3512 :     Owner: dbm
3513 :     Status: open (2)
3514 :     ----------------------------------------------------------------------
3515 :     Number: 1255
3516 :     Title: Disagreements between SML/NJ and Defn: datatype replication, part II
3517 :     Keywords: datatype replication
3518 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3519 :     Date: 8/11/97
3520 :     Version: 109.30
3521 :     System: x86-linux
3522 :     Severity: minor
3523 :     Problem: I believe that the following code is legal, according
3524 :     to the Standard. However, SML/NJ rejects it, responding
3525 :     with:
3526 :    
3527 :     Error: value type in structure doesn't match signature spec
3528 :     name: U
3529 :     spec: ?.t -> ?.Foo.u
3530 :     actual: ?.int -> ?.Foo.u
3531 :    
3532 :     Code:
3533 :     structure Foo : sig
3534 :     type t
3535 :     datatype u = U of t
3536 :     structure Goo :
3537 :     sig
3538 :     datatype v = datatype u
3539 :     end
3540 :     end =
3541 :     struct
3542 :     type t = int
3543 :     datatype u = U of t
3544 :     structure Goo =
3545 :     struct
3546 :     datatype v = datatype u
3547 :     end
3548 :     end
3549 :    
3550 :     Transcript:
3551 :     Comments:
3552 :     Fix:
3553 :     Modified PATHtyc case of expandTyc in elabDATArepl in elabsig.sml.
3554 :     Check if entPath is external, in which case nothing needs to be
3555 :     done. Otherwise, if PATHtyc is internal to current signature, adjust
3556 :     it by adding appending prefix.
3557 :     Test: bug1255.sml
3558 :     Owner: dbm
3559 :     Status: fixed in 109.31 [dbm, 7/15/97]
3560 :     ----------------------------------------------------------------------
3561 :     Number: 1256
3562 :     Title: Free type variables in local datatype declarations.
3563 :     Keywords: datatype type variable
3564 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3565 :     Date: 8/11/97
3566 :     Version: 109.30
3567 :     System: x86-linux
3568 :     Severity: minor
3569 :     Problem: In a local datatype declarations, SML/NJ does not accept
3570 :     constructors whose types contain type variables that are not
3571 :     bound in the datatype declaration (even if they are bound
3572 :     in the enclosing program). For example, I believe that
3573 :     the Standard says that following program should be
3574 :     accepted. SML/NJ responds with "Error: unbound type
3575 :     variable in type declaration: 'a".
3576 :    
3577 :     Code:
3578 :     fun 'a f (x : 'a) =
3579 :     let datatype foo = Foo of 'a * int
3580 :     in 13
3581 :     end
3582 :     Transcript:
3583 :     Comments:
3584 :     [dbm, 8/13/97]
3585 :     This may technically be accepted under the definition, but this is
3586 :     an oversight or error in the definition. For various reasons, if
3587 :     a polymorphically bound type variable could participate in type
3588 :     definitions as in your example, there would be serious implementation
3589 :     complications for very little gain in utility. I don't plan to "fix"
3590 :     this bug in SML/NJ.
3591 :     Fix:
3592 :     Test: *
3593 :     Owner: dbm
3594 :     Status: not a bug
3595 :     ----------------------------------------------------------------------
3596 :     Number: 1257
3597 :     Title: (spurious) dependency cycle in instantiate
3598 :     Keywords: modules, opaque signatures
3599 :     Submitter: manuel@cs.berkeleye.edu
3600 :     Date: 8/19/97
3601 :     Version: SML-109.30 + blume patch
3602 :     System: x86-linux, sparc-solaris2.5
3603 :     Severity: major
3604 :     Problem: Opaque signature matching fails when the structure
3605 :     contains a functor whose signature has where
3606 :     specifications. Produces uncaught exception Unbound and
3607 :     a message "dependency cycle in instantiate"
3608 :    
3609 :     Code:
3610 :     signature S =
3611 :     sig
3612 :     type genT
3613 :    
3614 :     type T
3615 :    
3616 :     val embed : T -> genT
3617 :     end
3618 :    
3619 :    
3620 :     structure S =
3621 :     struct
3622 :     type genT = int
3623 :     type T = int
3624 :    
3625 :     val embed = fn x => x
3626 :     end
3627 :    
3628 :    
3629 :    
3630 :     signature B =
3631 :     sig
3632 :     type genT
3633 :    
3634 :     functor mkS() : S where type genT = genT
3635 :    
3636 :     end
3637 :    
3638 :     structure B :> B =
3639 :     struct
3640 :     type genT = S.genT
3641 :    
3642 :     functor mkS() = S
3643 :    
3644 :     end
3645 :    
3646 :     Transcript:
3647 :    
3648 :     - use "bug_inst.sml";
3649 :     [opening bug_inst.sml]
3650 :     bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate
3651 :    
3652 :     uncaught exception Unbound
3653 :     raised at: elaborate/elabmod.sml:1060.15-1060.25
3654 :     util/stats.sml:164.40
3655 :     build/evalloop.sml:123.38
3656 :     build/evalloop.sml:196.58
3657 :     build/evalloop.sml:289.46-289.49
3658 :     -
3659 :     Comments: The idea behind this code is to create new structures
3660 :     using B.mkS(), each of which will share the type genT,
3661 :     but not the type T.
3662 :    
3663 :     The desired behavior can be obtained with the following
3664 :     code, which moves the opaque matching from B to the
3665 :     functor. The difference to the code above is in that genT
3666 :     is not opaque in B.
3667 :    
3668 :     signature S =
3669 :     sig
3670 :     type genT
3671 :    
3672 :     type T
3673 :    
3674 :     val embed : T -> genT
3675 :     val new : int -> T
3676 :     val show : genT -> unit
3677 :    
3678 :     end
3679 :    
3680 :    
3681 :     structure S =
3682 :     struct
3683 :     type genT = int
3684 :     type T = int
3685 :    
3686 :     val embed = fn x => x
3687 :    
3688 :     fun new x = x
3689 :     val show = fn x => print (Int.toString x ^"\n")
3690 :    
3691 :     end
3692 :    
3693 :    
3694 :    
3695 :     signature B =
3696 :     sig
3697 :     type genT
3698 :    
3699 :     functor mkS() : S where type genT = genT
3700 :    
3701 :     end
3702 :    
3703 :     structure B : B =
3704 :     struct
3705 :     type genT = S.genT
3706 :    
3707 :     functor mkS() :> S where type genT = genT = S
3708 :    
3709 :     end
3710 :    
3711 :     structure X = B.mkS;
3712 :     structure Y = B.mkS;
3713 :    
3714 :     val x = X.new 5;
3715 :     val y = Y.new 7;
3716 :    
3717 :     val xe = X.embed x;
3718 :     val ye = X.embed y;
3719 :    
3720 :     val _ = X.show ye; (* is accepted correctly *)
3721 :     val _ = Y.show xe; (* is accepted correctly *)
3722 :     val xf = Y.embed x; (* rejected correctly *)
3723 :     val yf = X.embed y; (* rejected correctly *)
3724 :    
3725 :     val _ = X.show 5; (* genT isn't opaque. *)
3726 :    
3727 :     Fix:
3728 :     Test:
3729 :     Owner: dbm
3730 :     Status: Fixed in 109.31
3731 :     ----------------------------------------------------------------------
3732 :     Number: 1258
3733 :     Title: OS.Process.atExit does not agree with basis documentation
3734 :     Keywords: standard basis
3735 :     Submitter: Chris Stone, cstone+@cs.cmu.edu
3736 :     Perry Cheng, pscheng+@cs.cmu.edu
3737 :     Date: August 19, 1997
3738 :     Version: 109.30
3739 :     System: Alpha OSF/1 3.2
3740 :     Severity: minor
3741 :     Problem:
3742 :    
3743 :     From the on-line standard basis documentation for OS.Process.atExit:
3744 :    
3745 :     Calls to exit do not return, but should cause the remainder of the
3746 :     functions registered with atExit to be executed.
3747 :    
3748 :     The code does not have this behavior.
3749 :    
3750 :     Transcript:
3751 :    
3752 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3753 :     - OS.Process.atExit (fn _ => print "1\n");
3754 :     val it = () : unit
3755 :     - OS.Process.atExit (fn _ => print "2\n");
3756 :     val it = () : unit
3757 :     - OS.Process.atExit (fn _ => print "3\n");
3758 :     val it = () : unit
3759 :     - ^D3
3760 :     2
3761 :     1
3762 :    
3763 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
3764 :     - OS.Process.atExit (fn _ => print "1\n");
3765 :     val it = () : unit
3766 :     - OS.Process.atExit (fn _ => OS.Process.exit 1);
3767 :     val it = () : unit
3768 :     - OS.Process.atExit (fn _ => print "3\n");
3769 :     val it = () : unit
3770 :     - ^D3
3771 :     3
3772 :     3
3773 :     3
3774 :     ...[infinite loop]
3775 :    
3776 :     Comments:
3777 :    
3778 :     A quick glance at the file NJ/cleanup.sml led us to initially expect
3779 :     that the call to exit would terminate the program immediately,
3780 :     skipping the third function registered with atExit. However, it turns
3781 :     out that since the "clean" function does not change the list "hooks"
3782 :     when called with the AtExit parameter, the call to exit starts
3783 :     re-invoking all of the functions registered with AtExit.
3784 :    
3785 :     Fix:
3786 :     Test:
3787 :     Owner: jhr
3788 :     Status: fixed in 109.31
3789 :     ----------------------------------------------------------------------
3790 :     Number: 1259
3791 :     Title: Mistakenly inadmissable signature.
3792 :     Keywords: modules, signatures
3793 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
3794 :     Date: 8/19/97
3795 :     Version: 109.30
3796 :     System: x86-linux
3797 :     Severity: minor
3798 :     Problem:
3799 :     The following signature is not accepted by SML/NJ 109.30,
3800 :     even though it should be. SML/NJ 109.30 returns the message
3801 :     "Error: dependency cycle in instantiate". Earlier
3802 :     versions, such as 109.29, accepted this signature at
3803 :     the point it was declared, but reported the dependency
3804 :     cycle error when it was used as a functor parameter
3805 :     (i.e. when it was instantiated).
3806 :     Code:
3807 :     signature SIG =
3808 :     sig
3809 :     type b'
3810 :     datatype a = A1 | A2 of b'
3811 :     datatype b = B1 | B2 of a
3812 :     sharing type b = b'
3813 :     end
3814 :    
3815 :     The signature is accepted when it directly constrains a structure, as
3816 :     in the following code.
3817 :    
3818 :     structure S : sig
3819 :     type b'
3820 :     datatype a = A1 | A2 of b'
3821 :     datatype b = B1 | B2 of a
3822 :     sharing type b = b'
3823 :     end =
3824 :     struct
3825 :     datatype a = A1 | A2 of b
3826 :     and b = B1 | B2 of a
3827 :     type b' = b
3828 :     end
3829 :    
3830 :     Transcript:
3831 :     Comments:
3832 :     This might be the same as bug #1257.
3833 :    
3834 :     [Zhong, 8/21/97]
3835 :     Ok, in 109.30, we check the validity of every signature at its definition
3836 :     site (i.e., we try to instantiate it), thus the cycle is detected even
3837 :     at the declaration site.
3838 :    
3839 :     |> In any case, both versions are wrong to reject the signature, since it
3840 :     |> can be instantiated by the structure I provided.
3841 :     |>
3842 :     |> structure S : sig
3843 :     |> type b'
3844 :     |> datatype a = A1 | A2 of b'
3845 :     |> datatype b = B1 | B2 of a
3846 :     |> sharing type b = b'
3847 :     |> end =
3848 :     |> struct
3849 :     |> datatype a = A1 | A2 of b
3850 :     |> and b = B1 | B2 of a
3851 :     |> type b' = b
3852 :     |> end
3853 :    
3854 :     I'd not say our implementation is wrong :-) I'd argue that it is the
3855 :     Definition that is wrong --- in fact, the Definition is vague on how
3856 :     the above signature will be elaborated --- if you follow what's said
3857 :     in the Definition, you will get a structure of the form
3858 :    
3859 :     structure SIG-INST =
3860 :     struct type b' = b
3861 :     datatype a = A1 | A2 of b
3862 :     datatype b = B1 | B2 of a
3863 :     end
3864 :    
3865 :     [dbm: not quite. The definition (rule 78) elaborates the sharing
3866 :     spec by applying a substitution to an already elaborated environment
3867 :     structure representing the previous specs.]
3868 :    
3869 :     Notice I have no way to reorder the above into a valid ML structure.
3870 :     The best I can do is:
3871 :    
3872 :     structure SIG-INST =
3873 :     struct datatype a = A1 | A2 of b
3874 :     datatype b = B1 | B2 of a
3875 :     type b' = b
3876 :     end
3877 :    
3878 :     still type a and b are mutually recursive. To make it work, the
3879 :     signature elaboration has to make a and b mutually recursive:
3880 :    
3881 :     structure SIG-INST =
3882 :     struct datatype a = A1 | A2 of b
3883 :     and b = B1 | B2 of a
3884 :     type b' = b
3885 :     end
3886 :    
3887 :     This is non-trivial to generalize to cover other cases; for example,
3888 :     what if SIG is like the following:
3889 :    
3890 :     signature SIG' =
3891 :     sig type b'
3892 :     datatype a = A1 | A2 of b'
3893 :     structure S : sig
3894 :     datatype b = B1 | B2 of a
3895 :     end
3896 :     sharing type b' = S.b'
3897 :     end
3898 :    
3899 :     SIG' probably will not match any structure, but it is very hard
3900 :     to discover what is match-able and what is not.
3901 :    
3902 :     Because of all these, we decided to adopt a simpler algorithm
3903 :     in SML/NJ --- we'll only do reorganizations of all the specs,
3904 :     but we'll never merge two non-recursive datatype specs into
3905 :     mutually-recursive ones.
3906 :    
3907 :     [dbm, 8/5/97]
3908 :     I think that it would probably be possible to fix this "bug"
3909 :     superficially in the Instantiate module, but I am not sure what
3910 :     the consequences would be for FLINT's type representation analysis.
3911 :    
3912 :     In particular, with a signature declaration such as the
3913 :     following
3914 :    
3915 :     [1] signature SIG =
3916 :     sig
3917 :     type b'
3918 :     datatype a = A1 | A2 of b'
3919 :     datatype b = B1 | B2 of a
3920 :     sharing type b = b'
3921 :     end
3922 :    
3923 :     the datatypes a and b are made mutually recursive "after the fact"
3924 :     as a consequence of the type sharing spec. Will the FLINT
3925 :     representation analysis be able to come up with the same
3926 :     representations of a and b as for the following "equivalent"
3927 :     (see comment on equality properties below) signatures:
3928 :    
3929 :     [2] signature SIG =
3930 :     sig
3931 :     datatype a = A1 | A2 of b
3932 :     and b = B1 | B2 of a
3933 :     type b'
3934 :     sharing type b = b'
3935 :     end
3936 :    
3937 :     [3] signature SIG =
3938 :     sig
3939 :     datatype a = A1 | A2 of b
3940 :     and b = B1 | B2 of a
3941 :     type b' = b
3942 :     end
3943 :    
3944 :     and if you come up with different representations for the latter
3945 :     two signatures, does it matter?
3946 :    
3947 :     In other words, if you have two independent datatype specs, and
3948 :     then tie a knot between them by a subsequent sharing spec, can you
3949 :     recover the same representation as though the types had originally
3950 :     been specified as mutually recursive, or do you care?
3951 :    
3952 :     There is also the issue of assigning the equality properties to
3953 :     the specified types. In [1], b' does not admit equality, and
3954 :     therefore neither does a, and so neither does b. In [2] and [3],
3955 :     a and b, and therefore b', do admit equality. Does this inconsistency
3956 :     matter?
3957 :    
3958 :     Also, things can get much more convoluted; for instance
3959 :    
3960 :     signature SIG =
3961 :     sig
3962 :     structure A : sig
3963 :     type a
3964 :     end
3965 :     structure B : sig
3966 :     datatype b = B1 | B2 of A.a
3967 :     end
3968 :     structure C : sig
3969 :     datatype c = C1 | C2 of B.b
3970 :     end
3971 :     sharing type A.a = C.c
3972 :     end
3973 :    
3974 :     which could be matched by the structure
3975 :    
3976 :     structure S =
3977 :     struct
3978 :     datatype b = B1 | B2 of c
3979 :     and c = C1 | C2 of b
3980 :     structure A = struct
3981 :     type a = c
3982 :     end
3983 :     structure A = struct
3984 :     datatype b = datatype b
3985 :     end
3986 :     structure A = struct
3987 :     datatype c = datatype c
3988 :     end
3989 :     end
3990 :    
3991 :     I think it is clear that we don't want to force Instantiate
3992 :     to be this clever when attempting to create a realization.
3993 :    
3994 :     So how do we formulate a sharp condition that will disallow
3995 :     these kinds of recursion through sharing specs?
3996 :    
3997 :     Fix:
3998 :     Test: bug1259.1.sml, bug1259.2.sml, bug1259.3.sml
3999 :     Owner: dbm, Zhong
4000 :     Status: open
4001 :     ----------------------------------------------------------------------
4002 :     Number: 1260
4003 :     Title: Compiler bug (EntityEnv) when compiling ml-yacc
4004 :     Keywords:
4005 :     Submitter: John Reppy (jhr@research.bell-labs.com)
4006 :     Date: August 26, 1997
4007 :     Version: 109.30+
4008 :     System: all
4009 :     Severity: major
4010 :     Problem:
4011 :     I changed ml-yacc by replacing the three uses of "abstraction"
4012 :     with ":>". Now I get a compiler error on the file parser2.sml,
4013 :     which is one of the files I changed. I note that this file compiled
4014 :     okay in the context of the compiler, but not when trying to
4015 :     compile ml-yacc. Note, the changed file is accepted by 109.30,
4016 :     so this must have been introduced by one of the recent changes.
4017 :     Code:
4018 :     Transcript:
4019 :     [opening ../lib/parser2.sml]
4020 :     GC #0.0.0.1.3.62: (76 ms)
4021 :     lookEnt.1: expected STRent
4022 :     found entity: TYCent
4023 :     entpath: [#L.52,#L.1]
4024 :     Error: Compiler bug: EntityEnv: lookEnt.2
4025 :    
4026 :     uncaught exception TopLevelException [Error]
4027 :     raised at: util/errormsg.sml:54.14-54.19
4028 :     modules/instantiate.sml:1122.9
4029 :     elaborate/elabmod.sml:1119.8
4030 :     util/stats.sml:164.40
4031 :     build/evalloop.sml:123.38
4032 :     build/evalloop.sml:196.58
4033 :     build/evalloop.sml:289.46-289.49
4034 :    
4035 :     Comments:
4036 :     Zhong says:
4037 :     I found a fix for the bug. The bug was caused by Dave and Matthias's
4038 :     recent changes on turning off "pickling" in the top level (sigh ...).
4039 :     In fact, a more severe bug is the test case below.
4040 :    
4041 :     It turns out that the mkStamp function is making new stamp from 0
4042 :     when compiling each compilation unit (hmmm, not quite accurate, look
4043 :     when evalLoop is called in interact.sml). So t and s share the
4044 :     same stamp (L0).
4045 :    
4046 :     If we do pickling, s and t's stamps will be globalized during the
4047 :     pickling, so they will not be indentified.
4048 :    
4049 :     For the ML-Yacc, it is the similar reason. Because the stamp is not
4050 :     unique, the entity variable created for each signature component is
4051 :     not unique, this confuses the elaborator thus causing the bug.
4052 :    
4053 :     Fix:
4054 :     I make sure that the compiler never resets the global stamp
4055 :     counter --- notice that if the interactive loop is long enough
4056 :     (e.g., even after exportML,...); it is possible to run out of the stamps
4057 :     (i.e., overflow) --- especially the same stamp counter is now used
4058 :     for multiple purposes (stamp, entvar, ...). With pickling, the counter
4059 :     is reset each time and the pickler always globalize all the stamps
4060 :     (even hidden ones) with an external pid !
4061 :    
4062 :     Test:
4063 :     (* typing in each of the following at the top-level *)
4064 :    
4065 :     local datatype t = A
4066 :     in val x = A
4067 :     end;
4068 :    
4069 :     junk; (* this line is crucial; the purpose is to cause an error *)
4070 :    
4071 :     local datatype s = B
4072 :     in val y = B
4073 :     end;
4074 :    
4075 :     x = y;
4076 :    
4077 :     (* The compiler accepts the "x = y", and producing true. *)
4078 :    
4079 :     Owner: dbm, blume, zsh
4080 :     Status: fixed in 109.31
4081 :     ----------------------------------------------------------------------
4082 :     Number: 1261
4083 :     Title: explicit type parameter with "val rec" not supported
4084 :     Keywords: syntax, explicit type parameters
4085 :     Submitter: Dave MacQueen
4086 :     Date: 9/4/97
4087 :     Version: 109.30
4088 :     System: -
4089 :     Severity: minor
4090 :     Problem:
4091 :     Syntax "val 'a rec ..." not implemented.
4092 :     Transcript:
4093 :     - val 'a rec f = fn x : 'a => x;
4094 :     stdIn:14.8-14.15 Error: syntax error: deleting REC ID EQUALOP
4095 :     stdIn:14.16-14.22 Error: syntax error: deleting FN ID COLON
4096 :     stdIn:14.23-14.28 Error: syntax error: deleting TYVAR DARROW
4097 :     Comments:
4098 :     Fix:
4099 :     Test: bug1261.sml
4100 :     Owner: dbm, Appel
4101 :     Status: open
4102 :     ----------------------------------------------------------------------
4103 :     Number: 1262
4104 :     Title: literal ~0.0 reads as 0.0
4105 :     Keywords: floating point, literals
4106 :     Submitter: appel
4107 :     Date: August 19, 1997
4108 :     Version: 109.30
4109 :     System: any
4110 :     Severity: minor
4111 :     Problem: literal ~0.0 reads as 0.0
4112 :     Code: Real.copysign(1.0,~0.0)
4113 :     Transcript: val it = 1.0
4114 :     Comments:
4115 :     Fix: in first if-statement of ieeereal.sml
4116 :     Test: bug1262.sml
4117 :     Owner: Appel
4118 :     Status: open
4119 :     ----------------------------------------------------------------------
4120 :     Number: 1263
4121 :     Title: sqrt, ln incorrect on subnormal numbers
4122 :     Keywords: floating point, math
4123 :     Submitter: appel
4124 :     Date: August 19, 1997
4125 :     Version: 109.30
4126 :     System: any
4127 :     Severity: minor
4128 :     Problem: sqrt, ln incorrect on subnormal numbers
4129 :     Code: let val a = Math.sqrt(Real.minNormalPos * 0.1)
4130 :     in [Real.minNormalPos*0.1, a*a]
4131 :     end
4132 :     Transcript: val it = [2.22507385851e~309,1.22379062218e~308] : real list
4133 :     Comments: The scalb and logb functions in math64.sml
4134 :     called upon Assembly.A.scalb,logb,
4135 :     and were already augmented to handle a bigger range
4136 :     of cases than the assembly-lang primops,
4137 :     but I made them even fancier to handle subnormal
4138 :     inputs and outputs.
4139 :     Status: fixed in 109.31
4140 :     ----------------------------------------------------------------------
4141 :     Number: 1264
4142 :     Title: (spurious) dependency cycle in instantiate
4143 :     Keywords: modules, opaque signatures
4144 :     Submitter: manuel@cs.berkeleye.edu
4145 :     Date: 8/19/97
4146 :     Version: SML-109.27 + blume patch
4147 :     System: x86-linux, sparc-solaris2.5
4148 :     Severity: major
4149 :     Problem: Opaque signature matching fails when the structure
4150 :     contains a functor whose signature has where
4151 :     specifications. Produces uncaught exception Unbound and
4152 :     a message "dependency cycle in instantiate"
4153 :    
4154 :     Code:
4155 :     signature S =
4156 :     sig
4157 :     type genT
4158 :     type T
4159 :     val embed : T -> genT
4160 :     end;
4161 :    
4162 :     structure S =
4163 :     struct
4164 :     type genT = int
4165 :     type T = int
4166 :     val embed = fn x => x
4167 :     end;
4168 :    
4169 :     signature B =
4170 :     sig
4171 :     type genT
4172 :     functor mkS() : S where type genT = genT
4173 :     end;
4174 :    
4175 :     structure B :> B =
4176 :     struct
4177 :     type genT = S.genT
4178 :     functor mkS() = S
4179 :     end;
4180 :    
4181 :     Transcript:
4182 :    
4183 :     - use "bug_inst.sml";
4184 :     [opening bug_inst.sml]
4185 :     bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate
4186 :    
4187 :     uncaught exception Unbound
4188 :     raised at: elaborate/elabmod.sml:1060.15-1060.25
4189 :     util/stats.sml:164.40
4190 :     build/evalloop.sml:123.38
4191 :     build/evalloop.sml:196.58
4192 :     build/evalloop.sml:289.46-289.49
4193 :     -
4194 :     Comments: The idea behind this code is to create new structures
4195 :     using B.mkS(), each of which will share the type genT,
4196 :     but not the type T.
4197 :    
4198 :     The desired behavior can be obtained with the following
4199 :     code, which moves the opaque matching from B to the
4200 :     functor. The difference to the code above is in that genT
4201 :     is not opaque in B.
4202 :    
4203 :     signature S =
4204 :     sig
4205 :     type genT
4206 :     type T
4207 :    
4208 :     val embed : T -> genT
4209 :     val new : int -> T
4210 :     val show : genT -> unit
4211 :     end
4212 :    
4213 :     structure S =
4214 :     struct
4215 :     type genT = int
4216 :     type T = int
4217 :    
4218 :     val embed = fn x => x
4219 :    
4220 :     fun new x = x
4221 :     val show = fn x => print (Int.toString x ^"\n")
4222 :     end
4223 :    
4224 :     signature B =
4225 :     sig
4226 :     type genT
4227 :     functor mkS() : S where type genT = genT
4228 :     end
4229 :    
4230 :     structure B : B =
4231 :     struct
4232 :     type genT = S.genT
4233 :     functor mkS() :> S where type genT = genT = S
4234 :     end
4235 :    
4236 :     structure X = B.mkS;
4237 :     structure Y = B.mkS;
4238 :    
4239 :     val x = X.new 5;
4240 :     val y = Y.new 7;
4241 :    
4242 :     val xe = X.embed x;
4243 :     val ye = X.embed y;
4244 :    
4245 :     val _ = X.show ye; (* is accepted correctly *)
4246 :     val _ = Y.show xe; (* is accepted correctly *)
4247 :     val xf = Y.embed x; (* rejected correctly *)
4248 :     val yf = X.embed y; (* rejected correctly *)
4249 :    
4250 :     val _ = X.show 5; (* genT isn't opaque. *)
4251 :    
4252 :     Fix: <sorry>
4253 :     Test: bug1264.sml
4254 :     Owner: Zhong
4255 :     Status: fixed in 109.31 [Zhong, 8/21/97]
4256 :     ----------------------------------------------------------------------
4257 :     Number: 1265
4258 :     Title: uncaught Match exn in elabmod.sml:632.7
4259 :     Keywords: module elaboration, signature matching
4260 :     Submitter: manuel@cs.berkeley.edu
4261 :     Date: 8/19/97
4262 :     Version: 109.30 + Matthias Blume patch
4263 :     System: x86-linux, sparc-solaris2.5
4264 :     Severity: major
4265 :     Problem: Signature matching causes Match exception in compiler
4266 :     Code:
4267 :     structure J : S = K : T;
4268 :    
4269 :     Transcript:
4270 :     - structure J : S = K : T;
4271 :    
4272 :     uncaught exception in compiler: nonexhaustive match failure
4273 :     raised at: elaborate/elabmod.sml:632.7
4274 :     elaborate/elabmod.sml:1059.8
4275 :     util/stats.sml:164.40
4276 :     build/evalloop.sml:123.38
4277 :     build/evalloop.sml:196.58
4278 :     -
4279 :     Comments:
4280 :     Fix:
4281 :     Test: bug1265.sml
4282 :     Owner: Zhong, dbm
4283 :     Status: fixed in 109.31
4284 :     ----------------------------------------------------------------------
4285 :     Number: 1266
4286 :     Title: OS.Process.atExit does not agree with basis documentation
4287 :     Keywords: standard basis
4288 :     Submitter: Chris Stone, cstone+@cs.cmu.edu
4289 :     Perry Cheng, pscheng+@cs.cmu.edu
4290 :     Date: August 19, 1997
4291 :     Version: 109.30
4292 :     System: Alpha OSF/1 3.2
4293 :     Severity: minor
4294 :     Problem:
4295 :    
4296 :     From the on-line standard basis documentation for OS.Process.atExit:
4297 :    
4298 :     Calls to exit do not return, but should cause the remainder of the
4299 :     functions registered with atExit to be executed.
4300 :    
4301 :     The code does not have this behavior.
4302 :    
4303 :     Transcript:
4304 :    
4305 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
4306 :     - OS.Process.atExit (fn _ => print "1\n");
4307 :     val it = () : unit
4308 :     - OS.Process.atExit (fn _ => print "2\n");
4309 :     val it = () : unit
4310 :     - OS.Process.atExit (fn _ => print "3\n");
4311 :     val it = () : unit
4312 :     - ^D3
4313 :     2
4314 :     1
4315 :    
4316 :     Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
4317 :     - OS.Process.atExit (fn _ => print "1\n");
4318 :     val it = () : unit
4319 :     - OS.Process.atExit (fn _ => OS.Process.exit 1);
4320 :     val it = () : unit
4321 :     - OS.Process.atExit (fn _ => print "3\n");
4322 :     val it = () : unit
4323 :     - ^D3
4324 :     3
4325 :     3
4326 :     3
4327 :     ...[infinite loop]
4328 :    
4329 :     Comments:
4330 :    
4331 :     A quick glance at the file NJ/cleanup.sml led us to initially expect
4332 :     that the call to exit would terminate the program immediately,
4333 :     skipping the third function registered with atExit. However, it turns
4334 :     out that since the "clean" function does not change the list "hooks"
4335 :     when called with the AtExit parameter, the call to exit starts
4336 :     re-invoking all of the functions registered with AtExit.
4337 :    
4338 :     Fix: *
4339 :     Test: *
4340 :     Owner: jhr
4341 :     Status: fixed in 109.31 [jhr, 8/19/97]
4342 :     ----------------------------------------------------------------------
4343 :     Number: 1267 (duplicate of bug 1259)
4344 :     Title: Mistakenly inadmissable signature.
4345 :     Keywords: modules, signatures, definition specs, datatype specs
4346 :     Submitter: Stephen Weeks <sweeks@research.nj.nec.com>
4347 :     Date: 8/19/97
4348 :     Version: 109.30
4349 :     System: x86-linux
4350 :     Severity: minor
4351 :     Problem: The following signature is not accepted by SML/NJ 109.30,
4352 :     even though it should be. SML/NJ 109.30 returns the message
4353 :     "Error: dependency cycle in instantiate". Earlier
4354 :     versions, such as 109.29, accepted this signature.
4355 :    
4356 :     signature SIG =
4357 :     sig
4358 :     type b'
4359 :     datatype a = A1 | A2 of b'
4360 :     datatype b = B1 | B2 of a
4361 :     sharing type b = b'
4362 :     end
4363 :    
4364 :     The signature is accepted when it directly constrains a
4365 :     structure, as in the following code.
4366 :    
4367 :     structure S : sig
4368 :     type b'
4369 :     datatype a = A1 | A2 of b'
4370 :     datatype b = B1 | B2 of a
4371 :     sharing type b = b'
4372 :     end =
4373 :     struct
4374 :     datatype a = A1 | A2 of b
4375 :     and b = B1 | B2 of a
4376 :     type b' = b
4377 :     end
4378 :    
4379 :     Code:
4380 :    
4381 :     Transcript:
4382 :     Comments:
4383 :     [Zhong, 8/21/97]
4384 :     |> In any case, both versions are wrong to reject the signature, since it
4385 :     |> can be instantiated by the structure I provided.
4386 :     |>
4387 :     |> structure S : sig
4388 :     |> type b'
4389 :     |> datatype a = A1 | A2 of b'
4390 :     |> datatype b = B1 | B2 of a
4391 :     |> sharing type b = b'
4392 :     |> end =
4393 :     |> struct
4394 :     |> datatype a = A1 | A2 of b
4395 :     |> and b = B1 | B2 of a
4396 :     |> type b' = b
4397 :     |> end
4398 :    
4399 :     I'd not say our implementation is wrong :-) I'd argue that it is the
4400 :     Definition that is wrong --- in fact, the Definition is vague on how
4401 :     the above signature will be elaborated --- if you follow what's said
4402 :     in the Definition, you will get a structure of the form
4403 :    
4404 :     structure SIG-INST =
4405 :     struct type b' = b
4406 :     datatype a = A1 | A2 of b
4407 :     datatype b = B1 | B2 of a
4408 :     end
4409 :    
4410 :     Notice I have no way to reorder the above into a valid ML structure.
4411 :     The best I can do is:
4412 :    
4413 :     structure SIG-INST =
4414 :     struct datatype a = A1 | A2 of b
4415 :     datatype b = B1 | B2 of a
4416 :     type b' = b
4417 :     end
4418 :    
4419 :     still type a and b are mutually recursive. To make it work, the
4420 :     signature elaboration has to make a and b mutually recursive:
4421 :    
4422 :     structure SIG-INST =
4423 :     struct datatype a = A1 | A2 of b
4424 :     and b = B1 | B2 of a
4425 :     type b' = b
4426 :     end
4427 :    
4428 :     This is non-trivial to generalize to cover other cases; for example,
4429 :     what if SIG is like the following:
4430 :    
4431 :     signature SIG' =
4432 :     sig type b'
4433 :     datatype a = A1 | A2 of b'
4434 :     structure S : sig
4435 :     datatype b = B1 | B2 of a
4436 :     end
4437 :     sharing type b' = S.b'
4438 :     end
4439 :    
4440 :     SIG' probably will not match any structure, but it is very hard
4441 :     to discover what is match-able and what is not.
4442 :    
4443 :     Because of all these, we decided to adopt a simpler algorithm
4444 :     in SML/NJ --- we'll only do reorganizations of all the specs,
4445 :     but we'll never merge two non-recursive datatype specs into
4446 :     mutually-recursive ones.
4447 :    
4448 :     Fix: -
4449 :     Test: -
4450 :     Owner: dbm, Zhong
4451 :     Status: not a bug
4452 :     ----------------------------------------------------------------------
4453 :     Number: 1268
4454 :     Title: logb of negative numbers on Sparc
4455 :     Keywords: floating point, logb
4456 :     Submitter: appel
4457 :     Date: 8/21/97
4458 :     Version: 109.30
4459 :     System: Sparc
4460 :     Severity: minor
4461 :     Problem: Assembly.A.logb gives bogus result for any negative number.
4462 :     Code: Assembly.A.logb ~1.0; (* this example from 109.29 *)
4463 :     Transcript: val it = 2048 : int
4464 :     Comments: broken since 109.26 or before
4465 :     [dbm, 11/11/97] Test case is obsolete in 109.32 because Assembly is
4466 :     not bound at top level. Needs to be tested indirectly by regression
4467 :     tests on Math, Real64 structures.
4468 :     Fix: in SPARC.prim.asm
4469 :     Test: bug1268.sml (obsolete)
4470 :     Owner: Appel
4471 :     Status: fixed in 109.31
4472 :     ----------------------------------------------------------------------
4473 :     Number: 1269
4474 :     Title: CM.set_path has no effect after CM.make
4475 :     Keywords: CM
4476 :     Submitter: John Reppy (jhr@research.bell-labs.com)
4477 :     Date: August 21, 1997
4478 :     Version: 109.30
4479 :     System: all
4480 :     Severity: minor
4481 :     Problem: One a CM.make command has been executed, changing the
4482 :     search path has no effect.
4483 :     Code:
4484 :     Transcript:
4485 :    
4486 :     - CM.make();
4487 :     [starting dependency analysis]
4488 :     [scanning sources.cm]
4489 :     [checking CM/mipseb-unix/sources.cm.stable ... not usable]
4490 :    
4491 :     !* CM error: smlnj-lib.cm: description file not found
4492 :     - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]);
4493 :     val it = [] : string list
4494 :     - CM.make();
4495 :     [starting dependency analysis]
4496 :    
4497 :     !* CM error: smlnj-lib.cm: description file not found
4498 :     -
4499 :    
4500 :     whereas, if I change the path first, it works fine.
4501 :    
4502 :     - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]);
4503 :     val it = [] : string list
4504 :     - CM.make();
4505 :     [starting dependency analysis]
4506 :     [scanning sources.cm]
4507 :     [checking CM/mipseb-unix/sources.cm.stable ... not usable]
4508 :     [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]
4509 :     ...
4510 :    
4511 :     Comments:
4512 :     Fix:
4513 :     Test:
4514 :     Owner: Blume
4515 :     Status: open?
4516 :     ----------------------------------------------------------------------
4517 :     Number: 1270
4518 :     Title: EntityEnv.Unbound raised while compiling functor
4519 :     Keywords: modules, functors, signature matching
4520 :     Submitter: Lal George
4521 :     Date: 9/8/97
4522 :     Version: 109.31
4523 :     System: -
4524 :     Severity: major
4525 :     Problem:
4526 :     EntityEnv.Unbound raised while compiling functor
4527 :     Code:
4528 :     (* bug1270.sml *)
4529 :    
4530 :     signature S2 =
4531 :     sig
4532 :     structure A : sig type s end
4533 :     val x : A.s
4534 :     end;
4535 :    
4536 :     signature S3 =
4537 :     sig
4538 :     type u
4539 :     val y : u
4540 :     end;
4541 :    
4542 :     functor F (structure X: S3) = (* "structure" necessary *)
4543 :     struct
4544 :     type s = X.u
4545 :     end;
4546 :    
4547 :     functor G (U: S3) (V: S2) : S2 = (* ": S2" necessary *)
4548 :     struct
4549 :     structure A = F (structure X = U)
4550 :     val x = U.y
4551 :     end;
4552 :     Transcript:
4553 :     - use "bug1270.sml";
4554 :     [opening bug1270.sml]
4555 :     signature S2 =
4556 :     sig
4557 :     structure A : sig type s end
4558 :     val x : A.s
4559 :     end
4560 :     signature S3 =
4561 :     sig
4562 :     type u
4563 :     val y : u
4564 :     end
4565 :     functor F : <sig>
4566 :    
4567 :     uncaught exception Unbound
4568 :     raised at: elaborate/elabmod.sml:1225.39-1225.49
4569 :     util/stats.sml:164.40
4570 :     build/evalloop.sml:123.38
4571 :     build/evalloop.sml:196.58
4572 :     build/evalloop.sml:292.19-292.22
4573 :    
4574 :     Comments:
4575 :     Regression failure for bug 922.
4576 :     Fix:
4577 :     Test: bug1270.sml
4578 :     Owner: dbm, Zhong
4579 :     Status: open
4580 :     ----------------------------------------------------------------------
4581 :     Number: 1271
4582 :     Title: uncaught Unbound while compiling open
4583 :     Keywords: modules, functors, open
4584 :     Submitter: Lal George
4585 :     Date: 9/8/97
4586 :     Version: 109.31
4587 :     System: -
4588 :     Severity: major
4589 :     Problem: uncaught Unbound while compiling open
4590 :     Code:
4591 :     signature SIG1 =
4592 :     sig
4593 :     type t
4594 :     val x: t
4595 :     end;
4596 :    
4597 :     signature SIG2 =
4598 :     sig
4599 :     functor Foo(X:SIG1) : sig val w: X.t end
4600 :     end;
4601 :    
4602 :     structure B : SIG2 = (* ": SIG2" is necessary *)
4603 :     struct
4604 :     functor Foo(X:SIG1) =
4605 :     struct
4606 :     val w = X.x
4607 :     end
4608 :     end;
4609 :    
4610 :     open B;
4611 :    
4612 :     Transcript:
4613 :     - use "bug1271.sml";
4614 :     [opening bug1271.sml]
4615 :     signature SIG1 =
4616 :     sig
4617 :     type t
4618 :     val x : t
4619 :     end
4620 :     signature SIG2 =
4621 :     sig functor Foo : (<paramname>: <sig>) : <sig> end
4622 :     structure B :
4623 :     SIG2
4624 :    
4625 :     uncaught exception Unbound
4626 :     raised at: translate/transmodules.sml:80.33-80.43
4627 :     util/stats.sml:164.40
4628 :     build/evalloop.sml:196.58
4629 :     build/evalloop.sml:292.19-292.22
4630 :     Comments:
4631 :     Regression failure for bug 641.
4632 :    
4633 :     The SIG2 signature constraint on B is necessary for the
4634 :     bug to occur.
4635 :    
4636 :     Other references to B.Foo, such as
4637 :    
4638 :     functor F = B.Foo
4639 :    
4640 :     or
4641 :    
4642 :     structure XX = B.Foo(struct type t = int val x = 3 end);
4643 :    
4644 :     will also cause an uncaught Unbound exception.
4645 :     Fix:
4646 :     Test: bug1271.sml
4647 :     Owner: dbm, Zhong
4648 :     Status: open
4649 :     ----------------------------------------------------------------------
4650 :     Number: 1272
4651 :     Title: Match exception raised in instantiate while elaborating sig
4652 :     Keywords: modules, signatures, definition specs, sharing
4653 :     Submitter: Lal George
4654 :     Date: 9/8/97
4655 :     Version: 109.31
4656 :     System: -
4657 :     Severity: major
4658 :     Problem:
4659 :     Match exception raised in instantiate while elaborating sig
4660 :     Code: (bug1272.sml)
4661 :     signature Z = sig end;
4662 :    
4663 :     signature S =
4664 :     sig
4665 :     structure A: Z
4666 :     end;
4667 :    
4668 :     signature T1 =
4669 :     sig
4670 :     structure B: S
4671 :     structure A : Z = B.A
4672 :     end;
4673 :    
4674 :     signature T2 =
4675 :     sig
4676 :     structure B: S
4677 :     structure A : Z = B.A
4678 :     end;
4679 :    
4680 :     signature V =
4681 :     sig
4682 :     structure C: T1
4683 :     structure D: T2
4684 :     sharing C = D
4685 :     end;
4686 :    
4687 :     Transcript:
4688 :     uncaught exception Match [nonexhaustive match failure]
4689 :    </