Number: 1201 Title: ltUnbound in curried functor with where structure Keywords: modules, functors, where structure Submitter: Dave MacQueen Date: 5/16/97 Version: 109.27+ (with SML 97 sharing, where structure, etc.) System: - Severity: major Problem: A "where structure" clause modifying the second parameter signature refers to a substructure of the first parameter. The result is a message "**** hmmm, I didn't find the variable 52" and an uncaught ltUnbound exception. Code: signature SA = sig type t end; signature SX = sig structure A : SA end; signature SY = sig structure A : SA end; functor F (structure X : SX) (structure Y : SY where structure A = X.A) = struct end; Transcript: - use "bug1201.sml"; [opening bug1201.sml] signature SA = sig type t end signature SX = sig structure A : sig type t end end signature SY = sig structure A : sig type t end end **** hmmm, I didn't find the variable 52 uncaught exception ltUnbound raised at: basics/ltyenv.sml:244.32-244.41 util/stats.sml:164.40 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Comments: An extended variant of this remains open. See bug 1205. [fixed in 109.31] Fix: In ElabSig, where a STRdef is created by elabWhere, in the case that the STRdef in a CONSTstrDef variant, we replace the access and info fields by null values (NO_ACCESS and INL_NO respectively), since these fields are not relevant. Alternatively we could have CONSTstrDef have a record with only the sign and rlzn fields from the structure. Test: bug1201.sml Owner: dbm, zhong Status: fixed in 109.28 [dbm, 5/19/97] ---------------------------------------------------------------------- Number: 1202 Title: Unbound in functor with where structure clause on parameter sig Keywords: modules, functors, where structure Submitter: Dave MacQueen Date: 5/16/97 Version: 109.27+ (with SML 97 sharing, where structure, etc) System: - Severity: major Problem: where structure clause in parameter signature causes uncaught exception Unbound Code: signature SA = sig type t end; signature SX = sig structure A : SA end; signature SY = sig structure A : SA end; functor F (structure X : SX structure Y : SY where structure A = X.A) = struct end; Transcript: - use "bug1202.sml"; [opening bug1202.sml] signature SA = sig type t end signature SX = sig structure A : sig type t end end signature SY = sig structure A : sig type t end end uncaught exception Unbound raised at: elaborate/elabmod.sml:1144.39-1144.49 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Comments: Note that in bug1202.3, the explicit definition of the parameter signature SZ works, but the functor declaration still fails with uncaught Unbound. This is probably the same bug as 1200. Fix: Test: bug1202.1.sml, bug1202.2.sml, bug1202.3.sml Owner: dbm Status: fixed in 109.28 [dbm,5/20/97] ---------------------------------------------------------------------- Number: 1203 Title: structure def spec doesn't work Keywords: modules, signatures, functors, structure definition spec Submitter: Dave MacQueen Date: 5/16/97 Version: 109.27+ (with SML 97 sharing, where structure, etc) System: - Severity: major Problem: A structure def spec in a functor parameter signature doesn't have the expected effect. Code: signature S = sig type t end; structure A : S = struct type t = int end; functor F1(X: sig type t = A.t end) = struct val x : X.t = 3 end; functor F2(X: sig structure B: S = A end) = struct val x : X.B.t = 3 end; Transcript: - use "bug1203.sml"; [opening bug1203.sml] signature S = sig type t end structure A : S functor F1 : GC #0.0.0.0.1.2: (0 ms) bug1203.sml:18.3-18.20 Error: pattern and expression in val dec don't agree [literal] pattern: ?.t expression: int in declaration: x : ?.t = (3 : int) uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Comments: Fix: Test: bug1203.sml Owner: dbm Status: fixed in 109.28 [dbm] ---------------------------------------------------------------------- Number: 1204 Title: invalid paths in lhs of where clauses Keywords: modules, signatures, where clauses Submitter: Dave MacQueen Date: 5/16/97 Version: 109.27+ (SML 97 sharing, where structure, etc.) System: - Severity: major Problem: An invalid path in the the lhs of a where clause is not detected when a signature is elaborated, and causes uncaught Unbound when the signature is instantiated as a functor parameter. Code: This causes no complaint: (* bug1204.1.sml *) signature S = sig type t end; signature S1 = S where type A.t = int; while this causes uncaught exception Unbound: (* bug1204.2.sml *) signature S = sig type t end; functor F(X: S where type A.t = int) = struct end; Comments: Fix: added checkWhereDefs in ElabSig to check that lhs paths are valid. Test: bug1204.1.sml, bug1204.2.sml Owner: dbm Status: fixed in 109.28 [dbm, 5/17/98] ---------------------------------------------------------------------- Number: 1205 Title: problem with "where structure" and curried functors (cf. 1201) Keywords: modules, functors, curried functors, where structure Submitter: Dave MacQueen Date: 5/21/97 Version: 109.27+ (109.28) System: - Severity: major Problem: Defining the result of a curried functor by partial application of another curried functor, a "where structure" spec is not matched. Code: (* bug1205.sml *) signature SA = sig type t end; signature SX = sig structure A : SA end; signature SY = sig structure A : SA end; functor F (structure X : SX) (structure Y : SY where structure A = X.A) = struct fun f(x: X.A.t, y: Y.A.t list) = x::y end; functor G(structure A : SA) : sig functor G1(structure Y: SY where structure A = A) : sig end end = struct functor G1 = F(structure X = struct structure A = A end) end; Transcript: [opening test/bugs/bug1205.sml] signature SA = sig type t end signature SX = sig structure A : sig type t end end signature SY = sig structure A : sig type t end end GC #0.0.0.0.1.5: (0 ms) functor F : test/bugs/bug1205.sml:26.9-32.4 Error: where structure spec not matched: A uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Comments: This bug represents a problem with MLRISC/mlrisc/ra.sml and MLRISC/hppa/hppaRegAlloc.sml and MLRISC/alpha32/alpha32RegAlloc.sml. Fix: In processing structure def specs or where structure defs, lookStrDef has to relativize structures that are local to a functor (such as the functor parameter), turning CONSTstrDefs into VARstrDefs for such local structures. A local version of lookStrDef was defined within ElabSig (which is the only module using Lookup.lookStrDef) that does this relativization. Test: bug1205.sml Owner: dbm, Zhong Status: fixed in 109.31 [dbm, 8/14/97] ---------------------------------------------------------------------- Number: 1206 Title: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h Keywords: modules, functors, TransTypes Submitter: George Russell Date: 5/7/97 Version: 109.28- System: - Severity: major Problem: Compiling the code below (which requires smlnj-lib) causes Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h Code: functor Dictionary (HK:HASH_KEY): sig type 'b dictionary val create: int->'b dictionary end= struct structure Hash=HashTableFn(HK) exception NF type 'b dictionary='b Hash.hash_table fun create i=Hash.mkTable(i,NF) end functor T(S:HASH_KEY)= struct structure U=Dictionary(S) datatype v=v of int U.dictionary fun cre n=v(U.create n) end; structure OP=T(struct type hash_key=Word.word fun hashVal k=k val sameKey=op= end) [Zhong, 5/7/97] I have narrowed your code further down the following (it does not rely on the SML Library any more): functor Dict (type t) : sig type dict end = struct datatype dict = HT of t | NIL type dict = dict (* removing this line, the bug goes away *) end functor T(type t) = struct structure U = Dict(type t = t) datatype s = EE of U.dict | FF val x = FF end; structure A = T(type t = int) Transcript: - use "/usr/local/sml/bugs/tests/bug1206.sml"; [opening /usr/local/sml/bugs/tests/bug1206.sml] functor Dictionary : functor T : Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h uncaught exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:164.40 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Comments: [Zhong, 6/24/97] (* The following is a narrowed-down version of the code. The code raises the following exception: - [opening ztodo/z3.sml] functor T : Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h I managed to track it down and understand that the bug is caused by the incorrect management of "epContext". The scenerio is like this: datatype u is shadowed by another DEFtyc u inside U, so it is not exported by structure U; when we enter structure U, we create a new level of epContext, but when finish processing structure U, this level of epContext is popped off; we do try to recover the epContext binding all the components exported by structure U, but not the shadowed datatype "u". Therefore, when we process datatype s, the type U.u is not properly relativized because the shadowed version of u is not in the epContext. Possible fixes: we have to adjust the "enterClosed" or the "mapEPC" functions to take account these shadowed type bindings. *) functor T(type t) = struct structure U = struct datatype u = HT of t type u = u (* removing this line, the bug goes away *) end datatype s = EE of U.u val x = fn (_: s) => 0 end; structure A = T(type t = int) Fix: Added enterOpenNew and mergeHidden functions to modules/epcontext.sml and called them within function elabStrbs in elaborate/elabmod.sml. The effect is the preserve mappings for local hidden types that won't be found by the call to mapPaths, like the internal datatype u in the above code. Test: bug1206.sml (requires smlnj-lib), bug1206.2.sml Owner: Zhong, dbm Status: fixed in 109.32 (dbm, 7/21/97) ---------------------------------------------------------------------- Number: 1207 Title: unimplemented include syntax Keywords: syntax, parsing, include, signatures Submitter: John Reppy Date: 5/22/97 Version: 109.29 System: - Severity: medium Problem: The syntax for the basic "include" spec is include sigexp (page 14, DSMLR). Only sidids are accepted as arguments now. Comments: The derived form include sigid1 ... sigidn is implemented properly. The derived form does not allow for sigexps. Code: (from Andrew Kennedy) signature SIG = sig datatype d = c include sig type t end where type t = d end; Transcript: Error: Compiler bug: Include: elabInclude Fix: Test: bug1207.sml Owner: dbm Status: fixed in 110 [dbm, 10/25/97] ---------------------------------------------------------------------- Number: 1208 Title: unimplemented strexp syntax Keywords: syntax, parsing, structures Submitter: Dave MacQueen Date: 6/19/97 Version: 109.29 System: - Severity: major Problem: Syntax for structure expressions includes strexp : sigexp (DSMLR, p.13). This isn't implemented. Comments: Fix: Test: Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1209 Title: casting polymorphic functions and abstract types Keywords: cast, polymorphism, abstract types Submitter: Chris Paris Date: 5/28/97 Version: 109.28 System: ? Severity: minor Problem: casting a polymorphic function causes a Compiler bug. A better error message should be generated. Transcript: - fun subst (f : 'a -> unit) = System.Unsafe.cast f (); Error: Compiler bug: Contract: UsageMap on 158 Comments: [Paris] I reworked some of my code, and I believe I have it working in 109.28 now. In response to a comp.lang.ml post I made a while ago, Zhong Shao suggested that the introduction of the FLINT code would change the behavior of the cast function, so that I get to write one evil thing instead of another. The "nicer" approach seems to work in 109.28, though I don't know why my earlier code broke between 27 and 28, since I thought that FLINT has been around for a while now. [Zhong] While FLINT has been around for a few months, it is changing almost every week :-) There are some major differences between 27 and 28, one is the default calling conventions for polymorphic functions --- the result is that it is no longer safe to directly cast a polymorphic function from "'a -> unit" into "unit -> unit". Future compilers will report such "unsafe" uses of cast. For the time being, the compiler does not bother, the CPS optimizer takes the code and complains about "Contract: UsageMap on 158". I'll try to get a fix into 109.29. [jhr] The example where I get this bug involves converting the type (char -> char) -> string -> string to (Word8.word -> Word8.word) -> Word8Vector.vector -> Word8Vector.vector No polymorphism is involved, and the representations of the two types should be the same. [Zhong] There is a bug in 109.28 on representation analysis of values with "abstract types". In this case, Word8Vector.vector is an abstract type created by :> in boot/built-in.sml. I'll try to fix this in 109.29. In general, care must be taken when creating new types using :>. For example, structure V :> sig eqtype vector val create : int -> vector end = struct type vector = string val create = Assembly.A.create_s end representation analysis would think V.vector has type TC_ABS (string) and process it in the same way as other abstract types (with same shapes but different type stamps). A better way to add built-in types such as word8vector is to directly add it into the initial Prim environment. There are no guarantees that values of type T and ABS(T) would have same representations (right now, T and ABS(T) would have same representations if T is "boxed" in a canonical way) Fix: same as fix for 1323? Test: bug1209.sml Owner: Zhong Status: fixed in 110.0.1 [Zhong, 1/7/98] ---------------------------------------------------------------------- Number: 1210 Title: weak pointers to strings cause SML to crash Keywords: weak pointers Submitter: Edo Biagioni, esb@cs.cmu.edu Date: 05/30/1997 Version: 109.27 System: DEC alpha Osf1 V3.2 Severity: minor Transcript: % /afs/cs.cm.edu/project/fox/port/109.27/bin/sml Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM&CMB] val it = () : unit - val a = "foo"; val a = "foo" : string - val b = SMLofNJ.Weak.weak a; val b = - : string ?.weak - SMLofNJ.Internals.GC.doGC 0; 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 Comments: [jhr] Actually, this bug is weak pointers to big objects (aka, code). Heap allocated strings should work okay. This will be fixed when we go to the new array/vector representations. Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1211 Title: signature problems not reported until signature instantiation Keywords: modules, signatures, instantiation Submitter: Norman Ramsey Date: 5/30/97 Version: 109.28 System: - Severity: major Problem: I'm having trouble migrating my code to the new rules for sharing. The error message I get is: control.nw:94.9-94.44 Error: rigid type spec in sharing: item The source code prompting this message is: functor CodeBogus(Code : CODE) = struct end It would be more helpful if - the error message were issued when the CODE signature was compiled - the source locations referred to in the message contained the offending sharing constraint - the README file for 109.28 indicated what error message to expect when the new illegal constructs are used. This way I could correlate the error message with the potential problem. Comments: Fix: Need to instantiate signatures where they are declared to detect these errors at the appropriate point. This could be controlled by a flag that could turn off instantiation when recompiling debugged code. Test: Owner: dbm, Zhong Status: fixed in 109.30 [dbm] ---------------------------------------------------------------------- Number: 1212 Title: where structure when signatures differ Keywords: modules, where structure, SML97 Submitter: Norman Ramsey Date: 5/30/97 Version: 109.28 System: - Severity: major Problem: I am informed: elabexp.nw:32.9...53.4 Error: Inconsistent defining constraints : type item = item I introduced this error by replacing functor ElabExpFun (structure Denotable : DENOTABLE structure DoublePattern : DOUBLE_PATTERN sharing DoublePattern.Normal = Denotable.Pattern val simplify : Denotable.Constructor.Pattern.Exp.exp -> Denotable.Constructor.Pattern.Exp.exp ) : ELAB_EXP = struct ... end with functor ElabExpFun (structure Denotable : DENOTABLE structure DoublePattern : DOUBLE_PATTERN where structure Normal = Denotable.Pattern val simplify : Denotable.Constructor.Pattern.Exp.exp -> Denotable.Constructor.Pattern.Exp.exp ) : ELAB_EXP = struct ... end The replacement was necessary because the two structures have difference signatures and both signatures are full of 'rigid' type definitions (I've forgotten the proper term for these). I have no idea how to track down and diagnose this error. Some more source locations in the error message might help. Comments: Same as bug 1232. Fix: Test: Owner: dbm Status: fixed in 109.30 ---------------------------------------------------------------------- Number: 1213 Title: CM dependency analysis Keywords: CM, dependency Submitter: Andrew Kennedy Date: 6/3/97 Version: 109.28 System: - Severity: major Problem: I don't have sample code for this one; I'm hoping that my vague description will suffice. The situation is that a structure imports another structure but only by way of rebinding e.g. structure STR1 = struct structure STR2 = STR3 .... STR2.x ... end so that STR3 is never used in a qualified identifier. This seems to trick the compilation manager into thinking that STR3 is not referenced in STR1, leading to compilation errors such as "no such structure STR3". However, if one of the qualified identifiers (such as STR2.x above) is replaced by its synonym (STR3.x) then this fixes things. What's more, I can then change it back to STR2.x and the compilation manager seems to `remember' that STR1 referred to STR3. Comments: Fix: Test: Owner: Matthias Status: not reproducible [blume, 8/3/97] ---------------------------------------------------------------------- Number: 1214 Title: Increased make time Keywords: CM, memory usage Submitter: Emden R. Gansner, erg@research.att.com Date: Wed Jun 4 17:35:01 EDT 1997 Version: 109.28 System: Only tested on irix-mips Severity: minor Problem: There seems to be a dramatic increase in make time from 109.27 to 109.28 Code: Transcript: In 109.27, the entire process takes 20 secs and I get something like the following: [dependency analysis completed] GC #3.23.28.47.230.7259: (34 ms) GC #3.23.28.47.231.7305: (29 ms) GC #3.23.28.47.232.7343: (18 ms) GC #3.24.29.48.233.7406: (127 ms) GC #3.24.29.48.234.7455: (9 ms) GC #3.24.29.48.235.7523: (18 ms) GC #3.24.29.48.236.7581: (23 ms) GC #3.24.29.48.237.7657: (19 ms) GC #3.24.29.48.238.7735: (29 ms) [compiling bezier.sml -> CM/mipseb-unix/bezier.sml.bin] In 109.28, the entire process takes 60 secs and I get something like the following: [dependency analysis completed] GC #2.15.16.21.104.6631: (35 ms) GC #2.15.16.21.105.6741: (19 ms) GC #2.15.16.21.106.6841: (10 ms) GC #2.15.16.21.107.6955: (13 ms) GC #2.15.16.21.108.7097: (7 ms) GC #2.15.16.21.109.7242: (5 ms) GC #2.15.16.21.110.7341: (48 ms) GC #2.16.17.22.111.7408: (97 ms) GC #2.16.17.22.112.7417: (1 ms) GC #2.16.17.22.113.7453: (34 ms) GC #2.16.17.22.114.7520: (8 ms) GC #2.16.17.22.115.7586: (42 ms) GC #2.17.18.23.116.7728: (159 ms) GC #3.18.19.24.117.7774: (736 ms) GC #3.18.19.24.118.7816: (37 ms) GC #3.18.19.25.119.7887: (33 ms) GC #3.18.19.25.120.7968: (43 ms) GC #3.18.19.25.121.8107: (31 ms) GC #3.18.19.25.122.8258: (17 ms) GC #3.18.19.25.123.8389: (17 ms) [compiling bezier.sml -> CM/mipseb-unix/bezier.sml.bin] Comments: This was caused by supplying a context entityEnv when building a realization for a closed signature in modules/instantiate.sml. Fix: Test: Owner: dbm Status: fixed in 109.30 ---------------------------------------------------------------------- Number: 1215 Title: Unaligned access messages Keywords: reals, real arrays, alignment Submitter: George Russell Date: 4/3/97 Version: 109.26 System: alpha, OSF4.0 (& probably OSF3.2) Severity: major Problem: Following code produces lots and lots of "Unaligned access . . ." messages. Code: Array.tabulate(500,fn i=>RealArray.array(500,0.0)); Transcript: Comments: [Lal] This bug appears to be garbage collection related. Executing: Array.tabulate(100, fn i=>RealArray.array(500,0.0)); results in a large number of unaligned accesses. However, executing this under: sml @SMLalloc=10M works fine. [jhr, 7/31/97] This is the same as bug 1227, which is fixed in 109.30. Fix: Test: bug1215.sml Owner: Lal, jhr Status: fixed in 109.30 [jhr] ---------------------------------------------------------------------- Number: 1216 Title: curried higher-order functors not accepted Keywords: modules, functors, higher-order functors Submitter: Zhong Shao (shao@cs.yale.edu) Date: April 4, 1997 Version: 109.29 System: all platform Severity: minor Problem: curried higher-order functors not accepted Code: signature SIG = sig end functor F (A : SIG) (B : SIG) = struct end structure V = struct end structure X = F (struct end) (struct end) structure Y = F (structure A = V) (structure B = V); structure Z = F V V ; (* this one is problematic *) Transcript: - signature SIG = sig end functor F : structure V : sig end structure X : sig end structure Y : sig end - stdIn:94.23 Error: syntax error found at ID Comments: Probably this is not a bug. But I was never clear about the currying syntax for higher-order functors. Is the functor application "(F V V)" allowed ? [dbm] Not a bug. Parantheses are required around all functor arguments. Fix: Test: bug1216.sml Owner: dbm Status: not a bug ---------------------------------------------------------------------- Number: 1217 Title: Compiler generates exception [FPRegEA]. Keywords: code generation Submitter: ? Date: 5/1/97 Version: 109.27 System: x86-linux Severity: major Problem: Compiler generates exception [FPRegEA]. Code: val foo = fn x : 'a * 'b => [x] val bar = fn y => foo(y,13) Transcript: Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled] - val foo = fn x : 'a * 'b => [x] val bar = fn y => foo(y,13) ; uncaught exception in compiler: FPRegEA raised at: cps/generic.sml:98.67-98.74 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:191.58 Comments: For the polymorphic function 'foo', because 'x' is put in a list, representation analysis generates special code (governed by a runtime test) that coerces 'x' to its boxed representation if 'x' is a pair of floats. In the cps optimizer, because the call to 'foo' in 'bar' is known, it is inlined. Because the type of 'y' is unknown, the runtime test in 'foo' remains, and the special case code for floating points is not dead. However, the record '(y,13)' is known and the coercion code for floating point attempts to coerce this record to its boxed representation, which causes it to think that '13' can be put in a floating point register. The bug occurs if you attempt to batch compile ml-yacc (i.e. if you cat all the source files and compile as one declaration). Fix: This is speculative, but the representation analysis uses the following idiom, which is not type correct: Lambda alpha. lambda z:alpha. typecase alpha of float => _ => The idiom could be replaced by the following, which is type correct: Lambda alpha. typecase alpha of float => lambda z:float. _ => lambda z:alpha. Comment: [Lorenz, 5/1/97] For what it's worth, this bug appeared in the transition from 109.23 to 109.24, appears (at least) on x86-linux and sparc-solaris, but not on mipseb-unix. [Zhong, 5/1/97] Thanks for the bug report (and also suggestion the fix). This was really bug 1175 in the masterbug list. I have fixed it and will incorporate the fix into 109.28. Test: bug1217.sml Owner: Zhong Status: fixed in 109.28 [Zhong] ---------------------------------------------------------------------- Number: 1218 Title: increase in size of exportFn image Keywords: exportFn, image size Submitter: Nikolaj Bjorner Date: 5/1/97 Version: 109.27 System: ? Severity: major Problem: The size of the image that is exported with 109.27 is significantly higher than with for instance version 108. I made the following tests: Transcript: [108:] structure Test = struct fun dummy(_,[name]) = (print ("Hi I am "^name^"\n")) fun export() = exportFn("/step/sml-108/bin/.heap/hi",dummy) end [109.27:] structure Test = struct fun dummy(name,_) = (TextIO.print ("Hi I am "^name^"\n"); OS.Process.success) fun export() = SMLofNJ.exportFn("/step/sml/bin/.heap/hi",dummy) end The sizes of the exported images were: 108: -rw-rw---- 1 nikolaj 196292 May 1 22:42 hi 109.27 -rw-rw---- 1 nikolaj 500824 May 1 22:38 hi.sparc-solaris For larger executables the situation gets even worse. I reported an image size of more than 35 MB in 109.27 compared to approx 13 MB in 108. Comments: [Zhong, 5/2/97] This difference seems to be caused from changes in the runtime system, as even the image for a null function is about this big. fun export1() = SMLofNJ.exportFn("xxx1", dummy); fun export2() = SMLofNJ.exportFn("xxx2", fn _ => 0); -rw-r--r-- 1 shao systems 449616 May 2 09:38 xxx1.sparc-solaris -rw-r--r-- 1 shao systems 433232 May 2 10:55 xxx2.sparc-solaris I also checked the runtime closures for both the dummy function and the "fn _ => 0" function, they all contain minimum amount of free variables. |> For larger executables the situation gets even worse. I |> reported an image size of more than 35 MB in 109.27 compared |> to approx 13 MB in 108. |> |> Is there any way to improve on this situation? This could be caused by completely different reasons from the previous. Sorry for keeping asking this, but if you can ship us the entire source code, we can probably take a look and narrow the problem down for you. [Nikolaj, 5/20/97] A. -- I was asked if I could provide a more realistic example where the size of the exported image problem showed up in the 109 version. The example directory in eXene (the bricks example) appears to be excellent. With 108: -rw-rw---- 1 nikolaj 1490428 May 20 14:17 /step/sml-108/bin/.heap/bricks With 109.27: -rw-rw---- 1 nikolaj 12978676 May 20 14:21 /step/sml/bin/.heap/bricks.sparc-solaris As we can see, the size of the image is almost 10 times larger for this small eXene example. The size problem seems however not to be an artifact of eXene. I have exported images that are purely ML (that do not use CML) that are much larger than they should be. The fact that I am using an eXene demo is that it was the first and best example that I could find. B. -- I have previously reported problems with CM. I still think there is something fishy about CM. Some of the problems appear to arise when the same files are loaded using different .cm files. If person A has one cm file and person B has a different one that loads different files, and A and B both use SCCS they may see different versions of files that other files depend on. It is typically possible to hack around this so I have not been eager to clarify the source of the problems precisely. C. -- eXene/CML may have some problems running under Linux and over the network. We have just started to port our system to a laptop (IBM thinkpad 760 E). Here the Inbuf appears to die as well as IO exceptions are raised at will. Over the network (phone line) in Inbuf dies. Other applications (emacs,...) do not have these problems. ----------------------------------------------- Below follows the modifications I did to export the images (so you can reproduce it): 109: examples/bricks/sources.cm: Group is cml.cm cml-lib.cm ../../sources.cm util.sml brickview.sml brick.sml wall.sml badbricks.sml export.sml examples/bricks/export.sml: structure Export = struct val tq = Time.fromMilliseconds 20 fun main(name,display::args) = (RunCML.doit(fn ()=>BadBricks.badBricks display,SOME tq); OS.Process.success) fun export() = SMLofNJ.exportFn("/step/sml/bin/.heap/bricks",main) end ----------------------------------------------- 108: examples/bricks/sources.cm: (* sources file for triangle demo *) Group is /step/sml-108/lib/smlnj-lib.cm /step/sml-108/lib/cml.cm /step/sml-108/lib/cml-lib.cm ../../sources.cm util.sml brickview.sml brick.sml wall.sml badbricks.sml export.sml examples/bricks/export.sml: structure Export = struct fun main(env,display::args) = BadBricks.badBricks display fun export() = RunCML.exportFn("/step/sml-108/bin/.heap/bricks",main,SOME 20) end examples/bricks/brickview.sml: This does not compile under 108, so I corrected it with parts from 109. Replaced: fun showText (backc, framec) txt _ = ( Label.setBackground label backc; Label.setLabel label (Label.Text txt); Frame.setColor frame framec; framec) val showView = showText (#concrete palette, SOME(#lightLines palette)) val endView = showText (#brick palette, SOME(#lightLines palette)) val markView = showText (#mark palette, SOME(#darkLines palette)) "ok" val normView = showText (#brick palette, SOME(#darkLines palette)) "" examples/bricks/wall.sml: This does not compile under 108, so I corrected it with parts from 109. Replaced: fun setMsg txt = Label.setLabel msgArea (Label.Text txt) [Zhong, 5/21/97] Hi, Nikolaj, Thanks very much for narrowing down the problem for us. I can reproduce the image size using the following export.sml: structure Export = struct fun export() = SMLofNJ.exportFn("bricks", fn _ => (RunCML.doit (fn () => (), NONE); 0)) end There are definitely wierd thing going on with exportFn. As if I use the following sources.cm file: Group is cml.cm cml-lib.cm ../../sources.cm util.sml brickview.sml brick.sml wall.sml badbricks.sml export.sml I get 12Mbytes image, while if I use this sources.cm file: Group is cml.cm cml-lib.cm export.sml I get only 8.2Mbytes. Even though export.sml does not refer to anything in eXene or brick code at all. Clearly, the closure for RunCML.doit function contains a pointer to all the toplevel environments. Even worse, I am afraid that it contains a pointer to the top-level environment (where code for bricks and eXene stays). This bug occurs also in version 109.16 (with probably 1.2 Mbytes smaller image size, which is the image size difference between sml-cm-109.16 and sml-cm-109.27). John, what are the main differences between 108's RunCML.doit and 109.16's RunCML.doit ? Would the new code possibly hold more free variables ? |> The size problem seems however not to be an artifact of eXene. |> I have exported images that are purely ML (that do not use CML) |> that are much larger than they should be. The fact that I am using |> an eXene demo is that it was the first and best example that I could find. It is possible that the image-size problems for these purely-ML code are caused by different reasons (from the brick example above). We'll continue diagnosing the problem, at the same time, we would very appreciate you send us new (purely-ML) examples if you happen to run into any of them in the future. [Bjorner, 8/7/97] The recent bugfixes in version 109.30 offered some hopes that the heap size bug has been fixed. This appears not to be the case: -rw-rw---- 1 root 14293696 Aug 7 08:38 bricks.sparc-solaris is the 109.30 size of the bricks exported image. Compared with previous sizes this is a clear worsening. [Bjorner, 8/7/97] I have previously communicated with various members of the SML/NJ team on the memory problems in versions 109.**. Desparately trying to track the problem down further in 109.30 (it is really a serious problem for us and others who wish to use SML/NJ images on reasonable hardware) I ran into the following simple scenario that can recreate some weird memory behaviour. I am still a bit frustrated that I am don't have an overview of the source code of SML/NJ which could allow me to track the problem in a more systematic way. What are the documents describing the design of the present compiler? Regards Nikolaj --------------------------------------------- sources.cm: Group is (** (* C *) cml.cm cml-lib.cm **) export.sml -------------------- structure Export = struct val tq = Time.fromMilliseconds 20 fun main(name,display::args) = (** (* A *) (TextIO.print "dummy"; OS.Process.success) **) (** (* B *) (RunCML.doit(fn ()=>(),SOME tq); OS.Process.success) **) fun export() = SMLofNJ.exportFn("dummy",main) end -------------------- 1. To obtain an image of with 318 big objects (9 MB!) uncomment C and B. 2. Then comment B, and uncomment A. This still gives the same image size. 3. Then comment C. This gives 38 big objects, about 0.5 MB (nice and "small"). 4. Then uncomment C. This still gives only 38 big objects, different than point 2 although the CM.sa files look exactly the same! It has been listed below. To narrow the source of the problems down further it should also be possible to recreate the situation with the reference to cml-lib.cm deleted from the sources.cm. This already seems to follow from the CM.sa generate file below. Even when replacing C by: /sml-109.30/src/cml/src/Unix/sources.cm in step 2 I get the 9 MB large image size. In comparison when compiling the following under version 108 I only get 22 big objects ( 0.3 MB). This is the 108 equivalent of step 1 above. sources.cm ---------- Group is /sml-108/lib/cml.cm export.sml export.sml ---------- structure Export = struct val tq = Time.fromMilliseconds 20 fun main(name,display::args) = (RunCML.doit(fn ()=>(),SOME 20);()) fun export() = exportFn("dummy",main) end ------------------------------------------------------ CM.sa for step 1,2,3,4: local open Compiler.CMSA val pervenv = pervenv () val o1 = run ("/step/sml-109.30/src/cml/src/core-cml/rep-types.sml", pervenv) val d0 = layer [o1, pervenv] val o2 = run ("/step/sml-109.30/src/cml/src/core-cml/queue.sml", d0) val o3 = run ("/step/sml-109.30/src/cml/src/core-cml/debug.sml", pervenv) val d1 = layer [o1, o2, o3, pervenv] val o4 = run ("/step/sml-109.30/src/cml/src/core-cml/scheduler.sml", d1) val o5 = run ("/step/sml-109.30/src/cml/src/core-cml/event-sig.sml", pervenv) val d2 = layer [o1, o4, o5, pervenv] val o6 = run ("/step/sml-109.30/src/cml/src/core-cml/event.sml", d2) val d3 = layer [o6, pervenv] val o21 = run ("/step/sml-109.30/src/cml/src/OS/os-io-sig.sml", d3) val o22 = run ("/step/sml-109.30/src/cml/src/OS/os-process-sig.sml", d3) val d4 = layer [o21, o22, pervenv] val o23 = run ("/step/sml-109.30/src/cml/src/OS/os-sig.sml", d4) val d5 = layer [o21, o22, o23, pervenv] val o24 = run ("/step/sml-109.30/src/cml/src/OS/os-signatures.sml", d5) val f0 = filter [SIG "OS", SIG "OS_IO", SIG "OS_PROCESS"] val d6 = f0 o24 val d7 = layer [o1, o4, o6, pervenv] val o13 = run ("/step/sml-109.30/src/cml/src/core-cml/io-manager.sml", d7) val o0 = run ("/step/sml-109.30/src/cml/src/core-cml/version.sml", pervenv) val o7 = run ("/step/sml-109.30/src/cml/src/core-cml/thread-sig.sml", pervenv) val d8 = layer [o1, o4, o6, o7, pervenv] val o8 = run ("/step/sml-109.30/src/cml/src/core-cml/thread.sml", d8) val o9 = run ("/step/sml-109.30/src/cml/src/core-cml/channel-sig.sml", pervenv) val d9 = layer [o1, o2, o4, o6, o8, o9, pervenv] val o10 = run ("/step/sml-109.30/src/cml/src/core-cml/channel.sml", d9) val o11 = run ("/step/sml-109.30/src/cml/src/core-cml/timeout-sig.sml", pervenv) val d10 = layer [o1, o4, o6, o11, pervenv] val o12 = run ("/step/sml-109.30/src/cml/src/core-cml/timeout.sml", d10) val d11 = layer [o5, o7, o9, o11, pervenv] val o14 = run ("/step/sml-109.30/src/cml/src/core-cml/cml-sig.sml", d11) val d12 = layer [o0, o6, o8, o10, o12, o14, pervenv] val o15 = run ("/step/sml-109.30/src/cml/src/core-cml/cml.sml", d12) val d13 = layer [o13, o15, d6, pervenv] val o25 = run ("/step/sml-109.30/src/cml/src/Unix/os-io.sml", d13) val f1 = filter [SIG "OS", STR "OS_Process", SIG "OS_IO", STR "OS_IO", SIG "OS_PROCESS", STR "ProcManager"] val d14 = f1 o25 val d15 = layer [o15, pervenv] val o16 = run ("/step/sml-109.30/src/cml/src/core-cml/sync-var-sig.sml", d15) val d16 = layer [o1, o2, o4, o16, pervenv] val o17 = run ("/step/sml-109.30/src/cml/src/core-cml/sync-var.sml", d16) val d17 = layer [o15, o17, pervenv] val o20 = run ("/step/sml-109.30/src/cml/src/util/result.sml", d17) val d18 = layer [o4, o6, o20, pervenv] val o26 = run ("/step/sml-109.30/src/cml/src/Unix/proc-manager.sml", d18) val d19 = layer [o26, o4, o6, d6, pervenv] val o27 = run ("/step/sml-109.30/src/cml/src/Unix/os-process.sml", d19) val d20 = f1 o27 val d21 = layer [d6, d14, d20, pervenv] val o45 = run ("/step/sml-109.30/src/cml/src/Unix/os.sml", d21) 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"] val d22 = f2 o45 val o32 = run ("/step/sml-109.30/src/cml/src/IO/prim-io-sig.sml", d15) val d23 = layer [o32, o15, pervenv] val o36 = run ("/step/sml-109.30/src/cml/src/IO/prim-io-fn.sml", d23) val d24 = layer [o36, pervenv] val o39 = run ("/step/sml-109.30/src/cml/src/IO/text-prim-io.sml", d24) val o34 = run ("/step/sml-109.30/src/cml/src/IO/cml-text-stream-io-sig.sml", d15) val d25 = layer [o34, o39, o15, pervenv] val o40 = run ("/step/sml-109.30/src/cml/src/IO/cml-text-io-sig.sml", d25) val d26 = layer [o32, pervenv] val o41 = run ("/step/sml-109.30/src/cml/src/IO/os-prim-io-sig.sml", d26) val o18 = run ("/step/sml-109.30/src/cml/src/core-cml/mailbox-sig.sml", d3) val d27 = layer [o1, o4, o18, pervenv] val o19 = run ("/step/sml-109.30/src/cml/src/core-cml/mailbox.sml", d27) val d28 = layer [o32, o15, o17, o19, pervenv] val o43 = run ("/step/sml-109.30/src/cml/src/IO/chan-io-fn.sml", d28) val d29 = layer [o39, o40, o41, o43, o15, o17, pervenv] val o44 = run ("/step/sml-109.30/src/cml/src/IO/text-io-fn.sml", d29) val o37 = run ("/step/sml-109.30/src/cml/src/IO/bin-prim-io.sml", d24) val d30 = layer [o45, o4, pervenv] val o46 = run ("/step/sml-109.30/src/cml/src/Unix/syscall.sml", d30) val d31 = layer [o45, o46, o13, o15, o17, o37, o41, pervenv] val o47 = run ("/step/sml-109.30/src/cml/src/Unix/posix-bin-prim-io.sml", d31) val d32 = layer [o47, o15, o17, o39, o41, pervenv] val o49 = run ("/step/sml-109.30/src/cml/src/Unix/posix-text-prim-io.sml", d32) val d33 = layer [o49, o44, pervenv] val o50 = run ("/step/sml-109.30/src/cml/src/Unix/posix-text-io.sml", d33) val d34 = f2 o50 val d35 = layer [d22, d34, pervenv] val o153 = run ("export.sml", d35) in val _ = register o153 end Fix: Optimization to lift structure references out of closures restored (it had been dropped in 109.24). Isolate function fixed. CML version of exportFn cleaned up. Test: Owner: Zhong, jhr Status: fixed in 109.31 [jhr, Zhong, 9/15/97] ---------------------------------------------------------------------- Number: 1219 Title: sml crashes while trying to print Keywords: printing, representations Submitter: Chris Paris Date: 5/5/97 Version: 109.27 System: sparc/solaris 5.5, mipseb Severity: major Problem: Printing datatype values involving ints and words causes segmentation faults. Transcript: Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled] - datatype id = ID of Int32.int; datatype id = ID of int32 - ID (Int32.fromInt 0); Segmentation fault Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled] - datatype id = ID of int32; datatype id = ID of int32 - ID (0 : int32); Segmentation fault Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled] - datatype id = ID of Word32.word; datatype id = ID of word32 - ID (Word32.fromInt 0); Segmentation fault Comments: Fix: Test: bug1219.sml Owner: Zhong Status: fixed ---------------------------------------------------------------------- Number: 1220 Title: type definition masks datatype Keywords: modules, signature matching, datatypes Submitter: Zhong Shao Date: 5/7/97 Version: 109.29 System: - Severity: minor Problem: Is the following legal sml ? structure A : sig datatype t = HT end = struct datatype t = HT type t = t end Our compiler complains that z2.sml:1.1-4.6 Error: type t must be a datatype z2.sml:1.1-4.6 Error: unmatched type specification: t uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Changing it to the following works as expected: structure A : sig datatype t = HT end = struct datatype t = HT datatype t = datatype t end Code: Transcript: Comments: Check whether this is legal. Fix: Test: Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1221 Title: type inference of literals is quirky Keywords: type inference, literals Submitter: Perry Cheng; pscheng@cs.cmu.edu Date: 5/9/97 Version: 109.25, 109.29 System: alpha DEC UNIX 3.2 Severity: minor Problem: The type of word literals seems to fail when they occur in top-level bindings inside a structure. Transcript: - let val ten = 0w10 val y = Word32.div(ten,ten) in y end; val it = 0wx1 : Word32.word - structure X = struct val ten = 0w10 val y = Word32.div(ten,ten) end; stdIn:270.21-277.4 Error: operator and operand don't agree (tycon mismatch) operator domain: Word32.word * Word32.word operand: word * word in expression: Word32.div (ten,ten) Comments: This is not a bug because of the way literal overloading is resolved in let expressions vs within structures. The overloading is resolved at each structure element declaration, meaing that the type of ten in structure X will default to Word.word, not Word32.word. In the let expression the resolution of the type of ten is not done until after the body is typed. Fix: Test: bug1221.sml Owner: dbm Status: not a bug ---------------------------------------------------------------------- Number: 1222 Title: ref assignment not performed before overflow Keywords: Submitter: Lorenz Huelsbergen (lorenz@research.bell-labs.com) Date: 5/27/97 Version: 109.28 System: mipseb-irix5 (but not sparc-solaris) Severity: major Problem: ref assignment not performed before overflow Code: val x = ref 0; fun f n : unit = (x := !x + 1; f (n+1)); f (valOf Int.maxInt); x; (* should be 1 *) Transcript: - : canna.research.bell-labs.com 178; Standard ML of New Jersey, Version 109.28, May 23, 1997 [new runtime] - val x = ref 0; val x = ref 0 : int ref - fun f n : unit = (x := !x + 1; f (n+1)); = = val f = fn : int -> unit - ; - f (valOf Int.maxInt); uncaught exception Overflow [overflow] - x; (* should be 1 *) val it = ref 0 : int ref - Comments: Appears to be work properly on sparc. Fix: The problem is caused by the following CPS fragment generated by unrolling f a couple of times: f772(v785[I],v784[PV]) = !(v784) -> v698[PV] .. 1 +i31(v698,(I)1) -> v710[I] .. 2 unboxedupdate(v784,(I)0,v710) .. 3 +i31(v785,(I)1) -> v740[I] .. 4 !(v784) -> v758[PV] .. 5 +i31(v758,(I)1) -> v759[I] .. 6 unboxedupdate(v784,(I)0,v759) .. 7 +i31(v740,(I)1) -> v760[I] .. 8 (L)f772(v760,v784) .. 9 In mips/mipsdepend.sml the use/def information associated with trapping add is given by: fun arith_ud(rd,rs,ea) = (exnptr::(reg rs @ arithOpndUse ea), reg rd) The problem with this, is that there is no dependence of any kind with memory. Thus there is nothing preventing (trapping) instruction 4 from being scheduled before 3. [I cannot believe that we haven't tripped this bug earlier.] It doesn't matter what kind of dependency is introduced so I think I prefer to create a regular data dependency and define arith_ud as: fun arith_ud(rd,rs,ea) = (mem::exnptr::(reg rs @ arithOpndUse ea), reg rd) This essentially says that the trapping instruction will use memory on a trap. A similar consideration should be made with arith3_ud and mult_ud. -- Lal Test: Owner: Status: fixed in 109.31 [Lal, 8/18/97] ---------------------------------------------------------------------- Number: 1223 Title: Compiler bug: ModuleUtil: strId after unbound structure in functor Keywords: modules, unbound identifier, secondary error Submitter: Chris Paris (cap@cs.cmu.edu) Date: 6/15/97 Version: 109.29 System: - Severity: minor Problem: Unbound structure identifier in a functor body leads to "Compiler bug: ModuleUtil: strId". Code: functor A () = struct structure B = B end; Transcript: Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled] - functor A () = struct structure B = B end; stdIn:17.37 Error: unbound structure: B Error: Compiler bug: ModuleUtil: strId Comments: Fix: Test: bug1223.sml Owner: Zhong Status: fixed in 109.31 [Zhong, 8/14/97] ---------------------------------------------------------------------- Number: 1224 Title: representation foulup Keywords: data representation Submitter: Chris Paris Date: 6/15/97 Version: 109.28? System: ? Severity: major Problem: Execution gives wrong answers or core dumps. Code: structure T = struct datatype 'a pref = PREF of {obj : 'a} fun apply (PREF {obj}, arg) = obj arg fun f ((x, y), z) = y fun s () = apply (PREF {obj=f}, (("one", "two"), "three")) fun t () = apply (PREF {obj=f}, (("one", "two"), ())) end; T.s(); T.t(); Transcript: - T.s(); val it = "three" : string (* should be "two" *) - T.t(); Bus error (* tries to print a unit as a string? *) Comments: [Paris] Something interesting happens if I change the definition of f to fun f ((x, y), z) = x Then we get - T.s(); val it = "\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#" : string And if f is fun f ((x, y), z) = z, then the file doesn't compile: - use "test.sml"; [opening test.sml] uncaught exception Lookup raised at: cps/nclosure.sml:384.49-384.62 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 Fix: Test: bug1224.sml Owner: Zhong Status: fixed in 109.30 [Zhong] ---------------------------------------------------------------------- Number: 1225 Title: SMLofNJ.Internals.GC.doGC doesn't work Keywords: garbage collection, runtime Submitter: Christoph Kern Date: 06/18/97 Version: Version 109.28, May 23, 1997 System: sparc-solaris (probably any) Severity: minor Problem: SMLofNJ.Internals.GC.doGC x doesn't cause a collection, regardless of the value of x. Fix: --- src/runtime/c-libs/smlnj-runtime/gc-ctl.c.orig Wed Jun 18 14:11:03 1997 +++ src/runtime/c-libs/smlnj-runtime/gc-ctl.c Wed Jun 18 14:12:51 1997 @@ -86,7 +86,7 @@ PVT void DoGC (ml_state_t *msp, ml_val_t arg) { heap_t *heap = msp->ml_heap; - int level = INT_MLtoC(arg); + int level = INT_MLtoC(DEREF(arg)); if (level < 0) level = 0; Comment [jhr] I think you are right. What is happening is that the ref cell's address is a negative number on the sparc, but is a (large) positive number on the SGI. When you call doGC, it only does a minor collection, whereas, when I call it, it always collects all generations. I've applied your patch, and it will be in 109.30. Thanks. Test: * Owner: jhr Status: fixed in 109.30 ---------------------------------------------------------------------- Number: 1226 Title: Ctrl-C no longer works on Alpha Keywords: signals, interrupt Submitter: Andrew.Kennedy@persimmon.co.uk Date: 6/17/97 Version: 109.29 System: Alpha Severity: critical Problem: Ctrl-C does not interrupt compilation or execution Comments: [George Russell , 6/23/97] This is more about a problem reported by Andrew Kennedy, that SML109.29 on Digital Unix 4 does not respond to /C. I can now report that it also does not respond to kill -2 [process id] (IE sending SIGINT to it). However SML109.29 on Digital Unix 3.2, and SML109.28 on Digital Unix 4, both do respond to kill -2. [jhr, 6/23/97] We have not been able to reproduce these problems on our Unix 4.0 Alpha, so we will need your help in tracking this down. Please try the following experiment: cd src/runtime/objs make -f mk.alpha32-dunix BASE_DEFS="-DSIGNAL_DEBUG" run.alpha32-dunix @SMLload=../../../bin/.heap/sml (* and then try your ^C at the SML prompt *) Another thing to try (you might do this first) is typing Signals.inqHandler Signals.sigINT; at the prompt. This should return val it = HANDLER fn : sig_action Let me know what you find out. [jhr, 6/23/97] In message <33AE614D.41C6@persimmon.co.uk>, George Russell writes: > > Test #1 - Ctrl/C does nothing. I'll keep this SML session going in > case there's anything else you want me to try. > > Test #2 yields > val it = IGNORE : sig_action > !! > But for 109.28 and 109.29 on 3.2 it does what you say it should do. Then the explanation is quite simple. When SML starts up, it checks the status of signals that it inherits from its parent process; if the status is SIGING, then it doesn't install a handler. This behavior is necessary to get sml to work properly as a background process (or under nohup). Why you see different behavior between 109.28 and 109.29, I have no idea, but I think that the problem is in your shell environment. [jhr, 7/14/97] not a bug --- sml was built in a non interactive shell. Owner: jhr, Lal Status: not a bug ---------------------------------------------------------------------- Number: 1227 Title: Unaligned access generated from floating-point arrays Keywords: arrays, reals Submitter: Perry Cheng (pscheng@cs.cmu.edu) Date: 6/26/97 Version: 109.28 System: Alpha OSF/1 3.2 Severity: major Problem: Floating point array manipulations cause unaligned accesses. Code: The following program computes FFTs at sizes 16, 32, ..., 65536. The code comes from a CAML-Lite distribution. local val sin = Real.Math.sin val cos = Real.Math.cos open Array fun abs_real(x:real) = if x < 0.0 then ~x else x fun print_real (x:real) = print(Real.toString x) (* $Id: bugs.1201-1400 1314 2003-03-20 23:09:51Z macqueen $ *) val pi = 3.14159265358979323846 val tpi = 2.0 * pi fun for(start,stop,f) = let fun loop i = if i > stop then () else (f i; loop (i+1)) in loop start end val print_string : string -> unit = print val print_int : int -> unit = print_string o Int.toString val print_newline : unit -> unit = fn _ => print_string "\n" fun dump pxr pxi = for(0,15,fn i => (print_int i; print " "; print_real (sub(pxr,i+1)); print " "; print_real (sub(pxi,i+1)); print_newline())) fun fft px py np = let val i = ref 2 val m = ref 1 val _ = while (!i < np) do (i := !i + !i; m := !m + 1) val n = !i in if n <> np then ( for (np+1,n,fn i=> (update(px,i,0.0); update(py,i,0.0))); print_string "Use "; print_int n; print_string " point fft"; print_newline() ) else (); let val n2 = ref(n+n) in for(1,!m-1,fn k => let val _ = n2 := !n2 div 2 val n4 = !n2 div 4 val e = tpi / (real (!n2 )) in for(1,n4,fn j => let val a = e * real(j - 1) val a3 = 3.0 * a val cc1 = cos(a) val ss1 = sin(a) val cc3 = cos(a3) val ss3 = sin(a3) val is = ref j val id = ref(2 * !n2) in while !is < n do let val i0r = ref (!is) in while !i0r < n do let val i0 = !i0r val i1 = i0 + n4 val i2 = i1 + n4 val i3 = i2 + n4 val r1 = sub(px,i0) - sub(px,i2) val _ = update(px,i0,sub(px,i0) + sub(px,i2)) val r2 = sub(px,i1) - sub(px,i3) val _ = update(px,i1,sub(px,i1) + sub(px,i3)) val s1 = sub(py,i0) - sub(py,i2) val _ = update(py,i0,sub(py,i0) + sub(py,i2)) val s2 = sub(py,i1) - sub(py,i3) val _ = update(py,i1,sub(py,i1) + sub(py,i3)) val s3 = r1 - s2 val r1 = r1 + s2 val s2 = r2 - s1 val r2 = r2 + s1 in update(px,i2,r1*cc1 - s2*ss1); update(py,i2,~s2*cc1 - r1*ss1); update(px,i3,s3*cc3 + r2*ss3); update(py,i3,r2*cc3 - s3*ss3); i0r := i0 + !id end; is := 2 * !id - !n2 + j; id := 4 * !id (* ; dump px py *) end end) end) end; (************************************) (* Last stage, length=2 butterfly *) (************************************) let val is = ref 1 val id = ref 4 in while !is < n do let val i0r = ref (!is) in while !i0r <= n do let val i0 = !i0r val i1 = i0 + 1 val r1 = sub(px,i0) val _ = update(px,i0,r1 + sub(px,i1)) val _ = update(px,i1,r1 - sub(px,i1)) val r1 = sub(py,i0) in update(py,i0,r1 + sub(py,i1)); update(py,i1,r1 - sub(py,i1)); i0r := i0 + !id end; is := 2 * !id - 1; id := 4 * !id end end; (* print "\nbutterfly\n"; dump px py; *) (*************************) (* Bit reverse counter *) (*************************) let val j = ref 1 in for (1,n-1,fn i => (if i < !j then ( let val xt1 = sub(px,!j) val xt2 = sub(px,i) val _ = update(px,!j,xt2) val _ = update(px,i,xt1) val yt1 = sub(py,!j) val yt2 = sub(py,i) in update(py,!j,yt2); update(py,i,yt1) end) else (); let val k = ref(n div 2) in while !k < !j do (j := !j - !k; k := !k div 2); j := !j + !k end)); (* print "\nbit reverse\n"; dump px py; *) n end end; fun test np = (print_int np; print_string "... "; let val enp = real np val npm = np div 2 - 1 val pxr = array ((np+2), 0.0) val pxi = array ((np+2), 0.0) val t = pi / enp val _ = update(pxr,1,(enp - 1.0) * 0.5) val _ = update(pxi,1,0.0) val n2 = np div 2 val _ = update(pxr,n2+1,~0.5) val _ = update(pxi,n2+1,0.0) in for (1,npm,fn i => let val j = np - i val _ = update(pxr,i+1,~0.5) val _ = update(pxr,j+1,~0.5) val z = t * (real i) val y = ~0.5 * (cos(z)/sin(z)) in update(pxi,i+1,y); update(pxi,j+1,~y) end); (* print "\n"; print "before fft: \n"; dump pxr pxi; *) fft pxr pxi np; (* print "\n"; print "after fft: \n"; dump pxr pxi; *) let val zr = ref 0.0 val zi = ref 0.0 val kr = ref 0 val ki = ref 0 in for (0,np-1,fn i => let val a = abs_real(sub(pxr,i+1) - (real i)) in if !zr < a then (zr := a; kr := i) else (); let val a = abs_real(sub(pxi,i+1)) in if !zi < a then (zi := a; ki := i) else () end end); let val zm = if abs_real (!zr) < abs_real (!zi) then !zi else !zr in print_real zm; print_newline() end end end) fun doit() = let val np = ref 16 in for(1,13,fn i => (test (!np); np := (!np)*2)) end in val _ = doit() end Transcript: Standard ML of New Jersey, Version 109.28, May 23, 1997 [CM&CMB] val it = () : unit - use "/afs/cs/user/pscheng/bug.sml"; [opening /afs/cs/user/pscheng/bug.sml] GC #0.0.0.0.1.6: (10 ms) GC #0.0.0.0.2.24: (14 ms) GC #0.0.0.1.3.40: (23 ms) GC #0.0.0.1.4.51: (16 ms) GC #0.0.1.2.5.60: (55 ms) GC #0.0.1.3.6.96: (12 ms) GC #0.0.1.3.7.120: (23 ms) 16... 8.881784197e~16 32... 3.5527136788e~15 64... 1.06581410364e~14 128... 2.84217094304e~14 256... 5.68434188608e~14 512... 1.16795462191e~13 1024... GC #0.0.1.4.8.130: (1 ms) Unaligned access pid=1001 va=31c205c pc=2b439f4 ra=2b43994 type=stt Unaligned access pid=1001 va=31c2064 pc=2b43a28 ra=ffffffffffffffff type=stt Unaligned access pid=1001 va=31c206c pc=2b439f4 ra=ffffffffffffffff type=stt Unaligned access pid=1001 va=31c2074 pc=2b43a28 ra=ffffffffffffffff type=stt Unaligned access pid=1001 va=31c207c pc=2b439f4 ra=ffffffffffffffff type=stt Unaligned access pid=1001 va=31c2084 pc=2b43a28 ra=ffffffffffffffff type=stt Unaligned access pid=1001 va=31c208c pc=2b439f4 ra=ffffffffffffffff type=stt Comments: This works correctly in 109.25. [Zhong, 6/26/97] This seems to be an Alpha-specific bug, as the above code work fine on my SPARC. Do we align all floating-point numbers on Alpha ? [jhr, 6/26/97] I suspect that it must be a bug in the code generator. The run-time system and garbage collector aligns all real and real array objects on 64-bit boundries on all machines. BTW, I hope this code is not being used for benchmarking. It uses int refs to do iteration, instead of the more natural (and more efficient) tail recursive form. [Lal, 6/29/97] The bug is in the runtime system, in the routine runtime/gc/ml-object.c:ML_AllocRealdarray. If garbage collection is invoked there is no guarantee that the next word in the STRING arena is properly aligned. ------ ml_val_t ML_AllocRealdarray (ml_state_t *msp, int len) { int nwords = DOUBLES_TO_WORDS(len); if (nwords > SMALL_OBJ_SZW) { arena_t *ap = msp->ml_heap->gen[0]->arena[STRING_INDX]; BEGIN_CRITICAL_SECT(MP_GCGenLock) #ifdef ALIGN_REALDS /* Force REALD_SZB alignment (descriptor is off by one word) */ ap->nextw = (ml_val_t *)((Addr_t)(ap->nextw) | WORD_SZB); #endif IFGC (ap, (WORD_SZB*(nwords + 1))+msp->ml_heap->allocSzB) { /* we need to do a GC */ ap->reqSizeB += WORD_SZB*(nwords + 1); RELEASE_LOCK(MP_GCGenLock); InvokeGC (msp, 1); ACQUIRE_LOCK(MP_GCGenLock); } *(ap->nextw++) = desc; <<<<<< not aligned. res = PTR_CtoML(ap->nextw); ap->nextw += nwords; ---- A crude fix to get you going is to replicate the #ifdef ALIGN_REALDS ... #endif just before the line containing: *(ap->nextw++) = desc; <<<<<< not aligned. p.s. This bug manifested on the HPPA, and this fix solved the problem. I have not tested this on the alpha, so please let me know if it works on the alpha as well. Thanks. Fix: Test: Owner: Lal, jhr Status: fixed in 109.30 ---------------------------------------------------------------------- Number: 1228 Title: various Real functions on Alpha Keywords: Floating point, Real Submitter: Andrew.Kennedy@persimmon.co.uk, George Russell Date: 7/7/97 Version: 109.29 System: Alpha, OSF 4.0 Severity: Minor Problem: 1. Real.ceil and Real.floor cause segmentation fault on reals whose integer equivalent is out of range 2. Real.signBit (~0.0); returns false on both Alpha/OSF 4.0 and Linux/i386. 3. Real.fromManExp{exp=0,man=1.5}; causes SML/NJ 109.29 to hang forever (well, 8 GCs so far and counting) on Alpha/Digital Unix 4 and i686/Linux 4. Real.toManExp(1.0); returns {exp=0,man=1.0} for both Alpha/Digital Unix 4.0 and Linux/i686. However by my version of the standard this is wrong because we should have 0.5<=man<1.0. The correct answer is {exp=1,man=0.5}. The local version of frexp gets this right, incidentally. 5. Real.isNormal 0.0 ought to return false. Code: Real.floor 1073741824.0 Transcript: Comments: [Kennedy] NB Real.ceil 1073741823.1 correctly raises Overflow [jhr, 7/7/97] > Real.signBit (~0.0); > returns false on both Alpha/OSF 4.0 and Linux/i386. Actually, this is a feature of the IEEE 754-1985 specification. The negation of zero is negative zero, only when the rounding mode is set to TO_NEGINF. I don't know if the SML specification says anything about how the literal ~0.0 should be interpreted (is it the same as Real.~(0.0) in default rounding mode)? [appel, 9/17/97] No, this is not true. The IEEE specification calls for the negation of 0.0 to be ~0.0 regardless of rounding mode. [jhr, 7/7/97] I've tried the various FP bugs on canna, and here is some more info: 1) The Real.floor and Real.ceil of 1073741824.0 work correctly. This is probably a bug in the assembly code for floor. 2) Real.signBit(~0.0) returns false, but Real.signBit(0.0/ ~1.0) returns true. This is probably not a bug, but a feature of the IEEE specification. 3) Real.fromManExp{exp=0,man=1.5} goes to lunch on the MIPS too. I suspect this is a bug in the Real.fromManExp function (written by Andrew, I think). Fix: [for which part?] [Lal, 7/7/97] Thanks for the bug report. In the file src/runtime/mach-dep/ALPHA32-prim.asm there are two labels called floor_overflow that require a trapb instruction at the end. The first floor_overflow label should look like: floor_overflow: ldl ATMP1, ovfl_MAXINT addlv ATMP1, ATMP1, ATMP1 trapb and the second should look like: floor_overflow: addq $30, 16, $30 ldl ATMP1, ovfl_MAXINT addlv ATMP1, ATMP1, ATMP1 trapb The stack deallocation must be added to the second label as well. Making this change and recompiling the runtime system fixes this problem. Test: * Owner: jhr, Lal Status: fixed in 109.31 [Lal, Andrew] ---------------------------------------------------------------------- Number: 1229 Title: Bugs in unionWith, unionWithi of smlnj-lib Keywords: smlnj-lib, binary-set-map Submitter: Yasuhiko Minamide, nan@kurims.kyoto-u.ac.jp Date: 7/11/1997 Version: 109.29 System: any Severity: minor Problem: The behaviour of unionWith and unionWithi of smlnj-lib seems wrong. Code: let open IntBinaryMap val x = insert (insert (empty, 1,1), 2, 2) val y = insert (empty, 1, 0) val z = unionWith (fn (x,y) => x) (x, y) in listItemsi z end Transcript: The code above returns val it = [(1,0),(2,2)] : (int * int) list I think that this should be val it = [(1,1),(2,2)] : (int * int) list Test: * Owner: jhr Status: fixed in 109.30 [jhr, 7/14/97] ---------------------------------------------------------------------- Number: 1230 Title: bus-error due to representation problem Keywords: bus-error Submitter: manuel@cs.berkeley.edu Date: July 12 Version: 109.26 and 109.29 System: Solaris Ultrasparc and Linux i686 Severity: severe Problem: Small test program crashes sml process Code: signature CONS = sig type 'a sign type 'a constructor val new : {name : string, signa : 'a sign} -> 'a constructor end structure Cons : CONS = struct datatype sort = SUB | CSUB datatype datacon = DCON of {name : string, arity : int, sign : sort list, sort : sort, strict : bool} type 'a constructor = datacon type 'a sign = {sign : sort list, sort : sort, strict : bool} fun new {name,signa={sign,sort,strict}} = DCON {name=name, arity=List.length sign, sign=sign, sort=sort, strict=strict } end Transcript: [Solaris,UltraSparc] Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled] - [opening /tmp/mla002oZ] signature CONS = sig type 'a sign type 'a constructor val new : {name:string, signa:'a sign} -> 'a constructor end structure Cons : CONS? val it = () : unit - Cons.new; Process sml bus error [Linux i686] Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled] use "/tmp/mla32088";^M - [opening /tmp/mla32088] signature CONS = sig type 'a sign type 'a constructor val new : {name:string, signa:'a sign} -> 'a constructor end structure Cons : CONS? val it = () : unit - Cons.new; /disks/orodruin/aa/home/manuel/Projects/sml-109.26/bin/.run/run.x86-linux: Fatal error --\ unexpected fault, signal = 11, code = 0x4081346b Process sml exited abnormally with code 1 Comments: I tried to make the example as short as possible. It seems important that the datatype DCON have at least 5 fields in the record, and that new takes 2 arguments. Fix: Test: bug1230.sml Owner: Zhong Status: fixed in 109.30 [Zhong] ---------------------------------------------------------------------- Number: 1231 Title: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo Keywords: secondary error, error recovery Submitter: manuel@cs.berkeley.edu Date: July 12 Version: 109.29 System: Solaris Ultrasparc Severity: severe Problem: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo Code: signature CONS = sig type 'a sign type 'a constructor val new : {name : string, signa : 'a sign} -> 'a constructor end structure Cons : CONS = struct datatype sort = SUB | CSUB datatype datacon = DCON of {name : string, arity : int, sign : sort list, sort : sort, strict : bool} type 'a constructor = datacon datatype 'a sign = Sign of {sign : sort list, sort : sort, strict : bool} fun new {name,signa=Sign{sign,sort,strict}} = DCON {name=name, arity=List.length sign, sign=sign, sort=sort, strict=strict } end signature B = sig structure Cons : Cons end structure B :> B = struct structure Cons = Cons end Transcript: Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled] - [opening /tmp/mla002oZ] /tmp/mla002oZ:39.2-40.5 Error: unbound signature: Cons Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo uncaught exception Error raised at: util/errormsg.sml:51.14-51.19 modules/sigmatch.sml:807.24 elaborate/elabmod.sml:1039.8 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 - Comments: Fix: Test: bug1231.sml Owner: Zhong Status: fixed in 109.30 ---------------------------------------------------------------------- Number: 1232 Title: consistent definitional specs seen as inconsistent Keywords: modules, signatures, definitional specs, where definitions Submitter: Norman Ramsey Date: 6/19/97 Version: 109.29 System: - Severity: major Problem: Definitional specs are rejected as inconsistent when they are not. Code: signature SIG1 = sig type t = int end signature SIG2 = sig structure N : SIG1 end functor Bad(structure X : SIG1 structure Y : SIG2 where N = X) = struct end; Transcript: - use "foo.sml"; [opening foo.sml] foo.sml:11.9-13.11 Error: Inconsistent defining constraints : type t = t uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:193.58 build/evalloop.sml:285.46-285.49 Comments: Confusing error message too. Fix: Remove consistency checking for multiple definitions in Instantiate.builtTycClass.constrain when one or both definitions are not instantiated (NOTINST tyc). Test: bug1232.sml Owner: dbm Status: fixed in 109.30 [dbm, 7/16/97] ---------------------------------------------------------------------- Number: 1233 Title: funny printing of multiple bindings in a declaration Keywords: printing, duplicate binding Submitter: Walid Taha Date: 7/16/97 Version: 109.29 System: - Severity: minor Problem: The top level prints an odd message when a value variable is bound twice in a declaration. Transcript: - val c = 1 val c = 2; val c = : int val c = 2 : int Comments: It would be preferable to just print val c = 2 : int as the result of the declaration. Fix: Test: bug1233.sml Owner: Zhong? Status: open ---------------------------------------------------------------------- Number: 1234 Title: EntityEnv.Unbound raised in functor application Keywords: modules, translation, hidden types Submitter: Dave MacQueen Date: 7/21/97 Version: 109.30 (+ bug 1206 fix) System: - Severity: major Problem: EntityEnv.Unbound exception raised in function specLty when compiling legal functor application. Code: functor F(type t val x : t) = struct structure U : sig type u val y : u end = struct datatype u = K of t type u = u list val y = [K x] end val z = hd U.y end; structure A = T(type t = int val x = 3); Transcript: - use "bug1234.sml"; [opening bug1234.sml] functor F : uncaught exception Unbound raised at: translate/transmodules.sml:79.33-79.43 util/stats.sml:164.40 build/evalloop.sml:193.58 build/evalloop.sml:285.46-285.49 Comments: [dbm] This is after incorporating the fix for bug 1206. If the signature on U is removed, the code works. Looking at the functor representation and the bad entityEnv with debugging on, it looks like signature matching is introducing an extra level of structure nesting. The path to the hidden datatype u should be of length 2, but in the entityEnv, the datatype is nested inside an extra intermediate structure, so the length two path doesn't reach it. I presume that sigmatch is creating the extra intermediate structure level. Fix: Test: bug1234.sml Owner: dbm, Zhong Status: Fixed in 109.31 [Zhong] ---------------------------------------------------------------------- Number: 1235 Title: Argument type constraint changes behavior of a function Keywords: types Submitter: Sam Kamin, s-kamin@uiuc.edu Date: 7/21/97 Version: Version 109.29, June 13, 1997 [CM&CMB] System: sparc-solaris, don't know what version offhand Severity: major Problem: Function defined as fun f x = ... type-checks, but then crashes. When defined as fun f (x:T) = ..., it works fine. Code: I'm not going to send enough to reproduce the error, because it's too much. If this turns out to be an interesting problem, I can send it. Anyway, the specific problem is demonstrated in this function: fun mkseqlist seqop [] = empty | mkseqlist seqop [p:Picture] = p | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps); If the ":Picture" in the second clause is omitted, the function type-checks but crashes when used. Transcript: In this transcript, "seq" is an infix operator. As I said, I haven't come up with a simpler example, and I don't think you want all the code (especially not if this turns out to be something simple). - fun mkseqlist seqop [] = empty | mkseqlist seqop [p] = p | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps); = = val mkseqlist = fn : ((('a -> string) * Environment) * (('a -> string) * Environment) -> ('a -> string) * Environment) -> (('a -> string) * Environment) list -> ('a -> string) * Environment - val seqlist = mkseqlist (op seq); val seqlist = fn : ((GraphicsContext -> string) * Environment) list -> (GraphicsContext -> string) * Environment - draw (seqlist [text "a"]) "test"; ~2.34725596609e228, ~2.34705354077e228 uncaught exception Overflow [overflow] - fun mkseqlist seqop [] = empty | mkseqlist seqop [p:Picture] = p | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps); = = val mkseqlist = fn : (Picture * ((GraphicsContext -> string) * Environment) -> (GraphicsContext -> string) * Environment) -> Picture list -> (GraphicsContext -> string) * Environment - val seqlist = mkseqlist (op seq); val seqlist = fn : Picture list -> (GraphicsContext -> string) * Environment - draw (seqlist [text "a"]) "test"; 1.0, 0.0(1.0, 1.0)(0.0, 0.0)val it = () : unit - Comments: I'm not sure if this is really a bug, but it seems to me that adding type declarations is not supposed to matter. And it's a heck of a difficult error to track down. Fix: Test: ? Owner: Zhong Status: fixed in 109.30 ---------------------------------------------------------------------- Number: 1236 Title: TextIO.outputSubstr doesn't work on substrings containing \n Keywords: IO, TextIO, outputSubstr Submitter: Konrad.Slind@cl.cam.ac.uk Date: 7/23/97 Version: 109.30 System: sparc/solaris 2.5.5 Severity: major Problem: TextIO.outputSubstr doesn't seem to handle substrings with "\n" in them. For example: - TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n")); val it = () : unit This behaviour contradicts the description in the basis documentation. Code: TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n")); Comments: Fix: Test: bug1236.sml Owner: jhr, erg Status: fixed in 109.32 [jhr, 7/24/97] ---------------------------------------------------------------------- Number: 1237 Title: ml-yacc doesn't handle constructors with long names Keywords: ml-yacc, constructor names Submitter: Konrad.Slind@cl.cam.ac.uk Date: 7/23/97 Version: 109.30 System: - Severity: major Problem: ml-yacc emits bogus string literals from constructors with long names. The following input will generate a file where, on about line 104, a mangled string literal is produced. Code: %% %term I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild | EOLEX | EOF %nonterm START of unit %start START %eop EOF EOLEX %pos int %header (functor ELrValsFun (structure Token : TOKEN)) %name E %noshift EOF %pure %% START : I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild() Transcript: Comments: Fix: Test: Owner: appel Status: fixed in 109.32 ---------------------------------------------------------------------- Number: 1238 Title: Elaboration error involving where structure Keywords: where structure Submitter: Perry Cheng (pscheng@cs.cmu.edu) Date: 7/23/97 Version: 109.30 System: Digital Unix 4.0 Severity: major Problem: Where structure construct causes strange error message. Code: signature MA = sig type t end; signature MU = sig structure M : MA end; signature DA = sig type t end; (* ------------ this one works ---------------------- *) functor Good(structure D : DA structure Mu : MU where type M.t = D.t) = struct end; (* ------------ this one fails ---------------------- *) functor Bad(structure D : DA structure Mu : MU where M = D) = struct end; Transcript: - use "bug1238.sml"; [opening bug1238.sml] signature MA = sig type t end signature MU = sig structure M : sig type t end end signature DA = sig type t end functor Good : uncaught exception Unbound raised at: elaborate/elabmod.sml:1164.39-1164.49 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:193.58 build/evalloop.sml:285.46-285.49 Comments: Minor modification to the code will make the bug go away. This bug is related to bug 1232. On a related note, sometime a functor definition that involves "where structure" generates a functor which, when instantiated, gives the same error message even though the code is correct. [dbm, 7/23/97] If DA is replaced by MA in Bad, the code compiles ok. So the problem is caused by the difference in signatures (DA vs MA). Fix: Modified entityInfo datatype in Instantiate so that GENERATE_ENT carries a boolean value indicating whether there was a VARstrDef with signature that does not agree with the spec. Test: bug1238.sml Owner: dbm Status: fixed in 109.31 [dbm, 8/13/97] ---------------------------------------------------------------------- Number: 1239 Title: Subscript-out-of-bounds error when opening a structure Keywords: pretty printing, compiler Submitter: Jon Riecke, riecke@bell-labs.com Date: 07/25/97 Version: 109.30 System: Linux and Irix Severity: major Problem: When opening the CML structure, a "subscript out of bounds" exn is raised. Code: CML standard library Transcript: - open CML; GC #0.0.0.1.3.57: (43 ms) open CML val version = {date="June 11, 1997",system="Concurrent ML",version_id=[1,0,7]} : {date:string, system:string, version_id:int list} val banner = "Concurrent ML, Version 1.0.7, June 11, 1997" : string val getTid = fn : unit -> thread_id val sameTid = fn : thread_id * thread_id -> bool val compareTid = fn : thread_id * thread_id -> order val hashTid = fn : thread_id -> word val tidToString = fn : thread_id -> string val spawnc = fn : ('a -> unit) -> 'a -> thread_id val spawn = fn : (unit -> unit) -> thread_id val exit = fn : unit -> 'a val joinEvt = fn : thread_id -> unit event val yield = fn : unit -> unit val channel = fn : unit -> 'a chan val sameChannel = fn : 'a chan * 'a chan -> bool val send = fn : 'a chan * 'a -> unit val recv = fn : 'a chan -> 'a val sendEvt = fn : 'a chan * 'a -> unit event val recvEvt = fn : 'a chan -> 'a event val sendPoll = fn : 'a chan * 'a -> bool val recvPoll = fn : 'a chan -> 'a option uncaught exception in compiler: subscript out of bounds raised at: print/ppobj.sml:89.24-89.29 print/ppobj.sml:349.20 print/ppobj.sml:349.20 print/ppobj.sml:349.20 util/pp.sml:545.6 build/evalloop.sml:193.58 Comments: [jhr, 7/30/97] Appears to be the same as bug 1241, which is fixed in 109.31. Fix: Test: * Owner: Zhong Status: fixed in 109.31 [Zhong, 7/29/97] ---------------------------------------------------------------------- Number: 1240 Title: Can't form pairs of reals Keywords: reals Submitter: Sam Kamin, kamin@cs.uiuc.edu Date: 7/25/97 Version: 109.30 System: sparc-solaris Severity: Critical Problem: Attempt to create tuples containing only real numbers results in "uncaught exception in compiler: Representation" Code: (0.0,0.0) Transcript: Here are a couple of more examples: - (0.0, 0.0); uncaught exception in compiler: Representation raised at: boot/Unsafe/object.sml:58.19-58.33 print/ppobj.sml:349.20 print/ppobj.sml:349.20 util/pp.sml:545.6 build/evalloop.sml:193.58 - (real 0, real 0); uncaught exception in compiler: Representation raised at: boot/Unsafe/object.sml:58.19-58.33 print/ppobj.sml:349.20 print/ppobj.sml:349.20 util/pp.sml:545.6 build/evalloop.sml:193.58 - ((fn x => (x,x)) 0.0); uncaught exception in compiler: Representation raised at: boot/Unsafe/object.sml:58.19-58.33 print/ppobj.sml:349.20 print/ppobj.sml:349.20 util/pp.sml:545.6 build/evalloop.sml:193.58 - (0.0, 0); val it = (0.0,0) : real * int - (0.0, "abc"); val it = (0.0,"abc") : real * string Comments: Fix: Test: bug1240.sml Owner: jhr, Zhong Status: fixed in 109.31 [jhr, 7/28/97] ---------------------------------------------------------------------- Number: 1241 Title: confused datatype constructors Keywords: datatype Submitter: Elsa L. Gunter, elsa@research.bell-labs.com Date: July 25, 1997 Version: 109.30 System: x86 - linux 2.0 Severity: critical Problem: In a datatype with two constructors, the constructors get swapped Code: datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1; datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0; norfolk% sml Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1; datatype 'a t1 = A1 | B1 of 'a list val i1 = B1 [] : 'a t1 - datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0; datatype 'a t2 = A2 of int | B2 of 'a list uncaught exception in compiler: subscript out of bounds raised at: print/ppobj.sml:89.24-89.29 print/ppobj.sml:349.20 print/ppobj.sml:349.20 util/pp.sml:545.6 build/evalloop.sml:193.58 - Comments: Notice that in the first datatype declaration, I assign, i1 to be A1, but it gives me back that it is B1 []. In the second case, it raises an exception (I think because it is trying to apply B2 [] to 0.). Fix: change to ppobj.sml Test: bug1241.sml Owner: Zhong Status: fixed in 109.31 [Zhong] ---------------------------------------------------------------------- Number: 1242 Title: error recovery in open could be better Keywords: open error recovery Submitter: manuel@cs.berkeley.edu Date: July 29/97 Version: 109.29 System: all Severity: low Problem: If one structure is undefined in an open declarations with multiple structures, the non-constant constructors made visible from opening preceding structures are not bound. Results in weird spurious error messages. Code: structure A = struct datatype at = A | B | C of int end local open A Foo in fun toString A = "A" | toString B = "B" | toString (C i) = "C " ^ Int.toString i end Transcript: - [opening /tmp/mla003Cy] /tmp/mla003Cy:7.5-7.15 Error: unbound structure: Foo /tmp/mla003Cy:9.9-11.47 Error: non-constructor applied to argument in pattern: C uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:192.58 build/evalloop.sml:284.46-284.49 - Comments: The C constructor isn't visible, even though A and B are. Removing the Foo structure from the open declaration makes the second error disappear. [dbm, 7/29/97] The reason there is no error message complaining about A and B in the first two clauses of toString is that since these are not bound as constructors they are interpreted as variables. It should be possible to have the open take effect on the structures that are defined, which would cut down on secondary errors like this one. [manuel, 7/29/97] Yes, you are right about the constant constructors. I didn't think of that. But what is strange is that only constructors seem to be missing from the environment. Value bindings are visible in the same context. Fix: Test: bug1242.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1243 Title: Application of functor to different representations Keywords: functor application, polymorphism, representation analysis Submitter: Stephen Weeks Date: 7/28/97 Version: 109.30 System: x86-linux Severity: major Problem: compiler bug tickled by application of functor to two different polymorphic representations Code: local functor Foo(type 'a t val destruct : 'a t -> ('a * 'a t) option) = struct fun first s = case destruct s of SOME(x,_) => x end structure Foo1 = Foo(type 'a t = 'a list fun destruct _ = let exception E in raise E end) structure Foo2 = Foo(datatype 'a t = T of ('a * 'a t) option fun destruct _ = let exception E in raise E end) in val _ = 13 end Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] stdIn:36.6-37.23 Warning: match nonexhaustive SOME (x,_) => ... for the type: I Error: Compiler bug: LambdaType: unexpected case in tcd_arw - Comments: Fix: change to translate/specialize.sml Test: bug1243.sml Owner: Zhong Status: fixed in 109.31 [Zhong, 7/29/97] ---------------------------------------------------------------------- Number: 1244 Title: Explicitly scoped type variable with 'val ... and' declaration Keywords: translate, lambda types Submitter: Stephen Weeks Date: 8/1/97 Version: 109.30, 109.30+ System: x86-linux Severity: minor Problem: Compiler bug caused by use of an explicitly scoped type variable in multiple val declarations. Code: val 'a f = fn x : 'a => x and g = fn y : 'a => y Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - val 'a f = fn x : 'a => x and g = fn y : 'a => y = = ; Error: Compiler bug: Translate: unexpected tyvar INSTANTIATED in mkPE - Comments: Fix: Test: bug1244.sml Owner: Zhong, dbm Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1245 Title: Pretty printer bug Keywords: Submitter: Stephen Weeks Date: 8/4/97 Version: 109.30 System: x86-linux Severity: minor Problem: Error raised when attempting to print the binding of a pair of empty lists in the REPL. Code: val (x,y) = ([],[]) Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB] val it = () : unit - val (x,y) = ([],[]); uncaught exception in compiler: subscript out of bounds raised at: print/ppobj.sml:422.28-422.33 print/ppobj.sml:349.20 print/ppobj.sml:349.20 util/pp.sml:545.6 build/evalloop.sml:193.58 - Comments: Fix: Test: bug1245.sml Owner: Zhong Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1246 Title: Explicit scoping of type variables does not obey the standard. Keywords: explicity scoped type variable Submitter: Stephen Weeks Date: 8/4/97 Version: 109.30 System: x86-linux Severity: minor Problem: The following definition does not typecheck. fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, fn z => z:'a) The following definition does typecheck. fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, fn z => z:'b) I believe that, according to the standard, they both should typecheck. It appears that the first example is failing because the typechecker is changing the scope of the explicitly scoped 'a, whereas the standard only specifies how to determine the scope of implicitly scoped type variables -- the scope of explicitly scoped type variables should not change. As the second example demonstrates, the problem appears to occur because a bound type variable happens to have the same name as a free type variable. Code: fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, fn z => z:'a) fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, fn z => z:'b) Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB] val it = () : unit - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, fn z => z:'a); = stdIn:13.12-13.60 Error: operator and operand don't agree [UBOUND match] operator domain: 'a operand: 'a -> 'a in expression: id id - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, fn z => z:'b); = val f = fn : unit -> ('a -> 'a) * ('b -> 'b) - Another example from Andrew Tolmach [8/18/97] - val 'a f = fn (x:'a) => let val 'a g = fn (y:'a) => (y,y) in g (x,x) end; stdIn:15.25-15.73 Error: operator and operand don't agree [UBOUND match] operator domain: 'a operand: 'a * 'a in expression: g (x,x) Comments: [Andrew Kennedy, 3/20/98] I have a small query concerning explicit type variables: the final syntactic restriction listed in Section 2.9 (page 9) of the Definition seems unnecessary and isn't enforced by SML/NJ. Was it a mistake? In particular, the Tolmach example cited on your bug list val 'a f = fn (x:'a) => let val 'a g = fn (y:'a) => (y,y) in g (x,x) end would appear (to me) not to obey this restriction, and yet is perfectly sensible if val 'a is essentially `big lambda'. Surely a desirable property of the SML is that a declaration such as val 'a id = fn x : 'a => x can be plugged into an arbitrary program context without breaking any restrictions. Fix: in elabcore.sml, revised calculations of updt in the presence of etvs (explicitly bound type variables) to avoid inappropriate instantiations of explicit variables. Test: bug1246.sml, bug1246.1.sml Owner: dbm Status: fixed in 109.31 [dbm, 9/4/97] ---------------------------------------------------------------------- Number: 1247 Title: IntSet library module is wrong Keywords: smlnj-lib, IntSet, ListSet Submitter: Andrew Kennedy Date: 8/4/97 Version: 109.30 System: - Severity: major Problem: A while back I reported some bugs in the ListSet functor. They were fixed but unfortunately the fix doesn't appear to have been applied to the IntSet specialised version. (Just compare the source files: they're are some missing primes on variable names in some functions). Comments: Fix: Test: ? Owner: jhr, Emden Status: Fixed in 109.31 ---------------------------------------------------------------------- Number: 1248 Title: blastWrite failures Keywords: blastRead, blastWrite Submitter: Chris Paris Date: 8/5/97 Version: 109.30 System: ? Severity: major Problem: blastwrite fails catastrophically Code: Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB] val it = () : unit - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);val blastWrite = fn : 'a -> Word8Vector.vector - blastWrite (Word8Array.array (516000, 0w0)); GC #0.0.0.0.1.4: (0 ms) GC #0.0.0.0.2.6: (10 ms) val it = - : Word8Vector.vector - blastWrite (Word8Array.array (516001, 0w0)); GC #0.0.0.1.3.7: (0 ms) GC #0.0.0.1.4.8: (0 ms) ./sml: Fatal error -- blasting out of 516096 bytes not supported yet! Increase allocation arena size. But perhaps blasting one large atomic object presents a problem that blasting a collection of small objects wouldn't, so here's another example. Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB] val it = () : unit - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x); val blastWrite = fn : 'a -> Word8Vector.vector - fun iter 0 = [] = | iter n = n :: (iter (n-1)); val iter = fn : int -> int list - blastWrite (iter 10); val it = - : Word8Vector.vector - blastWrite (iter 100); val it = - : Word8Vector.vector - blastWrite (iter 1000); val it = - : Word8Vector.vector - blastWrite (iter 10000); GC #0.0.0.0.1.13: (20 ms) val it = - : Word8Vector.vector - blastWrite (iter 100000); GC #0.0.0.1.2.16: (110 ms) GC #0.0.0.2.3.17: (140 ms) Segmentation fault Comments: [Chris Paris, 8/5/97] In last night's message, I meant to make another comment about blastWrite but forgot. I find it limiting that the size of the object blastWrite can handle is limited by the allocation arena size. I'm already running with a doubled allocation arena size to accomodate our growing data, but I understand that I can't just keep increasing it indefinitely and expect to retain reasonable performance. The end of blast-out.c mentions allocating space in the big-object arena as an alternative implementation. I'm wondering if this would be an easy change to make that hasn't been done simply due to lack of demand, or whether there are difficult issues to overcome in order to remove the current limitation. Fix: Test: bug1248.1.sml, bug1248.2.sml Owner: jhr Status: fixed in 109.31 [jhr, 8/12/97] ---------------------------------------------------------------------- Number: 1249 Title: Time.time type too small Keywords: Time.time Submitter: Chris Paris Date: 8/5/97 Version: 109.30 System: - Severity: minor Problem: The project I'm working on uses the Time.time type for some things. Today we ran into some data that required 32 bits in the sec field. We had to write our own time type to handle this. I'm not saying the system Time type should definitely be changed, but I thought you'd like to know that someone needed more than 31 bits there. Comments: The SML Basis now specifies a LargeInt.int representation for the seconds field. -- jhr Fix: Test: Owner: jhr? Status: Fixed in 109.31 [jhr, 7/31/97] ---------------------------------------------------------------------- Number: 1250 Title: Bind exception delayed by polymorphic generalization Keywords: Bind exception Submitter: Stephen Weeks Date: 8/5/97 Version: 109.30 System: x86-linux Severity: minor Problem: A Bind exception is not raised in a value declaration when the variable being defined is polymorphically generalized. I suspect that the raise is getting wrapped in a _/\_ in the translation into the typed IL. The exception is raised later if the polymorphic value is applied. Code: datatype 'a foo = Foo1 of 'a | Foo2 of 'a val Foo1 f = Foo2(fn x => x); f 13; Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB] - datatype 'a foo = Foo1 of 'a | Foo2 of 'a val Foo1 f = Foo2(fn x => x); = stdIn: Warning: binding not exhaustive Foo1 f = ... datatype 'a foo = Foo1 of 'a | Foo2 of 'a val f = fn : 'a -> 'a - f 13; uncaught exception Bind [nonexhaustive binding failure] raised at: stdIn: Comments: [Zhong, 8/5/97] Thanks for the bug report. This bug is actually related to the pretty-printing. As you observed, binding f to _/\_ does not raise the exception; the exception should be raised when printing f in the top-level (however, the pretty-printing in 109.30 was broken, so the exception is not raised). Our fixes for the other pretty-printing bugs (which have been incorporated into 109.31) should correctly raise the exception, however, the exception name is not printed out correctly still. Fix: Test: bug1250.sml Owner: Zhong Status: Fixed in 109.31 [Zhong] ---------------------------------------------------------------------- Number: 1251 Title: where specs cause exception Unbound Keywords: where Unbound Submitter: Stephen Weeks Date: 8/6/97 Version: 109.30 System: x86-linux Severity: minor Problem: The use of a where spec can cause exception Unbound to be raised by the elaborator. Code: structure S : sig structure A : sig end structure B : sig structure C : sig end end where C = A end = struct structure A = struct end structure B = struct structure C = A end end Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - structure S : sig structure A : sig end structure B : sig structure C : sig end end where C = A end = struct structure A = struct end structure B = struct structure C = A end end; uncaught exception in compiler: Unbound raised at: elaborate/elabmod.sml:1050.15-1050.25 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:193.58 Comments: [Zhong, 8/6/97] Thanks for the bug report. I encountered this same bug while trying to fix bug 1205. It happens only if the righthand side of the where clause is a "flexible" structure (i.e., locally defined structure). Dave and I will try to get a fix into 109.31. Fix: change strEntEnv to entEnv around line 545 of sigmatch.sml Test: bug1251.sml Owner: Zhong, dbm Status: fixed in 109.31 [Zhong, dbm] ---------------------------------------------------------------------- Number: 1252 Title: Unbound exception on functor application Keywords: modules, functors Submitter: Stephen Weeks Date: 8/6/97 Version: 109.30 System: x86-linux Severity: minor Problem: A compiler bug is raised on the following code. Code: functor F(type t) = let structure S : sig type v val x : v end = struct datatype 'a u = U of (t * 'a) list type v = t u val x = U[] end in struct datatype t = T of S.v val x = T S.x end end; structure S = F(type t = int); Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - functor F(type t) = let structure S : sig type v val x : v end = struct datatype 'a u = U of (t * 'a) list type v = t u val x = U[] end in struct datatype t = T of S.v val x = T S.x end end; - structure S = F(type t = int); functor F : Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h [dbm: In 109.31-, the behavior is different. Unbound (EE.Unbound?) is raised instead: ] - use "test/bugs/bug1252.sml"; [opening test/bugs/bug1252.sml] functor F : uncaught exception Unbound raised at: elaborate/elabmod.sml:1060.15-1060.25 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:289.46-289.49 Comments: [Zhong] This seems to be the same as bug 1234. Fix: Test: bug1252.sml, bug1252.1.sml Owner: Zhong, dbm Status: Fixed in 109.31 [Zhong] ---------------------------------------------------------------------- Number: 1253 Title: pretty printing nested polymorphic records Keywords: pretty printing, representations Submitter: Chris Page Date: 8/6/97 Version: 109.30 System: - Severity: major Problem: The code in the printer that tries to avoid printing polymorphic records doesn't work when the record is wrapped in another (non-record) type. Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB] val it = () : unit - (NONE, ()); val it = : 'a option * unit - SOME (NONE, ()); uncaught exception in compiler: Representation Comments: [Zhong, 4/4/98] By the way, in 110.4, I have fixed the pretty printing of poly record. So typing things such as: val x = (nil, nil) or val x = (nil, 3) will print the expected values rather than . Fix: Test: bug1253.sml Owner: Zhong Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1254 Title: Disagreements between SML/NJ and Defn: datatype replication Keywords: datatype replication Submitter: Stephen Weeks Date: 8/11/97 Version: 109.30 System: x86-linux Severity: minor Problem: (1) I believe that the Standard says that the following program is legal, and should make 's' an abbreviation for 'int'. However, SML/NJ responds with "Error: rhs of datatype replication not a datatype". type t = int datatype s = datatype t SML/NJ and the Standard both accept the following program, but I believe they do so for different reasons. (2) structure S : sig type t end = struct datatype t = T end datatype u = datatype S.t After the above program is entered, I believe that the Standard says that the following declaration is illegal, whereas SML/NJ accepts it. val x = T My reading of the Standard is that the signature constraint on 'S' should hide the constructors associated with type 't' and that the declaration of 'u' should declare 'u' as an abbreviation of 't', but not be able to access t's constructors, since they were hidden by the signature. Comments: [dbm, 8/14/97] Part (1) is considered an omission in the Definition. Part (2) is a bug because of rule (80), which says that the constructor environment component of t is stipped out by signature matching. This should really cause the subsequent datatype replication declaration datatype u = datatype S.t to fail, because there is no constructor environment for u to inherit from S.t, and a datatype without a constructor environment is not a proper datatype. Fix: Test: bug1254.sml Owner: dbm Status: open (2) ---------------------------------------------------------------------- Number: 1255 Title: Disagreements between SML/NJ and Defn: datatype replication, part II Keywords: datatype replication Submitter: Stephen Weeks Date: 8/11/97 Version: 109.30 System: x86-linux Severity: minor Problem: I believe that the following code is legal, according to the Standard. However, SML/NJ rejects it, responding with: Error: value type in structure doesn't match signature spec name: U spec: ?.t -> ?.Foo.u actual: ?.int -> ?.Foo.u Code: structure Foo : sig type t datatype u = U of t structure Goo : sig datatype v = datatype u end end = struct type t = int datatype u = U of t structure Goo = struct datatype v = datatype u end end Transcript: Comments: Fix: Modified PATHtyc case of expandTyc in elabDATArepl in elabsig.sml. Check if entPath is external, in which case nothing needs to be done. Otherwise, if PATHtyc is internal to current signature, adjust it by adding appending prefix. Test: bug1255.sml Owner: dbm Status: fixed in 109.31 [dbm, 7/15/97] ---------------------------------------------------------------------- Number: 1256 Title: Free type variables in local datatype declarations. Keywords: datatype type variable Submitter: Stephen Weeks Date: 8/11/97 Version: 109.30 System: x86-linux Severity: minor Problem: In a local datatype declarations, SML/NJ does not accept constructors whose types contain type variables that are not bound in the datatype declaration (even if they are bound in the enclosing program). For example, I believe that the Standard says that following program should be accepted. SML/NJ responds with "Error: unbound type variable in type declaration: 'a". Code: fun 'a f (x : 'a) = let datatype foo = Foo of 'a * int in 13 end Transcript: Comments: [dbm, 8/13/97] This may technically be accepted under the definition, but this is an oversight or error in the definition. For various reasons, if a polymorphically bound type variable could participate in type definitions as in your example, there would be serious implementation complications for very little gain in utility. I don't plan to "fix" this bug in SML/NJ. Fix: Test: * Owner: dbm Status: not a bug ---------------------------------------------------------------------- Number: 1257 Title: (spurious) dependency cycle in instantiate Keywords: modules, opaque signatures Submitter: manuel@cs.berkeleye.edu Date: 8/19/97 Version: SML-109.30 + blume patch System: x86-linux, sparc-solaris2.5 Severity: major Problem: Opaque signature matching fails when the structure contains a functor whose signature has where specifications. Produces uncaught exception Unbound and a message "dependency cycle in instantiate" Code: signature S = sig type genT type T val embed : T -> genT end structure S = struct type genT = int type T = int val embed = fn x => x end signature B = sig type genT functor mkS() : S where type genT = genT end structure B :> B = struct type genT = S.genT functor mkS() = S end Transcript: - use "bug_inst.sml"; [opening bug_inst.sml] bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate uncaught exception Unbound raised at: elaborate/elabmod.sml:1060.15-1060.25 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:289.46-289.49 - Comments: The idea behind this code is to create new structures using B.mkS(), each of which will share the type genT, but not the type T. The desired behavior can be obtained with the following code, which moves the opaque matching from B to the functor. The difference to the code above is in that genT is not opaque in B. signature S = sig type genT type T val embed : T -> genT val new : int -> T val show : genT -> unit end structure S = struct type genT = int type T = int val embed = fn x => x fun new x = x val show = fn x => print (Int.toString x ^"\n") end signature B = sig type genT functor mkS() : S where type genT = genT end structure B : B = struct type genT = S.genT functor mkS() :> S where type genT = genT = S end structure X = B.mkS; structure Y = B.mkS; val x = X.new 5; val y = Y.new 7; val xe = X.embed x; val ye = X.embed y; val _ = X.show ye; (* is accepted correctly *) val _ = Y.show xe; (* is accepted correctly *) val xf = Y.embed x; (* rejected correctly *) val yf = X.embed y; (* rejected correctly *) val _ = X.show 5; (* genT isn't opaque. *) Fix: Test: Owner: dbm Status: Fixed in 109.31 ---------------------------------------------------------------------- Number: 1258 Title: OS.Process.atExit does not agree with basis documentation Keywords: standard basis Submitter: Chris Stone, cstone+@cs.cmu.edu Perry Cheng, pscheng+@cs.cmu.edu Date: August 19, 1997 Version: 109.30 System: Alpha OSF/1 3.2 Severity: minor Problem: From the on-line standard basis documentation for OS.Process.atExit: Calls to exit do not return, but should cause the remainder of the functions registered with atExit to be executed. The code does not have this behavior. Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - OS.Process.atExit (fn _ => print "1\n"); val it = () : unit - OS.Process.atExit (fn _ => print "2\n"); val it = () : unit - OS.Process.atExit (fn _ => print "3\n"); val it = () : unit - ^D3 2 1 Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - OS.Process.atExit (fn _ => print "1\n"); val it = () : unit - OS.Process.atExit (fn _ => OS.Process.exit 1); val it = () : unit - OS.Process.atExit (fn _ => print "3\n"); val it = () : unit - ^D3 3 3 3 ...[infinite loop] Comments: A quick glance at the file NJ/cleanup.sml led us to initially expect that the call to exit would terminate the program immediately, skipping the third function registered with atExit. However, it turns out that since the "clean" function does not change the list "hooks" when called with the AtExit parameter, the call to exit starts re-invoking all of the functions registered with AtExit. Fix: Test: Owner: jhr Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1259 Title: Mistakenly inadmissable signature. Keywords: modules, signatures Submitter: Stephen Weeks Date: 8/19/97 Version: 109.30 System: x86-linux Severity: minor Problem: The following signature is not accepted by SML/NJ 109.30, even though it should be. SML/NJ 109.30 returns the message "Error: dependency cycle in instantiate". Earlier versions, such as 109.29, accepted this signature at the point it was declared, but reported the dependency cycle error when it was used as a functor parameter (i.e. when it was instantiated). Code: signature SIG = sig type b' datatype a = A1 | A2 of b' datatype b = B1 | B2 of a sharing type b = b' end The signature is accepted when it directly constrains a structure, as in the following code. structure S : sig type b' datatype a = A1 | A2 of b' datatype b = B1 | B2 of a sharing type b = b' end = struct datatype a = A1 | A2 of b and b = B1 | B2 of a type b' = b end Transcript: Comments: This might be the same as bug #1257. [Zhong, 8/21/97] Ok, in 109.30, we check the validity of every signature at its definition site (i.e., we try to instantiate it), thus the cycle is detected even at the declaration site. |> In any case, both versions are wrong to reject the signature, since it |> can be instantiated by the structure I provided. |> |> structure S : sig |> type b' |> datatype a = A1 | A2 of b' |> datatype b = B1 | B2 of a |> sharing type b = b' |> end = |> struct |> datatype a = A1 | A2 of b |> and b = B1 | B2 of a |> type b' = b |> end I'd not say our implementation is wrong :-) I'd argue that it is the Definition that is wrong --- in fact, the Definition is vague on how the above signature will be elaborated --- if you follow what's said in the Definition, you will get a structure of the form structure SIG-INST = struct type b' = b datatype a = A1 | A2 of b datatype b = B1 | B2 of a end [dbm: not quite. The definition (rule 78) elaborates the sharing spec by applying a substitution to an already elaborated environment structure representing the previous specs.] Notice I have no way to reorder the above into a valid ML structure. The best I can do is: structure SIG-INST = struct datatype a = A1 | A2 of b datatype b = B1 | B2 of a type b' = b end still type a and b are mutually recursive. To make it work, the signature elaboration has to make a and b mutually recursive: structure SIG-INST = struct datatype a = A1 | A2 of b and b = B1 | B2 of a type b' = b end This is non-trivial to generalize to cover other cases; for example, what if SIG is like the following: signature SIG' = sig type b' datatype a = A1 | A2 of b' structure S : sig datatype b = B1 | B2 of a end sharing type b' = S.b' end SIG' probably will not match any structure, but it is very hard to discover what is match-able and what is not. Because of all these, we decided to adopt a simpler algorithm in SML/NJ --- we'll only do reorganizations of all the specs, but we'll never merge two non-recursive datatype specs into mutually-recursive ones. [dbm, 8/5/97] I think that it would probably be possible to fix this "bug" superficially in the Instantiate module, but I am not sure what the consequences would be for FLINT's type representation analysis. In particular, with a signature declaration such as the following [1] signature SIG = sig type b' datatype a = A1 | A2 of b' datatype b = B1 | B2 of a sharing type b = b' end the datatypes a and b are made mutually recursive "after the fact" as a consequence of the type sharing spec. Will the FLINT representation analysis be able to come up with the same representations of a and b as for the following "equivalent" (see comment on equality properties below) signatures: [2] signature SIG = sig datatype a = A1 | A2 of b and b = B1 | B2 of a type b' sharing type b = b' end [3] signature SIG = sig datatype a = A1 | A2 of b and b = B1 | B2 of a type b' = b end and if you come up with different representations for the latter two signatures, does it matter? In other words, if you have two independent datatype specs, and then tie a knot between them by a subsequent sharing spec, can you recover the same representation as though the types had originally been specified as mutually recursive, or do you care? There is also the issue of assigning the equality properties to the specified types. In [1], b' does not admit equality, and therefore neither does a, and so neither does b. In [2] and [3], a and b, and therefore b', do admit equality. Does this inconsistency matter? Also, things can get much more convoluted; for instance signature SIG = sig structure A : sig type a end structure B : sig datatype b = B1 | B2 of A.a end structure C : sig datatype c = C1 | C2 of B.b end sharing type A.a = C.c end which could be matched by the structure structure S = struct datatype b = B1 | B2 of c and c = C1 | C2 of b structure A = struct type a = c end structure A = struct datatype b = datatype b end structure A = struct datatype c = datatype c end end I think it is clear that we don't want to force Instantiate to be this clever when attempting to create a realization. So how do we formulate a sharp condition that will disallow these kinds of recursion through sharing specs? Fix: Test: bug1259.1.sml, bug1259.2.sml, bug1259.3.sml Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1260 Title: Compiler bug (EntityEnv) when compiling ml-yacc Keywords: Submitter: John Reppy (jhr@research.bell-labs.com) Date: August 26, 1997 Version: 109.30+ System: all Severity: major Problem: I changed ml-yacc by replacing the three uses of "abstraction" with ":>". Now I get a compiler error on the file parser2.sml, which is one of the files I changed. I note that this file compiled okay in the context of the compiler, but not when trying to compile ml-yacc. Note, the changed file is accepted by 109.30, so this must have been introduced by one of the recent changes. Code: Transcript: [opening ../lib/parser2.sml] GC #0.0.0.1.3.62: (76 ms) lookEnt.1: expected STRent found entity: TYCent entpath: [#L.52,#L.1] Error: Compiler bug: EntityEnv: lookEnt.2 uncaught exception TopLevelException [Error] raised at: util/errormsg.sml:54.14-54.19 modules/instantiate.sml:1122.9 elaborate/elabmod.sml:1119.8 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:289.46-289.49 Comments: Zhong says: I found a fix for the bug. The bug was caused by Dave and Matthias's recent changes on turning off "pickling" in the top level (sigh ...). In fact, a more severe bug is the test case below. It turns out that the mkStamp function is making new stamp from 0 when compiling each compilation unit (hmmm, not quite accurate, look when evalLoop is called in interact.sml). So t and s share the same stamp (L0). If we do pickling, s and t's stamps will be globalized during the pickling, so they will not be indentified. For the ML-Yacc, it is the similar reason. Because the stamp is not unique, the entity variable created for each signature component is not unique, this confuses the elaborator thus causing the bug. Fix: I make sure that the compiler never resets the global stamp counter --- notice that if the interactive loop is long enough (e.g., even after exportML,...); it is possible to run out of the stamps (i.e., overflow) --- especially the same stamp counter is now used for multiple purposes (stamp, entvar, ...). With pickling, the counter is reset each time and the pickler always globalize all the stamps (even hidden ones) with an external pid ! Test: (* typing in each of the following at the top-level *) local datatype t = A in val x = A end; junk; (* this line is crucial; the purpose is to cause an error *) local datatype s = B in val y = B end; x = y; (* The compiler accepts the "x = y", and producing true. *) Owner: dbm, blume, zsh Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1261 Title: explicit type parameter with "val rec" not supported Keywords: syntax, explicit type parameters Submitter: Dave MacQueen Date: 9/4/97 Version: 109.30 System: - Severity: minor Problem: Syntax "val 'a rec ..." not implemented. Transcript: - val 'a rec f = fn x : 'a => x; stdIn:14.8-14.15 Error: syntax error: deleting REC ID EQUALOP stdIn:14.16-14.22 Error: syntax error: deleting FN ID COLON stdIn:14.23-14.28 Error: syntax error: deleting TYVAR DARROW Comments: Fix: Test: bug1261.sml Owner: dbm, Appel Status: open ---------------------------------------------------------------------- Number: 1262 Title: literal ~0.0 reads as 0.0 Keywords: floating point, literals Submitter: appel Date: August 19, 1997 Version: 109.30 System: any Severity: minor Problem: literal ~0.0 reads as 0.0 Code: Real.copysign(1.0,~0.0) Transcript: val it = 1.0 Comments: Fix: in first if-statement of ieeereal.sml Test: bug1262.sml Owner: Appel Status: open ---------------------------------------------------------------------- Number: 1263 Title: sqrt, ln incorrect on subnormal numbers Keywords: floating point, math Submitter: appel Date: August 19, 1997 Version: 109.30 System: any Severity: minor Problem: sqrt, ln incorrect on subnormal numbers Code: let val a = Math.sqrt(Real.minNormalPos * 0.1) in [Real.minNormalPos*0.1, a*a] end Transcript: val it = [2.22507385851e~309,1.22379062218e~308] : real list Comments: The scalb and logb functions in math64.sml called upon Assembly.A.scalb,logb, and were already augmented to handle a bigger range of cases than the assembly-lang primops, but I made them even fancier to handle subnormal inputs and outputs. Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1264 Title: (spurious) dependency cycle in instantiate Keywords: modules, opaque signatures Submitter: manuel@cs.berkeleye.edu Date: 8/19/97 Version: SML-109.27 + blume patch System: x86-linux, sparc-solaris2.5 Severity: major Problem: Opaque signature matching fails when the structure contains a functor whose signature has where specifications. Produces uncaught exception Unbound and a message "dependency cycle in instantiate" Code: signature S = sig type genT type T val embed : T -> genT end; structure S = struct type genT = int type T = int val embed = fn x => x end; signature B = sig type genT functor mkS() : S where type genT = genT end; structure B :> B = struct type genT = S.genT functor mkS() = S end; Transcript: - use "bug_inst.sml"; [opening bug_inst.sml] bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate uncaught exception Unbound raised at: elaborate/elabmod.sml:1060.15-1060.25 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:289.46-289.49 - Comments: The idea behind this code is to create new structures using B.mkS(), each of which will share the type genT, but not the type T. The desired behavior can be obtained with the following code, which moves the opaque matching from B to the functor. The difference to the code above is in that genT is not opaque in B. signature S = sig type genT type T val embed : T -> genT val new : int -> T val show : genT -> unit end structure S = struct type genT = int type T = int val embed = fn x => x fun new x = x val show = fn x => print (Int.toString x ^"\n") end signature B = sig type genT functor mkS() : S where type genT = genT end structure B : B = struct type genT = S.genT functor mkS() :> S where type genT = genT = S end structure X = B.mkS; structure Y = B.mkS; val x = X.new 5; val y = Y.new 7; val xe = X.embed x; val ye = X.embed y; val _ = X.show ye; (* is accepted correctly *) val _ = Y.show xe; (* is accepted correctly *) val xf = Y.embed x; (* rejected correctly *) val yf = X.embed y; (* rejected correctly *) val _ = X.show 5; (* genT isn't opaque. *) Fix: Test: bug1264.sml Owner: Zhong Status: fixed in 109.31 [Zhong, 8/21/97] ---------------------------------------------------------------------- Number: 1265 Title: uncaught Match exn in elabmod.sml:632.7 Keywords: module elaboration, signature matching Submitter: manuel@cs.berkeley.edu Date: 8/19/97 Version: 109.30 + Matthias Blume patch System: x86-linux, sparc-solaris2.5 Severity: major Problem: Signature matching causes Match exception in compiler Code: structure J : S = K : T; Transcript: - structure J : S = K : T; uncaught exception in compiler: nonexhaustive match failure raised at: elaborate/elabmod.sml:632.7 elaborate/elabmod.sml:1059.8 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 - Comments: Fix: Test: bug1265.sml Owner: Zhong, dbm Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1266 Title: OS.Process.atExit does not agree with basis documentation Keywords: standard basis Submitter: Chris Stone, cstone+@cs.cmu.edu Perry Cheng, pscheng+@cs.cmu.edu Date: August 19, 1997 Version: 109.30 System: Alpha OSF/1 3.2 Severity: minor Problem: From the on-line standard basis documentation for OS.Process.atExit: Calls to exit do not return, but should cause the remainder of the functions registered with atExit to be executed. The code does not have this behavior. Transcript: Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - OS.Process.atExit (fn _ => print "1\n"); val it = () : unit - OS.Process.atExit (fn _ => print "2\n"); val it = () : unit - OS.Process.atExit (fn _ => print "3\n"); val it = () : unit - ^D3 2 1 Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled] - OS.Process.atExit (fn _ => print "1\n"); val it = () : unit - OS.Process.atExit (fn _ => OS.Process.exit 1); val it = () : unit - OS.Process.atExit (fn _ => print "3\n"); val it = () : unit - ^D3 3 3 3 ...[infinite loop] Comments: A quick glance at the file NJ/cleanup.sml led us to initially expect that the call to exit would terminate the program immediately, skipping the third function registered with atExit. However, it turns out that since the "clean" function does not change the list "hooks" when called with the AtExit parameter, the call to exit starts re-invoking all of the functions registered with AtExit. Fix: * Test: * Owner: jhr Status: fixed in 109.31 [jhr, 8/19/97] ---------------------------------------------------------------------- Number: 1267 (duplicate of bug 1259) Title: Mistakenly inadmissable signature. Keywords: modules, signatures, definition specs, datatype specs Submitter: Stephen Weeks Date: 8/19/97 Version: 109.30 System: x86-linux Severity: minor Problem: The following signature is not accepted by SML/NJ 109.30, even though it should be. SML/NJ 109.30 returns the message "Error: dependency cycle in instantiate". Earlier versions, such as 109.29, accepted this signature. signature SIG = sig type b' datatype a = A1 | A2 of b' datatype b = B1 | B2 of a sharing type b = b' end The signature is accepted when it directly constrains a structure, as in the following code. structure S : sig type b' datatype a = A1 | A2 of b' datatype b = B1 | B2 of a sharing type b = b' end = struct datatype a = A1 | A2 of b and b = B1 | B2 of a type b' = b end Code: Transcript: Comments: [Zhong, 8/21/97] |> In any case, both versions are wrong to reject the signature, since it |> can be instantiated by the structure I provided. |> |> structure S : sig |> type b' |> datatype a = A1 | A2 of b' |> datatype b = B1 | B2 of a |> sharing type b = b' |> end = |> struct |> datatype a = A1 | A2 of b |> and b = B1 | B2 of a |> type b' = b |> end I'd not say our implementation is wrong :-) I'd argue that it is the Definition that is wrong --- in fact, the Definition is vague on how the above signature will be elaborated --- if you follow what's said in the Definition, you will get a structure of the form structure SIG-INST = struct type b' = b datatype a = A1 | A2 of b datatype b = B1 | B2 of a end Notice I have no way to reorder the above into a valid ML structure. The best I can do is: structure SIG-INST = struct datatype a = A1 | A2 of b datatype b = B1 | B2 of a type b' = b end still type a and b are mutually recursive. To make it work, the signature elaboration has to make a and b mutually recursive: structure SIG-INST = struct datatype a = A1 | A2 of b and b = B1 | B2 of a type b' = b end This is non-trivial to generalize to cover other cases; for example, what if SIG is like the following: signature SIG' = sig type b' datatype a = A1 | A2 of b' structure S : sig datatype b = B1 | B2 of a end sharing type b' = S.b' end SIG' probably will not match any structure, but it is very hard to discover what is match-able and what is not. Because of all these, we decided to adopt a simpler algorithm in SML/NJ --- we'll only do reorganizations of all the specs, but we'll never merge two non-recursive datatype specs into mutually-recursive ones. Fix: - Test: - Owner: dbm, Zhong Status: not a bug ---------------------------------------------------------------------- Number: 1268 Title: logb of negative numbers on Sparc Keywords: floating point, logb Submitter: appel Date: 8/21/97 Version: 109.30 System: Sparc Severity: minor Problem: Assembly.A.logb gives bogus result for any negative number. Code: Assembly.A.logb ~1.0; (* this example from 109.29 *) Transcript: val it = 2048 : int Comments: broken since 109.26 or before [dbm, 11/11/97] Test case is obsolete in 109.32 because Assembly is not bound at top level. Needs to be tested indirectly by regression tests on Math, Real64 structures. Fix: in SPARC.prim.asm Test: bug1268.sml (obsolete) Owner: Appel Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1269 Title: CM.set_path has no effect after CM.make Keywords: CM Submitter: John Reppy (jhr@research.bell-labs.com) Date: August 21, 1997 Version: 109.30 System: all Severity: minor Problem: One a CM.make command has been executed, changing the search path has no effect. Code: Transcript: - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/mipseb-unix/sources.cm.stable ... not usable] !* CM error: smlnj-lib.cm: description file not found - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]); val it = [] : string list - CM.make(); [starting dependency analysis] !* CM error: smlnj-lib.cm: description file not found - whereas, if I change the path first, it works fine. - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]); val it = [] : string list - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/mipseb-unix/sources.cm.stable ... not usable] [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] ... Comments: Fix: Test: Owner: Blume Status: open? ---------------------------------------------------------------------- Number: 1270 Title: EntityEnv.Unbound raised while compiling functor Keywords: modules, functors, signature matching Submitter: Lal George Date: 9/8/97 Version: 109.31 System: - Severity: major Problem: EntityEnv.Unbound raised while compiling functor Code: (* bug1270.sml *) signature S2 = sig structure A : sig type s end val x : A.s end; signature S3 = sig type u val y : u end; functor F (structure X: S3) = (* "structure" necessary *) struct type s = X.u end; functor G (U: S3) (V: S2) : S2 = (* ": S2" necessary *) struct structure A = F (structure X = U) val x = U.y end; Transcript: - use "bug1270.sml"; [opening bug1270.sml] signature S2 = sig structure A : sig type s end val x : A.s end signature S3 = sig type u val y : u end functor F : uncaught exception Unbound raised at: elaborate/elabmod.sml:1225.39-1225.49 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:292.19-292.22 Comments: Regression failure for bug 922. Fix: Test: bug1270.sml Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1271 Title: uncaught Unbound while compiling open Keywords: modules, functors, open Submitter: Lal George Date: 9/8/97 Version: 109.31 System: - Severity: major Problem: uncaught Unbound while compiling open Code: signature SIG1 = sig type t val x: t end; signature SIG2 = sig functor Foo(X:SIG1) : sig val w: X.t end end; structure B : SIG2 = (* ": SIG2" is necessary *) struct functor Foo(X:SIG1) = struct val w = X.x end end; open B; Transcript: - use "bug1271.sml"; [opening bug1271.sml] signature SIG1 = sig type t val x : t end signature SIG2 = sig functor Foo : (: ) : end structure B : SIG2 uncaught exception Unbound raised at: translate/transmodules.sml:80.33-80.43 util/stats.sml:164.40 build/evalloop.sml:196.58 build/evalloop.sml:292.19-292.22 Comments: Regression failure for bug 641. The SIG2 signature constraint on B is necessary for the bug to occur. Other references to B.Foo, such as functor F = B.Foo or structure XX = B.Foo(struct type t = int val x = 3 end); will also cause an uncaught Unbound exception. Fix: Test: bug1271.sml Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1272 Title: Match exception raised in instantiate while elaborating sig Keywords: modules, signatures, definition specs, sharing Submitter: Lal George Date: 9/8/97 Version: 109.31 System: - Severity: major Problem: Match exception raised in instantiate while elaborating sig Code: (bug1272.sml) signature Z = sig end; signature S = sig structure A: Z end; signature T1 = sig structure B: S structure A : Z = B.A end; signature T2 = sig structure B: S structure A : Z = B.A end; signature V = sig structure C: T1 structure D: T2 sharing C = D end; Transcript: uncaught exception Match [nonexhaustive match failure] raised at: modules/instantiate.sml:706.6 modules/instantiate.sml:802.29 modules/instantiate.sml:1164.55 util/stats.sml:164.40 elaborate/elabmod.sml:1259.33 util/stats.sml:164.40 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:292.19-292.22 Comments: Regression failure for bug 429. Fix: added appropriate rule for VARstrDef to case expression in SDEFINE case of constrain within buildStrClass. Test: bug1272.sml Owner: dbm Status: fixed in 109.32 [dbm, 9/9/97] ---------------------------------------------------------------------- Number: 1273 Title: control-c doesn't interrupt infinite loop Keywords: interrupt, tail recursion, runtime, gc check Submitter: Allen Stoughton allen@cis.ksu.edu Date: 9/10/97 Version: 109.31 System: sparc-solaris Severity: major Problem: When a tail-recursive function infinite loops, CTRL-c doesn't interrupt the computation Code: Transcript: - fun f x = f x; GC #2.5.6.7.9.24: (0 ms) val f = fn : 'a -> 'b - f 0 : int; (CTRL-c has no effect) On the other hand, if I type - fun f n = if n = 0 then 1 else n * f(n-1); val f = fn : int -> int - f ~1; GC #0.0.0.0.1.4: (0 ms) GC #0.0.0.1.2.5: (90 ms) GC #0.0.1.2.3.10: (470 ms) GC #0.1.2.3.4.11: (610 ms) GC #1.2.3.4.5.16: (1030 ms) GC #1.3.4.5.6.17: (350 ms) GC #2.4.5.6.7.22: (1480 ms) Interrupt then I can interrupt out successfully. Comments: sparc-solaris specific Fix: The problem was that on Solaris the heap addresses are in the top half of the range (i.e., negative), and the code generator was using a signed comparison for the heap limit check. The fix was to change this to an unsigned comparison. Test: - Owner: jhr Status: fixed in 109.32 [jhr, 9/10/97] ---------------------------------------------------------------------- Number: 1274 Title: secondary compiler bug caused by unbound signature Keywords: secondary error, instantiate Submitter: Lal George Date: 9/8/97 Version: 109.31 System: - Severity: minor Problem: secondary compiler bug caused by unbound signature Code: functor F (structure A : S structure B : S sharing type B.t = A.s) = struct end; Transcript: - functor F = (structure A : S = structure B : S = sharing type B.t = A.s) = struct end; stdIn:8.6-10.24 Error: unbound signature: S stdIn:8.6-10.24 Error: unbound signature: S Error: Compiler bug: Instantiate: distributeT:stepPath 2 Comments: Fix: Test: bug1274.sml Owner: dbm Status: fixed in 109.32 ---------------------------------------------------------------------- Number: 1275 Title: mod and div broken on alpha Keywords: mod, div, alpha Submitter: george@persimmon.co.uk Date: 9/10/97 Version: 109.31 System: alpha-unix Severity: major Problem: mod and div broken on alpha Transcript: - Word32.mod(0w22,0w11); val it = 0wxffffffea : Word32.word Comments: [Lal, 9/11/97] In 109.31, division (divl and divlu) is implemented by a call to assembly rather than generating inline code that uses floating point registers. The overhead in doing this with a graph coloring allocator is very low. However, this test case pointed out a subtle bug in the interaction of parallel copy instructions with interference graph construction that is very serious and likely to show up wherever division is used. I have corrected this and the fix will be in the next version. I will also be making a patch file available (soon) incase you are familiar with recompiling the compiler (see the CM doc). Fix: Test: bug1275.sml Owner: Lal Status: fixed in 109.32 [Lal, 9/11/97] ---------------------------------------------------------------------- Number: 1276 Title: Posix.TTY.getattr returns invalid object. Keywords: Posix TTY Submitter: David Brown Date: 09/10/1997 Version: 109.31 System: x86-linux Severity: major Problem: The Posix.TTY.getattr function returns an object that doesn't appear to be valid. From what I can tell, the C code uses WORD_ALLOC to construct the members of the record. This object doesn't correspond with the Word32.word object that the ml code is expecting. Code: structure Read = struct structure FS = Posix.FileSys structure TTY = Posix.TTY structure IO = Posix.IO val O_RDWR = FS.O_RDWR val no_flags = FS.O.flags [] fun openf name = FS.openf (name, O_RDWR, no_flags) fun exp () = let val fd = openf "/dev/tty" (* val fields = {iflag = TTY.I.flags [], oflag = TTY.O.flags [], cflag = TTY.C.flags [TTY.C.cs8, TTY.C.cread], lflag = TTY.L.flags [], cc = Posix.TTY.V.cc [], ispeed = TTY.b9600, ospeed = TTY.b9600} val ios = TTY.termios fields val _ = TTY.setattr (fd, TTY.TC.saflush, ios) *) val ios = TTY.getattr fd val _ = IO.close fd in ios end end Transcript: - use "read.sml"; structure Read : sig structure FS : structure IO : structure TTY : val O_RDWR : ?.POSIX_FileSys.open_mode val exp : unit -> ?.POSIX_TTY.termios val no_flags : ?.POSIX_FileSys.O.flags val openf : string -> ?.POSIX_FileSys.file_desc end val it = () : unit - Read.exp (); uncaught exception in compiler: Representation raised at: boot/Unsafe/object.sml:106.17-106.31 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 util/pp.sml:554.6 build/evalloop.sml:196.58 - Comments: Everything that I can find built with WORD_ALLOC seems to be wrong in this way. Fix: [jhr, 9/10/97] The problem is that the WORD_ALLOC (and INT32_ALLOC) macros in the run-time are allocating records, when they should be allocating 4-byte vectors. Test: * Owner: jhr Status: fixed in 109.32 [jhr, 9/10/97] ---------------------------------------------------------------------- Number: 1277 Title: Segmentation fault Keywords: OS.FileSys OS.Path under suspicion, but perhaps it is eXene specific. Submitter: nikolaj@cs.stanford.edu Date: jada jada jada Version: 109.31 System: sparc-solaris2.5 Severity: critical Problem: I am able to make 109.31 terminate with a segmentation fault. The problem could be connected to the IS.FileSys structures, but then I was able to generate segmentation faults without calls to OS. In the process of identifying the source of the problem further I ran the following experiments which had some strange behaviour: - open Posix.FileSys; opening Posix.FileSys POSIX_FILE_SYS - stat "/manet/u1"; val it = ST {atime=TIME {sec=873972901,usec=0},ctime=TIME {sec=867367954,usec=0}, uncaught exception in compiler: Representation raised at: boot/Unsafe/object.sml:106.17-106.31 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 util/pp.sml:554.6 build/evalloop.sml:196.58 - In fact my code never calls this function, so this bug seems to be rather peripheric to the main problem. The Segmentation faults seem to happen in some different ways: manet> ./new-step GC #0.0.0.0.1.1: (0 ms) GC #0.0.0.1.2.2: (30 ms) STeP Version 1.2-beta (educational release) Compiled Wed Sep 10 02:53:48 1997 Copyright 1995, 1996, 1997 Stanford University Computer Science Department SML Version: 109 Concurrent ML, Version 1.0.9, September 1, 1997 GC #0.0.0.2.3.3: (30 ms) GC #0.0.1.3.4.27: (50 ms) Segmentation fault (core dumped) ------------------------------------------------- manet> ./new-step GC #0.0.0.0.1.1: (0 ms) GC #0.0.0.1.2.2: (10 ms) STeP Version 1.2-beta (educational release) Compiled Wed Sep 10 02:53:48 1997 Copyright 1995, 1996, 1997 Stanford University Computer Science Department SML Version: 109 Concurrent ML, Version 1.0.9, September 1, 1997 GC #0.0.0.2.3.3: (20 ms) GC #0.0.1.3.4.49: (50 ms) GC #0.1.2.4.5.99: (110 ms) GC #0.1.3.5.6.100: (40 ms) GC #1.2.4.6.7.114: (150 ms) GC #1.3.5.7.8.126: (50 ms) Segmentation fault Comments: [jhr, 9/11/97] This Representation exception bug is because we are allocating Word32.word values in the run-time with the wrong tag. Someone else reported it yesterday, and it has already been fixed for the next release. If you want, I can send you a replacement for src/runtime/include/ml-objects.h that fixes the bug. Fix: Test: Owner: jhr Status: fixed in 109.32 [jhr, 9/19/97] ---------------------------------------------------------------------- Number: 1278 Title: segmentation faults running Unix.execute Keywords: Unix.execute, segmentation fault, core dump Submitter: Nikolaj Bjorner Date: 9/11/97 Version: 109.31 System: sparc-solaris? Severity: critical Problem: We have now encountered some Segmentation faults while running Unix.execute from inside RunCML. I have not been able to reproduce the Segmentation fault on a simple example yet, but the following code: structure Test = struct fun doit fileName () = let val proc = Unix.execute(fileName,[]) val (fin,fout) = Unix.streamsOf proc in TextIO.closeIn fin; TextIO.closeOut fout; () end fun run fileName = (print ("\n"^(fileName)^":\n"); RunCML.doit(doit fileName, NONE) ) end has the following effect: manet> /step/sml/bin/cml-cm Concurrent ML, Version 1.0.9, September 1, 1997[CML autoload] - CM.make(); [starting dependency analysis] [scanning .... ..ecovering /step/sml-109.31/src/cml/src/glue/CM/sparc-unix/export-fn-fn.sml.bin... done] [recovering /step/sml-109.31/src/cml/src/glue/CM/sparc-unix/run-cml-fn.sml.bin... done] [recovering /step/sml-109.31/src/cml/src/Unix/CM/sparc-unix/unix-glue.sml.bin... done] [recovering /step/sml-109.31/src/cml/src/Unix/CM/sparc-unix/run-cml.sml.bin... done] [recovering CM/sparc-unix/test.sml.bin...GC #0.0.0.1.5.149: (10 ms) done] [introducing new bindings into toplevel environment...] val it = () : unit - Test.run "ls"; ls: manet> That is, the ML session is terminated. Comments: Fix: Test: Owner: jhr Status: fixed in 109.32 [jhr, 9/19/97] ---------------------------------------------------------------------- Number: 1279 Title: frags and backquotes are confused Keywords: frag Submitter: Elsa L. Gunter Date: 9/12/97 Version: 109.31 System: x86-linux2.0 Severity: major Problem: The type constructor frag is not present at top level, and when given a quote it sits waiting further input regardles of the state of Compiler.Control.quotation. Code: fn x:'a frag => x; val y = 'a'; Transcript: norfolk% sml Standard ML of New Jersey, Version 109.31, September 8, 1997 [CM; autoload enabled] - fn x:'a frag => x; stdIn:17.9-17.13 Error: unbound type constructor: frag - val y = 'a'; = = = stdIn:2.4 Error: syntax error found at TYVAR - Comments: I typed ^D to get to return to top level. The behavior is the same if you set Compiler.Control.quotation:= true; [jhr, 9/12/97] Quotation sort of works in my modified 109.31, but the translation of syntax is broken: Standard ML of New Jersey, Version 109.32, September 15, 1997 [new runtime] - Compiler.Control.quotation := true; val it = () : unit - `a`; stdIn:8.1-8.4 Error: unbound variable or constructor: QUOTE - datatype frag = datatype SMLofNJ.frag; datatype 'a frag = ANTIQUOTE of 'a | QUOTE of string - `a`; val it = [QUOTE "a"] : 'a frag list Fix: Added (strSymbol "SMLofNJ") to quoteDcon and antiquoteDcon in parse/astutil.sml. Test: bug1279.sml Owner: dbm Status: fixed in 109.32 [dbm, 9/12/97] ---------------------------------------------------------------------- Number: 1280 Title: structure sharing semantics Keywords: modules, signatures, structure sharing Submitter: Andrew Appel Date: 9/16/97 Version: 109.31 System: - Severity: major Problem: SML 97 semantics of structure sharing not implemented. Code: signature INT = sig type t=int end structure ONE :> INT = struct type t=int end structure TWO :> INT = struct type t=int end functor F(structure A:INT structure B:INT sharing A=B) = struct end structure THREE=F(structure A=ONE structure B=TWO) Transcript: Standard ML of New Jersey, Version 109.31, September 8, 1997 [CM&CMB] val it = () : unit - use "s3"; [opening s3] s3:5.17-5.51 Error: structure sharing violation: A # B uncaught exception Error raised at: build/evalloop.sml:105.44-105.52 build/evalloop.sml:123.38 build/evalloop.sml:196.58 build/evalloop.sml:292.19-292.22 Comments: Fix: Test: bug1280.sml Owner: dbm Status: fixed in 109.32 [dbm] ---------------------------------------------------------------------- Number: 1281 Title: Open in local-in-end can give "Compiler bug: PickMod: dontPickle" Keywords: compiler bug, local-in-end, open Submitter: Kjeld H. Mortensen Date: 9/16/1997 Version: 109.31 System: sparc-solaris2.5.1 Severity: major Problem: source code below results in "Compiler bug: PickMod: dontPickle" Code: structure foo = struct val myfoo = 0 end; structure bar = struct val mybar =0 end; local open foo in open bar end; Transcript: Standard ML of New Jersey, Version 109.31, September 8, 1997 - structure foo = struct val myfoo = 0 end; structure foo : sig val myfoo : int end - structure bar = struct val mybar =0 end; structure bar : sig val mybar : int end - local open foo in open bar end; Error: Compiler bug: PickMod: dontPickle Comments: The above example works fine with SML/NJ 109.30. Fix: Test: bug1281.sml Owner: dbm Status: fixed in 109.32 [Zhong] ---------------------------------------------------------------------- Number: 1282 Title: sharing syntax not consistent with SML 97 Keywords: syntax, sharing, SML 97 Submitter: Dave MacQueen Date: 9/18/97 Version: 109.31 System: - Severity: minor Problem: The syntax of sharing specs has changed in SML 97, and we are not implementing the new syntax at the moment. The old syntax allowed multiple sharing equations separated by "and", as in sharing A.B = C.D and type A.t = E.s = F.s and B = C.B (with the "type" keyword binding tighter than the "and"). Also sharing constraints were a spec (which means that one could occur at the beginning of a signature before any other specs). In the SML 97 grammar, sharing constraints are a spec modifier, so they apply to the sequence of contraints preceeding them. This means that they can't appear at the beginning of a signature (which wouldn't make sense anyway, since the paths refered to in the sharing equations have to be local to the innermost signature containing the sharing specs). Also, multiple sharing equations separated by "and" is not provided in SML 97, so the above example would have to be written as sharing A.B = C.D sharing type A.t = E.s = F.s sharing B = C.B Code: signature S = sig type t type u type v sharing type t = u and type u = v end; Transcript: Comments: Fix: change grammar Test: bug1282.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1283 Title: Representation exception raised during value pretty printing Keywords: representation, pretty printing Submitter: Kenneth Cline Date: 9/19/97 Version: 109.31+ System: - (sgi-irix) Severity: major Problem: The following code causes the 109.31 compiler to raise an the Representation exception. Code: type 'a queue = 'a list * 'a list; val empty : 'a queue = (nil, nil); Transcript: /home/sml/Dev/jhr/109.x/bin/sml Standard ML of New Jersey, Version 109.32, September 15, 1997 [new runtime] - type 'a queue = 'a list * 'a list; type 'a queue = 'a list * 'a list - val empty : 'a queue = (nil, nil); uncaught exception in compiler: Representation raised at: boot/Unsafe/object.sml:65.19-65.33 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 util/pp.sml:554.6 build/evalloop.sml:194.58 Comments: [jhr, 9/19/97] Some more information: it appears that the pretty printer is calling Unsafe.Object.toTuple with an unboxed value. Do you have any idea why that might be? [Zhong, 9/19/97] Yes, ([], []) is a polymorphic record that when applied returns a pair of 0s in two general purpose registers (as records are always flattened when returned as results) --- the toTuple function is trying to cast a 0 into a tuple, thus the problem. I can easily get the compiler to handle val empty : 'a queue = (nil, nil); just as we deal with "val empty = (nil, nil);" Fix: Test: bug1283.sml Owner: jhr, Zhong Status: fixed in 109.32 [Zhong, 9/22/97] ---------------------------------------------------------------------- Number: 1284 Title: bogus file created upon aborted run of ml-lex Keywords: ml-lex, CM Submitter: Matthias Blume, blume@cs.princeton.edu Date: Sun Sep 28 12:24:15 EDT 1997 Version: 109.31 System: all Severity: minor Problem: ML-Lex creates its output file (.lex.sml) too early. If the Lex specification has errors that force ml-lex to quit, then there will be a new, empty SML output file. If the programmer overlooks the error and runs CM.make() again, then CM will mistakenly assume that .lex.sml is up-to-date, because it is younger than .lex. Therefore, under these circumstances, ml-lex will not be invoked again. Empty ML source files are legal, though. This causes an error message down the line when structure Mlex (or equivalent) is not found. Code: Any syncatically incorrect ML-Lex specification that is used as part of a CM-managed project. Transcript: Comments: I could hack CM to cope with this problem (for example by removing the bogus output file when ml-lex returns with an exit status other than 0). But I think the problem should be solved at its origin. Fix: *** lexgen.sml.orig Sun Sep 28 12:44:11 1997 --- lexgen.sml Sun Sep 28 12:45:26 1997 *************** *** 1257,1267 **** --- 1257,1269 ---- parse() handle x => (close_ibuf(!LexBuf); TextIO.closeOut(!LexOut); + OS.FileSys.remove outfile; raise x) val (fins,trans,tctab,tcpairs) = makedfa(rules) val _ = if !UsesTrailingContext then (close_ibuf(!LexBuf); TextIO.closeOut(!LexOut); + OS.FileSys.remove outfile; prErr "lookahead is unimplemented") else () in Test: * Owner: Andrew, Matthias Status: fixed in 109.32+ ---------------------------------------------------------------------- Number: 1285 Title: Compiler bug: LtyEnv: unexpected tycs in tcWhNorm-TC_PROJ Keywords: modules, functors, higher-order functors Submitter: Andrew Appel Date: 10/2/97 Version: 109.32- System: - Severity: critical Problem: Example functor code from MacQueen/Tofte paper on higher order functor fails with Compiler bug: LtyEnv: unexpected tycs in tcWhNorm-TC_PROJ Code:(* bug1285.sml *) signature POINT = sig type point end; signature INTERVAL = sig type point val mk : point * point -> unit end; functor Interval(P: POINT) : INTERVAL = struct type point = P.point fun mk(x,y) = () (* <=== culprit is the pair (x,y) *) end; structure IntPoint : POINT = struct type point = int end; functor G(functor Interv(P: POINT) : INTERVAL) = struct structure NatNumInt = Interv(IntPoint) end; Transcript: - use "test/mods/270.sml"; [opening test/mods/270.sml] signature POINT = sig type point val <= : point * point -> bool end signature INTERVAL = sig type interval type point val mk : point * point -> interval val left : interval -> point val right : interval -> point end functor Interval : structure IntPoint : POINT structure T : INTERVAL val test = 9 : T.point Error: Compiler bug: LtyEnv: unexpected tycs in tcWhNorm-TC_PROJ - Comments: Fix: changes to basics/ltyenv.sml and modules/instantiate.sml Test: bug1285.sml Owner: Zhong Status: fixed in 109.32 [Zhong, 10/3/97] ---------------------------------------------------------------------- Number: 1286 Title: Flexible records and as patterns Keywords: Submitter: Stephen Weeks Date: 10/7/97 Version: 109.32 System: x86-linux Severity: minor Problem: I don't know if this is a bug, but it certainly was surprising to me. The following program succeeds (this seems right) : fun f() = let val {a,...} = g() in () end and g() = {a = (), b = ()} The following program does not type check (this seems wrong), although the only difference from the above is the introduction of an as pattern binding x. fun f() = let val x as {a,...} = g() in () end and g() = {a = (), b = ()} The error message is the following: Error: unresolved flex record (can't tell what fields there are besides #a) Code: fun f() = let val x as {a,...} = g() in () end and g() = {a = (), b = ()} Transcript: Comments: Fix: Test: bug1286.sml Owner: dbm Status: fixed in 110 [Zhong, 10/10/97] ---------------------------------------------------------------------- Number: 1287 Title: SML'97 scoping restrictions on local datatypes Keywords: type checking, local datatypes Submitter: Andrew.Kennedy@persimmon.co.uk Date: 10/7/97 Version: 109.32 System: Alpha, Digital Unix 4.0 Severity: Minor Problem: Code in section G.7 of Revised Defn elaborates; it shouldn't Code: (from Defn) val a = let datatype t = C in C end; val b = fn x => let datatype t = C val _ = if true then x else C in 5 end; Transcript: val a = C : ?.t val b = fn : ?.t -> int Comments: Bug not really a problem: just language pedantry. Fix: Implement side-conditions on rules 4, 14, 26 of Defn Test: bug1287.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1288 Title: readDir returns "." and ".." Keywords: input/output, directories, OS.FileSys Submitter: John Reppy Date: 10/7/97 Version: 109.32 System: - Severity: minor Problem: our implementation of readDir returns "." and "..". I believe that the latest version of the spec says that these are filtered out of the stream. Comments: the basis spec is a bit unclear on this --- for Posix.FileSys.readDir, it specifies this behavior, but not for OS.FileSys.readDir. Fix: Test: Owner: jhr Status: fixed in 110 ---------------------------------------------------------------------- Number: 1289 Title: readDir and rewindDir raise the wrong exception on closed dir stream Keywords: input/output, directories, OS.FileSys Submitter: John Reppy Date: 10/7/97 Version: 109.32 System: - Severity: minor Problem: readDir and rewindDir raise the wrong exception when the directory stream is closed: - readDir dstr; uncaught exception Fail: readdir on closed directory stream raised at: boot/Posix/posix-filesys.sml:72.10-72.51 - rewindDir dstr; uncaught exception Fail: rewinddir on closed directory stream raised at: boot/Posix/posix-filesys.sml:76.10-76.53 - closeDir dstr; These should raise OS.SysErr. Comments: Fix: Test: Owner: jhr Status: fixed in 110 ---------------------------------------------------------------------- Number: 1290 Title: OS.FileSys.fullPath raises exception on symbolic link Keywords: input/output, directories, OS.FileSys Submitter: John Reppy Date: 10/7/97 Version: 109.32 System: - Severity: minor Problem: OS.FileSys.fullPath is raising an exception when applied to what seems to be an okay symbolic link. uncaught exception SysErr: No such file or directory [noent] raised at: boot/Unix/os-filesys.sml:78.39-78.41 The function realPath has the same problem. Comments: This was a bug in the run-time system (same bug as 1291). Fix: Test: Owner: jhr Status: fixed in 110. ---------------------------------------------------------------------- Number: 1291 Title: OS.FileSys.readLink returns bogus results Keywords: input/output, directories, OS.FileSys Submitter: John Reppy Date: 10/7/97 Version: 109.32 System: - Severity: minor Problem: ls -l testlink lrwxrwxrwx 1 george 6 Mar 12 1997 testlink -> README - readLink "testlink"; val it = "testli" : string Comments: This was a bug in the run-time system (same bug as 1290). Fix: Test: Owner: jhr Status: fixed in 110 ---------------------------------------------------------------------- Number: 1292 Title: val rec (fun) should be able to rebind constructor id Keywords: type checking Submitter: Dave MacQueen Date: 10/8/97 Version: 109.32 System: - Severity: minor Problem: val rec or fun declarations fail if the identifier being bound is a constructor name. This should be allowed according to the SML 97 Defn (p. 24, rule (26)). Code: Transcript: - datatype t = f; datatype t = f - val rec f = fn x => x; stdIn:13.9-13.22 Error: rebinding data constructor "f" as variable - fun f x = x; stdIn:2.4-2.11 Error: rebinding data constructor "f" as variable Comments: Fix: Test: bug1292 Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1293 Title: CharVector.mapi doesn't work with non-zero start index Keywords: Basis CharVector mapi Submitter: Andrew.Kennedy@persimmon.co.uk Date: 10/8/97 Version: 109.32 System: Alpha, Digital Unix 4.0 Severity: Minor Problem: CharVector.mapi always starts from index 0 Code: CharVector.mapi (fn (i, c) => (print (Int.toString i ^ "\n"); c)) ("ABCDEFG", 2, SOME 3) Transcript: 0 1 2 val it = "ABC" : vector Comments: By the way, CharVector.{map,mapi} aren't documented [jhr] Same bug occurs for Word8Vector.{map,mapi}. Fix: Test: * Owner: jhr Status: fixed in 110. ---------------------------------------------------------------------- Number: 1294 Title: Real.fromString accepts too much Keywords: Basis Submitter: Andrew.Kennedy@persimmon.co.uk Date: 10/8/97 Version: 109.32 System: any Severity: Minor Problem: Real.fromString "1.e1" should return 1.0, since "1" is the longest prefix of "1.e1" which can be parsed as a real (according to the basis library specification). New Jersey ML 109.32 returns "10.0". Code: Real.fromString "1.e1" Transcript: - Real.fromString "1.e1"; val it = SOME 10.0 : real option Comments: Fix: Test: bug1294.sml Owner: jhr Status: fixed in 110.0.6 ---------------------------------------------------------------------- Number: 1295 Title: SMLofNJ.exportFn should complain about an empty name Keywords: exportFn runtime Submitter: Daniel C. Wang danwang@cs.princeton.edu Date: 10/7/97 Version: 109.32 and probably all previous versions System: Unix Severity: cosmentic Problem: When you do an exportFn and pass it the empty string as the name of the heap image it goes ahead and creates a heap named ".heap-suffix", which is a hidden file in Unix and doesn't behave in a obvious way on a Unix system. Code: SMLofNJ.exportFn("",fooFn); Transcript: Comments: Fix: I've added code to raise SysErr when either exportML or exportFn is called with "" as the filename. [jhr, 10/10/97] Test: * Owner: jhr Status: fixed in 110 [jhr, 10/10/97] ---------------------------------------------------------------------- Number: 1296 Title: Datatype replication and signature matching. Keywords: modules, signatures, datatype replication Submitter: Stephen Weeks Date: 10/15/97 Version: 109.32 System: x86-linux Severity: major Problem: This bug is similar to 1255. The following code is rejected by SML/NJ with the following error message Error: value type in structure doesn't match signature spec name: A spec: ?.b -> ?.S.t actual: ?.b -> ?.S.t Code: structure S : sig datatype t = A of b and b = B structure T : sig datatype u = datatype t end end = struct datatype t = A of b and b = B structure T = struct datatype u = datatype t end end Transcript: Comments: Fix: Have spec entVar be the same as formal tycon stamp in type specs. Then use this fact to translate RECtycs to PATHtycs in the datacon domains introduced by datatype replication specs. Test: bug1296.sml Owner: dbm Status: fixed in 110 [dbm, 10/16/97] ---------------------------------------------------------------------- Number: 1297 Title: Compile time and space performance bug Keywords: image size, compilation time Submitter: Stephen Weeks Date: 10/13/97 Version: 109.32 System: x86-linux Severity: major Problem: The following code requires 470 seconds to compile using CM and produces a five megabyte bin file on my 200MhZ Pentium. Furthermore, the time and space seem to vary at least as bad as exponentially in the size of the program. Code: signature U = sig structure T : sig end end signature V2 = sig structure T1 : sig end structure T2 : sig end structure T3 : sig end structure T4 : sig end structure T5 : sig end structure T6 : sig end structure T7 : sig end structure U1 : U where T = T1 structure U2 : U where T = T2 structure U3 : U where T = T3 structure U4 : U where T = T4 structure U5 : U where T = T5 structure U6 : U where T = T6 structure U7 : U where T = T6 end structure V2 :> V2 = struct structure T = struct end structure T1 = T structure T2 = T structure T3 = T structure T4 = T structure T5 = T structure T6 = T structure T7 = T structure U = struct structure T = T end structure U1 = U structure U2 = U structure U3 = U structure U4 = U structure U5 = U structure U6 = U structure U7 = U end Transcript: Comments: [Blume, 10/13/97] It must be a pickling problem then. The toplevel compiler and the one called by CM are pretty much the same -- except the toplevel does not call the pickler anymore. Incidentally, Manuel Fahndrich reported something that sounds similar (related to opaque matching and filtering). [dbm,10/15/97] Definitely a pickling blowup. Here is the Stats summary after CM.make(). Code Size 632 Pickle Bytes 4732609 Source Lines 0 Compiler 010 Parse 0.00u 0.01s 0.00g Compiler 030 Elaborate 0.01u 0.00s 0.00g Compiler 032 1-instParam 0.00u 0.00s 0.00g Compiler 033 1-mapPaths 0.00u 0.00s 0.00g Compiler 033 5-transType 0.00u 0.00s 0.00g Compiler 035 decType 0.00u 0.00s 0.00g Compiler 036 pickUnpick 410.48u 23.09s 112.63g Compiler 038 1-SCStatenv 2.92u 0.02s 0.91g Compiler 040 Translate 1.79u 0.57s 1.79g Compiler 044 x-evalApp 0.00u 0.00s 0.00g Compiler 045 matchcomp 0.00u 0.00s 0.00g Compiler 047 reformat 0.00u 0.00s 0.00g Compiler 050 CodeOpt 0.00u 0.00s 0.00g Compiler 051 1-ltAppSt 0.00u 0.00s 0.00g Compiler 051 2-ltAppSt 0.00u 0.00s 0.00g Compiler 052 lcontract 0.00u 0.00s 0.00g Compiler 053 specLexp 0.00u 0.00s 0.00g Compiler 054 wrapLexp 0.00u 0.00s 0.00g Compiler 055 ltyComp 0.00u 0.00s 0.00g Compiler 056 ltNarrow 0.00u 0.00s 0.00g Compiler 057 lambdaopt 0.00u 0.00s 0.00g Compiler 058 reorder 0.00u 0.00s 0.00g Compiler 060 Convert 0.01u 0.00s 0.00g Compiler 065 CPStrans 0.00u 0.00s 0.00g Compiler 070 cpsopt 0.00u 0.00s 0.00g Compiler 079 freemapClose 0.01u 0.00s 0.00g Compiler 080 closure 0.00u 0.00s 0.00g Compiler 090 globalfix 0.00u 0.00s 0.00g Compiler 100 spill 0.00u 0.00s 0.00g Compiler 110 limit 0.00u 0.00s 0.00g Compiler 120 cpsgen 0.00u 0.00s 0.00g Compiler 130 Schedule 0.00u 0.00s 0.00g Compiler 140 CodeGen 0.00u 0.01s 0.00g Execute 0.02u 0.11s 0.00g Other 0.01u 0.00s 0.00g TOTAL 415.24u 23.81s 115.33g No blowup seen if the file is compiled with "use" (interactive top level, and "use", do not pickle). Fix: Test: bug1297.sml Owner: dbm, Zhong, Appel Status: fixed in 110 [Appel, dbm, 10/17/97] ---------------------------------------------------------------------- Number: 1298 Title: TransTypes: unexpected FORMAL kind in tycTyc-h Keywords: functors, CM Submitter: Andrew.Kennedy@persimmon.co.uk Date: 10/16/97 Version: 109.32 System: Alpha, Digital Unix 4.0 Severity: Major Problem: fatal error in CM.make (it doesn't seem to happen with use) when compiling the following bunch of files. Code: =============== (* sources.cm *) Group is F.sml Test.sml =============== (* F.sml *) functor F(type Error) :> (* must be opaque constraint *) sig datatype Result = Failure of Error (* "type Result" won't do *) val run : Result -> unit end = struct datatype Result = Failure of Error fun run m = () end =============== (* Test.sml *) structure Test = F(type Error = string) =============== Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM&CMB] val it = () : unit - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/sparc-unix/sources.cm.stable ... not usable] [parsing F.sml] [Creating directory CM/DEPEND ...] [parsing Test.sml] [dependency analysis completed] [compiling F.sml -> CM/sparc-unix/F.sml.bin] [Creating directory CM/sparc-unix ...] [wrote CM/sparc-unix/F.sml.bin] [compiling Test.sml -> CM/sparc-unix/Test.sml.bin] Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h uncaught exception Error raised at: util/errormsg.sml:54.14-54.19 translate/translate.sml:129.39 translate/translate.sml:129.39 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 Comments: [Matthias, 10/16/97] This, again, seems to be pickling-related because the main difference between the top level and CM is now that the former doesn't pickle anymore. Fix: Test: cmtests/bug1298 Owner: dbm, Zhong Status: fixed in 110 [Zhong, 10/19/97] ---------------------------------------------------------------------- Number: 1299 Title: some error messages aren't being sent to stderr Keywords: errors, printing, stderr Submitter: lorenz Date: 10/16/98 Version: 109.32 System: presumably all Severity: minor Problem: Not all error messages are being sent to stderr. Transcript: $ /usr/local/sml/109.32/bin/sml 2>/dev/null Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - asdf; stdIn:17.1-17.5 Error: unbound variable or constructor: asdf - Comments: [jhr, 10/16/97] I think this is not a bug, but a feature. Remember that SML/NJ is an interactive system, thus error messages are part of the basic dialogue with the user. Fix: Test: Owner: Status: open ---------------------------------------------------------------------- Number: 1300 Title: type printing of datacon domain Keywords: printing, types Submitter: Dave MacQueen Date: 11/11/97 Version: 109.32+ System: - Severity: medium Problem: Int32.int printed as ?.int32 in the domain of a dataconstructor. Similarly for Word32.word. Code: Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [new runtime] - 3: Int32.int; val it = 3 : Int32.int - datatype t = T of Int32.int; datatype t = T of ?.int32 Comments: Fix: Test: bug1300.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1301 Title: too big real literal yields uncaught exception BadReal Keywords: real, literals Submitter: Dave MacQueen Date: 11/11/97 Version: 109.32+ System: sparc-solaris Severity: medium Problem: too big real literal yields uncaught exception BadReal Transcript: - 1.0E309; uncaught exception BadReal raised at: bignums/realconst.sml:228.54-228.63 Comments: Fix: Test: bug1301.sml Owner: Andrew Status: open ---------------------------------------------------------------------- Number: 1302 Title: handling differing newline conventions across OSes Keywords: strings, input/output Submitter: Bob Harper (rwh@cs.cmu.edu) Date: 10/10/97 Version: 109.32 System: - Severity: medium Problem: Would you please change the NJ lexer so that it ignores CR's in all cases? For various reasons I'm having to move files back and forth between NT and Unix. Guess what? Under NT lines are terminated by both CR and LF (belt and suspenders). If I copy from NT to Unix and run NJ on the file, I get zillions of lexer errors because of the CR's. Code: Transcript: Comments: [Matthias, 10/11/97] Suggested fix: *** ml.lex.old Tue Aug 26 15:25:26 1997 --- ml.lex Sat Oct 11 12:56:03 1997 *************** *** 78,85 **** %arg ({comLevel,sourceMap,err,charlist,stringstart,stringtype,brack_stack}); idchars=[A-Za-z'_0-9]; id=[A-Za-z]{idchars}*; ! ws=("\012"|[\t\ ])*; ! nrws=("\012"|[\t\ ])+; some_sym=[!%&$+/:<=>?@~|#*]|\-|\^; sym={some_sym}|"\\"; quote="`"; --- 78,85 ---- %arg ({comLevel,sourceMap,err,charlist,stringstart,stringtype,brack_stack}); idchars=[A-Za-z'_0-9]; id=[A-Za-z]{idchars}*; ! ws=("\012"|"\013"|[\t\ ])*; ! nrws=("\012"|"\013"|[\t\ ])+; some_sym=[!%&$+/:<=>?@~|#*]|\-|\^; sym={some_sym}|"\\"; quote="`"; [jhr, 10/14/97] If we are going to fix this, then we should get the newline counting right for all conventions (text files on the Mac use #"\r" for end of line). Also, I think DOS machines use ^Z as EOF, which we probably also need to handle. [Matthias, 10/15/97] I thought that normally TextIO will handle such translations. Bob was only asking that #"\r"s are ignored in the case that they shouldn't have been there in the first place (i.e., when reading a DOS file under Unix). Reading a DOS file under DOS or reading a Mac file under MacOS should never produce #"\r"s in the input stream, because TextIO will translate them away. But this translation will not happen (at least not properly) if the file is transmitted in binary form to a different OS with different conventions. [jhr, 10/15/97] If you snarf a DOS text file to a Unix machine w/o translation, then you get #"\r" at the end of each line, and a #"^Z" at the end of the file. This is the situation that Bob would like fixed. If we are going to fix it, we should do it properly (it is more than just making #"\r" be whitespace). Fix: Test: - Owner: jhr Status: fixed in 110.6, 110.0.4 ---------------------------------------------------------------------- Number: 1303 Title: CM file problems: multiple access not detected Keywords: "CM", "dependency" Submitter: Wolfgang Reissenberger, reissenb@informatik.uni-stuttgart.de Date: 10/23/97 Version: 1.09.32 System: sparc-solaris2.5, x-86-linux Severity: minor Problem: In a hierarchy of files, structures in several files use the same signature lying in an extra file. When CM tries to compile these structures, multiple occurences of the signature seemed to be detected, although they stem from the same source, and the case is uncritical. But CM stops reporting an error. Code: attached as tar.gz file Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - CM.make' "t.cm"; [starting dependency analysis] [scanning t.cm] [checking CM/sparc-unix/t.cm.stable ... not usable] [scanning etc/s1.cm] [checking etc/CM/sparc-unix/s1.cm.stable ... not usable] [parsing etc/s1.sml] GC #0.0.0.0.1.2: (10 ms) [Creating directory etc/CM/DEPEND ...] [parsing div/s.sig] [Creating directory div/CM/DEPEND ...] [scanning pp/s2.cm] [checking pp/CM/sparc-unix/s2.cm.stable ... not usable] [parsing pp/s2.sml] [Creating directory pp/CM/DEPEND ...] !* CM error: t.cm: signature S was imported from both div/s.sig and div/s.sig - Comments: If the signature S is filtered off by etc/s1.cm and pp/s2.cm, the error disappears. [Blume] That is the _real_ bug. Since using ../div/s.sig in two different sources is never legal, it should be reported regardless. [Matthias, 10/23/97] Well, it's a "feature", but one might call it a bug. CM does not permit the same SML source file to be listed in two or more different CM files. Unfortunately, this requirement is not actively enforced. You should put the signature into its own group or library. The same group or library can be imported from by more than one client group. But every source should have a unique group/library that it belongs to. Fix: Test: * Owner: Blume Status: fixed in 110 [Blume, 11/25/97] ---------------------------------------------------------------------- Number: 1304 Title: Type printing of exceptions on top-level Keywords: types, value restriction Submitter: Kjeld H. Mortensen (designCPN-support@daimi.aau.dk) Date: 10/26/1997 Version: 109.32 System: sparc-solaris2.5 Severity: minor Problem: Raising exceptions on top-level results in a type error message Code: raise Overflow; Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - raise Overflow; stdIn:17.1-17.15 Error: nongeneralizable type variable it : 'Z Comments: Works fine in release 0.93 Fix: Print warning instead of error message, with nongeneralized variables instantiated to fresh dummy types named X1, X2, ... Test: - Owner: dbm Status: fixed in 110 [dbm, 11/3/97] ---------------------------------------------------------------------- Number: 1305 Title: translation of newlines in TextIO Keywords: input/output, TextIO Submitter: Dave Berry Date: 10/28/97 Version: 109.32 System: x86-win32 Severity: major Problem: We've just received a bug report from someone who is comparing MLWorks and SML/NJ for Windows 95. He reports that TextIO.output1(outstream, Char.chr 10) behaves differently on the two systems! SML/NJ outputs a single ASCII newline character. MLWorks outputs a carriage return and newline pair. This is causing him problems. We've told him to use BinIO instead. Clearly someone has misunderstood something. The Basis Library is supposed to avoid problems of this kind. I thought TextIO was supposed to map newline characters to pairs -- am I mistaken? Or have the people who ported SML/NJ to Windows 95 made a mistake? Code: Transcript: Comments: [jhr, 10/28/97] I guess that this is our bug. My understanding is that the TextPrimIO structure is responsible for implementing new-line translation. Note that this means that reading from a string does not do translation, and should be portable. Fix: Test: Owner: Lorenz Status: fixed in 110 ---------------------------------------------------------------------- Number: 1306 Title: Refutable patterns and generalization Keywords: Pattern, integer constant, generalization Submitter: Andrew.Kennedy@persimmon.co.uk Date: 10/31/97 Version: 109.32 System: Alpha Severity: Minor Problem: Should see "Error: nongeneralizable type variable" when pattern is refutable; with integer constants we don't Code: val (5, x) = (5, []) Transcript: - val (5, y) = (5, []); stdIn:1.2-107.7 Warning: binding not exhaustive ((5 : int),y) = ... val y = [] : 'a list - Comments: For language pedants only! Fix: Class special constants as refutable Test: bug1306.sml Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1307 Title: Illegal escapes in strings not recognized Keywords: strings lexer Submitter: Riccardo Pucella riccardo@research.bell-labs.com Date: 11/05/97 Version: 109.32 System: Any/All Any Unix Subsystem: SML compiler Severity: minor Problem: An illegal escape character in a string will raise a "unclosed string" error instead of a "illegal escape" error. Code: Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - "another simple \k test"; stdIn:17.1-17.18 Error: unclosed string stdIn:17.24-17.26 Error: unclosed string Comments: Fix: Test: bug1307.sml Owner: ? Status: open ---------------------------------------------------------------------- Number: 1308 Title: uncaught exception Representation in Version 109.32 Keywords: "pp.sml", "modules" Submitter: Olivier Danvy, danvy@brics.dk Date: 11/12/97 Version: 109.32 System: linux, SGI Severity: minor Problem: an error is raised when priting a result Code: ---------- (* bug1308.2.sml *) signature STO = sig type store val update : (store -> 'a) -> 'a end; signature COMP = sig type 'a lift val rap : 'a -> 'a lift val uplift : ('b lift) -> 'b lift end; functor F (structure S : STO structure C : COMP) : sig val x : S.store C.lift end = struct val x = C.uplift (S.update (C.rap: S.store -> S.store C.lift)) end; structure Sto : STO = struct type store = string list * int list fun update f = f (["x"],[0]) end; structure CPS : COMP = struct type 'a lift = ('a -> Sto.store) -> Sto.store fun rap (v: 'a) (k: 'a -> Sto.store) = k v fun uplift (f: 'a lift) (k: 'a -> Sto.store) = f k end; structure R = F (structure S = Sto structure C = CPS); val s2' = R.x (fn x => x); ---------- Transcript: ---------- Standard ML of New Jersey, Version 109.32, October 1, 1997 [new runtime] - use "bug1308.2.sml"; [opening bug1308.2.sml] signature STO = sig type store val update : (store -> 'a) -> 'a end signature COMP = sig type 'a lift val rap : 'a -> 'a lift val uplift : 'a lift -> 'a lift end functor F : GC #0.0.0.0.1.3: (0 ms) structure Sto : STO structure CPS : COMP structure R : sig val x : store lift end uncaught exception Representation raised at: boot/Unsafe/object.sml:65.19-65.33 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 print/ppobj.sml:354.20 util/pp.sml:554.6 ---------- Comments: Evaluating "val s2' = ImpCPS'.C p2 (["x"],[0]) Ans'.k_init" yields the error above, but evaluating "val s2' = Ans'.k_init (["x"],[43]);" yields "val s2' = VAL (["x"],[43]) : Ans'.answer" without raising an error. Fix: Test: bug1308.1.sml, bug1308.2.sml, bug1308.3.sml (segmentation fault) bug1308.4.sml, bug1308.5.sml (PPObj: switch: none of the datacons matched) Owner: Zhong Status: fixed in 110 [Zhong, 11/17/97] ---------------------------------------------------------------------- Number: 1309 Title: SML/NJ not safe for space Keywords: safe for space, tail-call optimization, memory leak Submitter: Henry Cejtin, henry@research.nj.nec.com Date: 11/20/97 Version: 109.29 System: Linux Severity: major Problem: The following two programs should both run in constant space but each requires an unbounded amount of space. Code: fun noop1 x = x; fun f (x: int, y: int): int*int = (y, x); fun spin1 (f: int*int -> int*int) = spin1 (noop1 f); fun noop2 x = x; fun spin2 (): int*int = noop2 spin2 (); Transcript: Either of the following starts a non-terminating computation (which is correct) which uses an unbounded amount of space (which is incorrect). spin1 f; spin2 (); Comments: From looking at the generated assembler code, the problem is that the polymorphic identity function must get a procedure which takes arguments in the generic place (a single tuple) and returns results in the generic place (again, a tuple), but the f function takes them spread in registers and returns them the same way. Thus inside spin1, f is first wrapped in a procedure to make it obey the generic calling convention. As a result, the argument to spin grows bigger and bigger (and would be slower and slower if used) on each iteration. If you replace the definition of noop1 with fun noop1 (x: int*int -> int*int) = x; then it runs in constant space. A slightly more subtle problem with the wrapping code is that it causes the procedure that was wrapped to be called from a non-tail position, even if the result of the wrapping is called from a tail position. This is what causes spin2 (); to require unbounded space. Again, if you replace noop2 with the type-specific version fun noop2 (x: unit -> int*int): unit -> int*int = x; or you change the type of spin2 from uint -> int*int to uint -> int then it runs in constant space. Note, this is really what was going on in bug number 1193. In that report, the code did handlers := ! handlers where handlers was a ref cell holding a procedure. What was going on there was that the code was de-referencing handlers and then wrapping the result to get a non-generic-calling-convention version of the procedure, and then was wrapping that to convert it back to a generic-calling-convention version before storing it. The `fix' seems to have been to make the cpsopt pass smart enough to see that this pair of wrappers cancel and to eliminate them. This fix clearly isn't sufficient since in either of the above cases which fail, if noop1 and noop2 are unknown procedures, you are going to have to wrap the argument one way, and then wrap the result the inverse way. Besides, as the second bad case shows, you can't wrap a procedure to change the way it delivers its results and preserve tail-call optimization (since this really involves wrapping the continuation of the call). It seems to me (definitely quite unenlightened about SML/NJ) that this scheme just can't be made to be safe for space. Even if you believe that the identity function doesn't have to return an object the same size as that which it was given as an argument, wrappers that have to do things AFTER the procedure being wrapped returns are going to violate tail-call optimization. If there are only a few calling conventions, then you can get away with using a code pointer that knows how to handle the generic one and any others (essentially by having multiple entry points, either by using multiple code pointers, or fixed offsets from `the' code pointer). For more than one return convention you have to do the same thing with continuations. Test: - Owner: Zhong, Andrew Status: open ---------------------------------------------------------------------- Number: 1310 Title: ML-Yacc fails to accept double backslash strings in .grm file Keywords: ML-Yacc, parser, backslash Submitter: Richard Boulton rjb@dai.ed.ac.uk Date: 11/20/97 Version: 109.32 System: Sparc SunOS 4.1.3_U1 Subsystem: ML-Yacc Severity: minor Problem: ML-Yacc does not appear to correctly parse embedded ML code in the .grm file when it contains literal strings in which two backslashes are used to represent one backslash character. Code: %% %name Bug %term BSLASH | EOF %nonterm start of bug %pos Integer.int %eop EOF %noshift EOF %pure %verbose %start start %% start : BSLASH (Bug "\\") Transcript: bug.grm, line 16: Error: unclosed string bug.grm, line 16: Error: eof encountered in action beginning here ! bug.grm, line 17: Error: syntax error found at EOF ? ml-yacc: uncaught exception ParseError Comments: Fix: Test: Owner: Andrew, John, Emden? Status: open ---------------------------------------------------------------------- Number: 1311 Title: odd secondary typing error after incorrect datatype decl Keywords: typing Submitter: John Reppy Date: 11/19/97 Version: 109.32+ System: - Severity: minor Problem: After an improper datatype declaration containing free type variables on the rhs, but no type variable formal parameters on the lhs, an odd type error results involving UBOUND type variables. Code: (* bug1311.sml *) structure A = struct datatype t = C of ('a * 'a) fun f (cons, C(x,y)) = C(cons x, cons y) end; Transcript: - use "rbug.sml"; [opening rbug.sml] rbug.sml:3.3-3.30 Error: unbound type variable in type declaration: 'a rbug.sml:4.27-4.43 Error: operator and operand don't agree [UBOUND match] operator domain: 'a operand: 'a in expression: cons y Comments: Fix: Test: bug1311.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1312 Title: CM.autoloading always returns false Keywords: CM, autoloading Submitter: Dave MacQueen Date: 11/22/97 Version: 109.33 System: - Severity: minor Problem: CM.autoloading always returns false, even after "CM.autoloading (SOME true)" is executed. Transcript: - CM.autoloading NONE; val it = false : bool - CM.autoloading (SOME true); val it = false : bool - CM.autoloading (SOME false); val it = false : bool - CM.autoloading (SOME true); val it = false : bool - CM.autoloading NONE; val it = false : bool - CM.autoloading (SOME false); val it = false : bool - CM.autoloading NONE; val it = false : bool Comments: Fix: Test: - Owner: dbm Status: fixed in 110 [Matthias, 11/23/97] ---------------------------------------------------------------------- Number: 1313 Title: CM autoloader doesn't cope with . Keywords: CM, autoloader, modules, functors Submitter: Dave MacQueen Date: 11/22/97 Version: 109.33 System: - Severity: major Problem: CM autoloader doesn't cope with . Code: (run in sml-cm) M.autoloading (SOME true); signature S = sig end; functor Foo (X:S) (Y:S) = X; structure C = Foo(struct end); Transcript: - CM.autoloading (SOME false); val it = false : bool - signature S = sig end; signature S = sig end - functor Foo (X:S) (Y:S) = X; functor Foo : - structure C = Foo(struct end); stdIn:27.11-27.30 Error: structure C defined by partially applied functor - CM.autoloading (SOME true); val it = false : bool - signature S = sig end; signature S = sig end - functor Foo (X:S) (Y:S) = X; functor Foo : - structure C = Foo(struct end); : Undefined structure in path . stdIn:30.11-30.30 Error: structure C defined by partially applied functor - Comments: [dbm, 11/22/97] The message is generated in the function "lookup_path" in the function imports in cm/analysis/imp-exp.sml. It seems that the CM syntax analysis used in the autoloader is not taking account of the introduction of and in the parsing of functor declarations (see AstUtil.fctRes, AstUtil.fsigRes, and AstUtil.fappRes and their use in parse/ml.grm.). I think the main CM dependency analysis does take these derived forms into account. [Matthias, 11/22/97] CM doesn't know that etc. are special. I would prefer if they weren't. Manuel Fahndrich has recently requested this hack to be eliminated from the parser (e.g., moved into the elaborator). I 100% agree with him. This would solve the problem at the root. Fix: moved the , translations of functor declarations and functor application strexps to the elaboration phase. Test: testing/modules/tests/262.sml Owner: dbm, Matthias Status: fixed in 110 [dbm, 11/23/97] ---------------------------------------------------------------------- Number: 1314 Title: ml-burg loops on invalid character in input file Keywords: ml-burg ml-lex exceptions Submitter: manuel@cs.berkeley.edu Date: 11/23/1997 Version: 109.31 and 109.32 System: sparc-solaris2.5 Severity: minor Problem: ml-burg loops on input files containing invalid characters. Code: % ml-burg test.burg or CM.make (); (* in sml-109.32/src/ml-burg *) doit "test.burg"; where test.burg contains the single character '@'. Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - OS.FileSys.getDir(); val it = "/disks/orodruin/aa/projects/sml-109.32/src/ml-burg" : string - CM.make (); [starting dependency analysis] [scanning sources.cm] [checking CM/sparc-unix/sources.cm.stable ... not usable] [scanning ../smlnj-lib/Util/sources.cm] [checking ../smlnj-lib/Util/CM/sparc-unix/sources.cm.stable ... ok - stable] [scanning ../ml-yacc/lib/sources.cm] [checking ../ml-yacc/lib/CM/sparc-unix/sources.cm.stable ... ok - stable] [dependency analysis completed] [recovering ../smlnj-lib/Util/CM/sparc-unix/hash-string.sml.bin... done] [recovering ../smlnj-lib/Util/CM/sparc-unix/hash-key-sig.sml.bin... done] [recovering ../smlnj-lib/Util/CM/sparc-unix/hash-table-rep.sml.bin... done] [recovering ../smlnj-lib/Util/CM/sparc-unix/mono-hash-table-sig.sml.bin... done] [recovering ../smlnj-lib/Util/CM/sparc-unix/hash-table-fn.sml.bin... done] [recovering CM/sparc-unix/burg-ast.sml.bin... done] [recovering ../ml-yacc/lib/CM/sparc-unix/base.sig.bin... done] [recovering ../ml-yacc/lib/CM/sparc-unix/join.sml.bin... done] [recovering ../ml-yacc/lib/CM/sparc-unix/lrtable.sml.bin... done] [recovering ../ml-yacc/lib/CM/sparc-unix/stream.sml.bin... done] [recovering ../ml-yacc/lib/CM/sparc-unix/parser2.sml.bin... done] [recovering CM/sparc-unix/burg-gram.sig.bin... done] [recovering CM/sparc-unix/burg-gram.sml.bin... done] [recovering CM/sparc-unix/errormsg.sml.bin... done] [recovering CM/sparc-unix/burg-lex.sml.bin... done] [recovering CM/sparc-unix/parse.sml.bin... done] [recovering CM/sparc-unix/burg.sml.bin... done] [recovering CM/sparc-unix/main.sml.bin... done] [introducing new bindings into toplevel environment...] val it = () : unit - Main.doit "test.burg"; Interrupt Comments: Produces no output. Looking at the code, the LexError exception should be raised, but it never does. I even modified the source to generate a message before raising LexError, and it is NOT printed. May be a bug in the generated lexer. (Under 109.31, ^C produces a segmentation violation.) Fix: Test: - Owner: Lal Status: open ---------------------------------------------------------------------- Number: 1315 Title: bogus value created (probably representation bug) Keywords: modules, functors, opaque signatures Submitter: Matthias Blume Date: 11/23/97 Version: 109.33 System: - Severity: critical (can cause core dump) Problem: bogus value created Code: signature ASIG = sig type g type n type 'a t val newG: unit -> g val newN: g -> n val nodes: g -> n list val empty: 'a t val add: 'a t * n * 'a -> 'a t val look: 'a t * n -> 'a option val id: n -> string end; structure A :> ASIG = struct type g = (int * int list) ref type n = g * int type 'a t = (n * 'a) list fun newG () = ref (0, []) fun newN (g as ref (n, l)) = let val n' = n + 1 val l' = n' :: l val _ = print (concat ["ID of new node is: ", Int.toString n', "\n"]) in g := (n', l'); (g, n') end fun nodes (g as ref (_, l)) = map (fn n => (g, n)) l val empty = [] fun add (t, n, x) = (n, x) :: t fun look (t, (_, ni)) = let fun sameNode ((_, ni'), _) = ni = ni' in Option.map #2 (List.find sameNode t) end fun id (_, ni) = Int.toString ni end; signature BSIG = sig structure A : ASIG datatype t = B of { g: A.g, nstring: A.n -> string } val mk: string list -> t end; structure B : BSIG = struct structure A = A datatype t = B of { g: A.g, nstring: A.n -> string } fun mk sl = let val g = A.newG () fun loop ([], t) = let fun nstring n = valOf (A.look (t, n)) handle e => let val _ = print "!!!! BOGUS exception... " in print (concat ["node ID is: ", A.id n, "\n"]); raise e end in B { g = g, nstring = nstring } end | loop (s :: ss, t) = let val n = A.newN g in loop (ss, A.add (t, n, s)) end in loop (sl, A.empty) end end (* -------------------------------------------------- *) (* structure C = (* scenario 1 *) *) functor C (B: BSIG) = (* scenario 2 *) struct structure A = B.A fun show (B.B { g, nstring }) = app (fn n => print (nstring n ^ "\n")) (A.nodes g) end structure C = C (B) (* scenario 2 *) (* -------------------------------------------------- *) (* run the sucker... *) val test = C.show (B.mk ["a", "b", "c"]) Transcript: - use "bug1315.sml"; [opening bug1315.sml] signature ASIG = sig type g type n type 'a t val newG : unit -> g val newN : g -> n val nodes : g -> n list val empty : 'a t val add : 'a t * n * 'a -> 'a t val look : 'a t * n -> 'a option val id : n -> string end structure A : ASIG signature BSIG = sig structure A : sig type g type n type 'a t val newG : unit -> g val newN : g -> n val nodes : g -> n list val empty : 'a t val add : 'a t * n * 'a -> 'a t val look : 'a t * n -> 'a option val id : n -> string end datatype t = B of {g:A.g, nstring:A.n -> string} val mk : string list -> t end ID of new node is: 1 ID of new node is: 2 ID of new node is: 3 !!!! BOGUS exception... node ID is: 401 uncaught exception Option raised at: boot/option.sml:17.25-17.31 b1315.sml:68.15 Comments: [Matthias, 11/24/97] If you use the line commented as "scenario 1", then everything works fine (structure C uses B directly). If you comment out that line and remove the comment brackets around those labelled "scenario 2", then you will find strange behavior. The only difference between scenario 1 and 2 is than the latter uses structure B through a functor argument. Under 109.33 on an UltraSparc, scenario 1 reports (aside from its usual chattering about defined signatures and structures): . . . ID of new node is: 1 ID of new node is: 2 ID of new node is: 3 c b a This is the expected behavior. Under scenario 2 I get: . . . ID of new node is: 1 ID of new node is: 2 ID of new node is: 3 !!!! BOGUS exception... node ID is: 433 uncaught exception Option raised at: boot/option.sml:17.25-17.31 bug.sml:63.10 Clearly, there should never be a node with ID = 433 (because only 3 nodes are created total, and they are numbered 1, 2, 3). Looks like a representation bug to me... [dbm, 11/24/97] The opaque signature constraint in the declaration of A is also necessary. Fix: - Test: bug1315.sml Owner: Zhong Status: open ---------------------------------------------------------------------- Number: 1316 Title: type checker loops on incorrect function declaration Keywords: types Submitter: Anton Schwaighofer Date: 11/26/97 Version: 109.32 System: sparc-solaris Severity: major? Problem: When you forget the brackets in the pattern fun f x::xs = x+f(xs) SML 109.32 will not bring the correct error messages, but try to allocate larger and larger amounts of memory without ever stopping. Code: fun f x::xs = x+f(xs); Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - fun f x::xs = x+f(xs); stdIn:17.8-17.10 Error: infix operator "::" used without "op" in fun dec stdIn:17.5-17.22 Error: data constructor :: used without argument in pattern GC #0.0.0.0.1.1: (10 ms) GC #0.0.0.1.2.19: (510 ms) GC #0.0.1.2.3.27: (760 ms) GC #0.1.2.3.4.45: (3090 ms) GC #1.2.3.4.5.53: (4020 ms) .... and so on GC #5.19.20.21.22.279: (19320 ms) ... GC #5.27.28.29.30.383: (1510 ms) /disk7_1/software/sml109.32/bin/sml: Error -- unable to map 69599232 bytes, errno = 11 /disk7_1/software/sml109.32/bin/sml: Error -- unable to allocate to-space for generati on 5; trying smaller size GC #6.28.29.30.31.391: ^C (26950 ms) Interrupt /disk7_1/software/sml109.32/bin/sml: Error -- unable to map 244711424 bytes, errno = 11 /disk7_1/software/sml109.32/bin/sml: Error -- unable to allocate to-space for generation 5; trying small er size GC #7.29.30.31.32.392: (430 ms) - Comments: sml 0.93 brings the correct error messages: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - fun f x::xs = x+f(xs); std_in:2.8-2.9 Error: NONfix pattern required std_in:2.5-2.21 Error: data constructor :: used without argument in pattern std_in:2.1-2.21 Error: pattern and expression in val rec dec don't agree (circularity) pattern: 'Z -> 'Z expression: 'Z -> 'Y -> 'Z -> 'Z in declaration: f = (fn arg => (fn => )) std_in:2.16 Error: overloaded variable cannot be resolved: + [dbm,12/1/97] Simpler example that doesn't involve the bad syntax is (bug1316.2.sml) fun f x z = x+f(z); Fix: In basics/unify.sml, added an occurence check when instantiating a SCHEME tyvar (in function adjustType). Test: bug1316.1.sml, bug1316.2.sml, bug1316.3.sml Owner: dbm Status: fixed in 110 [dbm, 12/2/97] ---------------------------------------------------------------------- Number: 1317 Title: Error: Compiler bug: EntityEnv: lookEP.1 Keywords: functors, modules Submitter: Elsa L. Gunter, elsa@research.bell-labs.com Date: 12/5/97 Version: 109.33 System: x86 - Linux 2.0.0 Severity: minor Problem: A compiler error is generated when the compiler tries to make a structure from a functor that couldn't be defined because it's output signature was missing. Code: functor F () : FSIG = struct end structure C = F () Transcript: Standard ML of New Jersey, Version 109.34, December 2, 1997 val use = fn : string -> unit - use "test/bugs/bug1317.sml"; [opening test/bugs/bug1317.sml] test/bugs/bug1317.sml:4.16-4.20 Error: unbound signature: FSIG Error: Compiler bug: EntityEnv: lookEP.1 Comments: Fix: when structure binding signature constraint does not elaborate (elabSig returns ERRORsig), proceed as though there was no signature constraint. Test: bug1317.sml Owner: dbm Status: fixed in 109.35 [dbm, 12/6/97] ---------------------------------------------------------------------- Number: 1318 Title: incorrect sigmatch error in higher-order functor Keywords: modules, functors, higher-order functors, signature matching Submitter: Nikolaj Bjorner Date: 12/10/97 Version: 110 System: - Severity: major Problem: Signature match error message gives wrong type names while matching a the body of a higher order functor with a result constraint. Code: (bug1318.1.sml) funsig FSIG(type info) = sig type node type info type tree val f : node -> info end; functor FUN(functor F : FSIG): sig type info type node val g : node -> info end = struct type info = int * bool structure S = F(type info = info) type node = S.node val g = S.f end; Transcript: - use "bug1318.1.sml"; [opening bug1318.1.sml] funsig FSIG(: sig type info end) : sig type node type info type tree val f : node -> info end bug1318.1.sml:11.9-22.4 Error: value type in structure doesn't match signature spec name: g spec: ?.node -> ?.info actual: ?.S.tree -> ?.S.info Expected the last line to be "actual: ?.S.node -> ?.S.info", i.e. the type of S.f. If we comment out "type tree" in the body of FSIG, we get another strange result: - use "bug1318.2.sml"; [opening bug1318.2.sml] funsig FSIG(: sig type info end) : sig type node type info val f : node -> info end bug1318.2.sml:10.9-21.4 Error: value type in structure doesn't match signature spec name: g spec: ?.node -> ?.info actual: ?.S.info -> ?.S.node In this case the actual type looks like the type of S.f with domain and range reversed. Comments: If we strengthen the spec type info in the body of FSIG to be type info = info then the functor FUN elaborates successfully. However, if we then add the "type tree" specification to the body of FSIG (as in bug1318.4.sml), the elaboration of FUN fails again as follows - use "test/bugs/bug1318.4.sml"; [opening test/bugs/bug1318.4.sml] funsig FSIG(: sig type info end) : sig type node type info = info type tree val f : node -> info end test/bugs/bug1318.4.sml:12.9-23.4 Error: value type in structure doesn't match signature spec name: g spec: ?.node -> ?.info actual: ?.S.tree -> ?.S.info [Bjorner, 12/11/97: workaround] I just got rid of the functor argument to the functor and named the two instances of TreeFUN the same. I needed it for compiling with two different environment (we are in the transition from one representation of Tree to another and want to compile both). [dbm, 12/13/97] The bug appears first in 109.32, with the introduction of the , transforms and the rewrite of modules/epcontext.sml. Fix: Test: bug1318.1.sml, bug1318.2.sml, bug1318.3.sml, bug1318.4.sml Owner: dbm Status: fixed in 110.0.1 [dbm, 12/15/97] ---------------------------------------------------------------------- Number: 1319 Title: Real.toManExp on Intel Keywords: Real.toManExp Intel Submitter: Henry Cejtin henry@research.nj.nec.com Date: 12/05/97 Version: 109.32 System: x86 Any Unix Subsystem: SML basis library Severity: minor Problem: For reals near the maximum possible, Real.toManExp returns incorrect answers. Code: Real.toManExp (7.9 * 2e307) Transcript: Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled] - Real.toManExp (7.9 * 2e307); val it = {exp=0,man=1.58e308} : {exp:int, man:real} Comments: I would prefer these to give you the IEEE exponent and mantissa. I.e., no fancy stuff for denormalized numbers. Fix: Test: bug1319.sml Owner: jhr, Andrew Status: open ---------------------------------------------------------------------- Number: 1320 Title: path name syntax used by cm when compiling to x86 Keywords: CM, win32, file path syntax Submitter: Lorenz Huelsbergen Date: 12/9/97 Version: 110 System: - Severity: minor Problem: When compiling for win32, cm places / (instead of \) in the filenames in the various text files that sit in the bin directory. Currently we use a script to patch this. (It's been applied to /usr/local/sml/110/bin.x86-win32/) Perhaps cm should emit \'s when x-compiling to win32. Comments: Fix: added new function writeFileName that does the right thing for Windows. Owner: Matthias Status: fixed in 110.0.1 [Matthias, 1/10/98] ---------------------------------------------------------------------- Number: 1321 Title: printing of datatype = datatype in signatures Keywords: pretty-printing Submitter: John Reppy jhr@research.bell-labs.com Date: 12/10/97 Version: 110 System: Any/All Any Unix Subsystem: SML compiler Severity: cosmetic Problem: The spec "datatype t = t" gets printed as "type t = t". Code: signature S = sig datatype bool = datatype bool end; Transcript: Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - signature S = sig datatype bool = datatype bool end; signature S = sig type bool = bool end Comments: Fix: Test: bug1321.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1322 Title: Functor application causes "Compiler bug: LambdaType: wrong TCs in tc_select" Keywords: modules, functors, functor application, lambda types Submitter: Andrew Kennedy Andrew.Kennedy@persimmon.co.uk Date: 12/11/97 Version: 110 System: Any/All Any Unix Subsystem: SML compiler Severity: major Problem: A fairly straightforward functor application falls over. The code worked in previous versions of the compiler. The bug occurs under both CM and "use". Code: (* bug1322.2.sml *) signature MONAD = sig type 'a T val unit : 'a -> 'a T end; structure IdMonad = struct type 'a T = 'a fun unit x = x end; functor StMonad(structure Monad : MONAD type State) = struct fun read (s: State) = Monad.unit(s,s) (* unit arg must be a pair *) end; structure StMonad = StMonad(structure Monad = IdMonad type State = int); Transcript: - use "bug1322.2.sml"; [opening bug1322.2.sml] signature MONAD = sig type 'a T val unit : 'a -> 'a T end structure IdMonad : sig type 'a T = 'a val unit : 'a -> 'a end functor StMonad : Error: Compiler bug: LambdaType: wrong TCs in tc_select Comments: [dbm,12/13/97] The failure occurred between 109.23 and 109.24, i.e. with the introduction of the Flint intermediate language and the new module elaborator. Fix: Test: bug1322.1.sml, bug1322.2.sml Owner: Zhong, dbm Status: fixed in 110.0.1 [Zhong, 1/7/98] ---------------------------------------------------------------------- Number: 1323 Title: "uncaught exception RegMap" on hppa Keywords: code generation, RegMap, GpregNum Submitter: Martin Elsman Date: 12/12/97 Version: 110 System: hppa-hpux, alpha32-dunix, sparc-solaris, mipseb-irix5 Severity: critical Problem: I'm in the process of porting the ML Kit with Regions to SML/NJ version 109.32. However, when compiling a fairly large functor (2889 lines) SML/NJ crashes with the following error message: Code: simplified test case from Andrew (* bug1323.sml *) functor F ( type code val boo : bool option option val funcs : bool list ) : sig end = struct fun reset() = () val _ = reset() val pairId = fn (a,b) => (a,b) val boolref = ref false fun h (a,b) = if !boolref then (a,b) else (a,b) fun lookup () = case boo of SOME(SOME b) => b | _ => false fun f1 C = if lookup () then pairId C else C fun f2 C = C fun f (x, C) = if x then f1 C else f2 C fun g (x::rest) = h(f(x, g rest)) val uc: unit * code = g funcs end Transcript: (Sparc SunOS 5.5.1, SML/NJ 110) % sml use "bug.sml"; Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - [opening bug.sml] bug.sml:6.1-30.4 Warning: match nonexhaustive x :: rest => ... GC #0.0.0.0.1.5: (10 ms) uncaught exception GpregNum raised at: cps/generic.sml:76.26-76.34 Comments: [dbm, 12/16/97] Could it be an MLRISC code generation bug? Fails in a similar way on alpha32-dunix: ... [wrote CM/alpha32-unix/COMP_LAMB.sml.bin] [compiling CompLamb.sml -> CM/alpha32-unix/CompLamb.sml.bin] GC #1.3.6.10.40.1323: (117 ms) GC #1.3.6.11.41.1368: (245 ms) ... LOTS of GC messages ... GC #4.50.61.81.121.3226: (125 ms) GC #4.51.62.82.122.3242: (407 ms) uncaught exception RegMap raised at: util/intmap.sml:28.41-28.44 util/stats.sml:164.40 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 But it fails on sparc-solaris as well! ... [compiling CompLamb.sml -> CM/sparc-unix/CompLamb.sml.bin] GC #1.2.3.16.35.1300: (50 ms) GC #1.2.3.17.36.1354: (70 ms) ... lots of GC messages ... GC #3.20.26.52.105.2966: (70 ms) GC #3.21.27.53.106.2999: (80 ms) uncaught exception GpregNum raised at: cps/generic.sml:76.26-76.34 util/stats.sml:164.40 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 and on mipseb-irix! [wrote CM/mipseb-unix/COMP_LAMB.sml.bin] [compiling CompLamb.sml -> CM/mipseb-unix/CompLamb.sml.bin] GC #0.0.1.4.18.553: (204 ms) GC #0.0.1.5.19.590: (353 ms) .... GC #3.9.23.37.53.1466: (187 ms) GC #3.10.24.38.54.1470: (272 ms) uncaught exception GpregNum raised at: cps/generic.sml:76.26-76.34 util/stats.sml:164.40 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 On rs6000-aix (vasa) compilation died (killed by the OS?) before an error message occurred. [Andrew, 12/18/97] I've made the test case for bug 1323 even smaller. The following fails on the sparc: functor F ( type code val ? : bool ) : sig end = struct fun reset() = () val _ = reset() val pairId = fn (a,b) => (a,b) fun f1 C = if ? andalso ? then pairId C else C fun f2 C = C fun f (a,b) = if ? then f1 (a,b) else f2 (a,b) fun g () = let val ((),b) = f((),g()) in if ? then b else b end val u : code = g () end Note: this is not directly related to the bug, but might be an opportunity for optimization: Interestingly, if f is made monomorphic then it compiles successfully. Even more interesting is that if I put "local ... in" around the function up to (but not including) f, it fails, but if f is in the local part, it succeeds. This leads me to believe that monomorphic instatiation is performed for "local" but not for top-level vals in structures, even if they are not exported through the signature of the structure. Is that true? [Andrew, 12/18/97] Here's an even smaller test case for 1323. (bug1323.2.sml) Uncomment the commented code, and the error changes from "Gpregnum" to Error: Compiler bug: Contract: UsageMap on 299 which proves that the error is at CPSopt or earlier -- I strongly suspect earlier. functor F (type code) : sig end = struct fun id x = x val () = id() fun f (a,b) = id id id (a,b) fun g () : code = let val ((),b) = f((),g()) in (* id id *) b end val u = g () end [dbm, 1/7/98] Partially fixed by Zhong's changes of 1/7/98. bug1323.1.sml and the original DIKU code now work on all architectures, bug bug1323.2.sml still fails on hppa and alpha. Fix: Test: bug1323.1.sml, bug1323.2.sml, bug1323.3.sml (bug1323.tar.Z in dist/smlnj/working/bugs) Owner: Andrew, Zhong Status: open ---------------------------------------------------------------------- Number: 1324 Title: Equality check in where type Keywords: modules, signatures, include, equality types Submitter: Martin Elsman (mael@diku.dk) Date: 12/16/1997 Version: SML/NJ 110 System: hppa-hpux Severity: major Problem: The following signature declaration should not elaborate; but it does in SML/NJ 110. In rule (64) the requirement /\'a(k).\tau admits equality, if t does is not checked properly (I presume.) Code: signature K = sig type s include sig eqtype t end where type t = s end Transcript: mael@frej> sml110 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "eq.sml"; [opening eq.sml] signature K = sig type s type t = s end val it = () : unit - Comments: In functors with many formal arguments it is important that equality attributes be propagated correctly, as the user otherwise may have difficulties using equality in functor bodies. Fix: Test: bug1324.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1325 Title: raises exception in compiler while trying to print error message Submitter: Andrew Koenig, ark@research.att.com Date: 12/15/1997 Version: 110 System: Sparc-SunOS-4.1.1 Severity: minor (unless the problem is more pervasive) Problem: I gave the compiler an expression that I did not expect to type-check, to see what diagnostic message would result. The compiler raised an internal exception while trying to print the diagnostic message. Code: val x = Posix.FileSys.openf("/etc/passwd", Posix.Filesys.O_RDONLY, 0); Transcript: Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - val x = Posix.FileSys.openf("/etc/passwd", Posix.Filesys.O_RDONLY, 0); stdIn:16.44-16.66 Error: unbound structure: Filesys in path Posix.Filesys.O_RDONLY stdIn:16.1-16.70 Error: operator and operand don't agree [literal] operator domain: string * ?.POSIX_FileSys.open_mode * ?.POSIX_FileSys.O.flags operand: string * _ * int in expression: uncaught exception nonexhaustive match failure raised at: print/ppval.sml:120.41 util/pp.sml:554.6 elaborate/elabmod.sml:1567.47 elaborate/elabmod.sml:1573.4 Comment: I expect the problem to be that the third argument to openf is expected to have type Posix.FileSys.O.flags, but I gave it an integer. How am I supposed to say that I don't want any of the flags, anyway? Fix: Test: bug1325.sml Owner: dbm Status: fixed in 110.0.1 [dbm, 12/16/97] ---------------------------------------------------------------------- Number: 1326 Title: nonexhaustive match failure in pretty printer Keywords: printing, absyn, error messages Submitter: Ed Osinski osinski@cs.nyu.edu Date: 12/16/97 Version: 110 System: Sparc SunOS 4.1.4 Subsystem: SML compiler Severity: minor Problem: Dies while reporting errors in program. Code: fun f x _ = [] | f x _ = let val y = g () in 1 end Transcript: Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "bug.sml"; [opening bug.sml] bug.sml:2.25 Error: unbound variable or constructor: g bug.sml:1.13-4.9 Error: types of rules don't agree [literal] earlier rule(s): 'Z * 'Y -> 'X list this rule: 'Z * 'Y -> int in rule: uncaught exception nonexhaustive match failure raised at: print/ppabsyn.sml:419.34 util/pp.sml:554.6 elaborate/elabmod.sml:1567.47 elaborate/elabmod.sml:1573.4 Comments: The initial error messages are correct; the problem is the "match failure". This seems to be the smallest code to demonstrate the error. Fix: Test: bug1326.sml Owner: dbm Status: fixed in 110.0.1 [dbm, 12/17/97] ---------------------------------------------------------------------- Number: 1327 Title: tycStamp secondary error Keywords: secondary error, elaboration, modules, functors Submitter: Mikolaj Konarski Date: 12/30/97 Version: 110 System: - Severity: minor Problem: An unbound structure id results in a "Compiler bug: TypesUtil: tycStamp ERRORtyc" secondary error message. Code: signature S1 = sig datatype t = U end; signature S2 = sig structure A : S1 datatype u = U of A.t end; signature S3 = sig structure B : S2 end; functor F1 (structure X : S1 structure Y : S2 where A = X) :> S3 where B = Y = struct structure B = Y end; functor F2 () = struct structure D = F1(structure X = struct datatype t = U end structure Y = Z) end; Transcript: Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "bug.sml"; [opening bug.sml] signature S1 = sig datatype t = U end signature S2 = sig structure A : sig datatype t = U end datatype u = U of A.t end signature S3 = sig structure B : sig structure A : datatype u = U of A.t end end functor F1 : bug.sml:28.20 Error: unbound structure: Z bug.sml:27.17-28.22 Error: unmatched structure specification: Y Error: Compiler bug: TypesUtil: tycStamp ERRORtyc Comments: Fix: added a check for ERRORtyc in function doElem in function mapEPC in elabmod.sml. Test: bug1327.sml Owner: dbm Status: fixed in 110.1 [dbm, 1/6/97] ---------------------------------------------------------------------- Number: 1328 Title: non-legal respecifications and redeclarations Keywords: reserved identifiers, signature specs, val decls Submitter: Martin Elsman (mael@diku.dk) Date: 12/19/1997 Version: SML/NJ 110 System: - Severity: minor Problem: Neither the signature declaration, nor the declaration should elaborate due to syntactic restriction: No datdesc, valdesc or exdesc may describe true, false, nil, :: or ref. No datdesc or exdesc may describe it. Code: signature S = sig val true : int end datatype t = it Transcript: mael@frej> sml110 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - signature S = sig val true : int end; signature S = sig val true : int end - - datatype t = it; datatype t = it - Test: bug1328.1.sml, bug1328.2.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1329 Title: Problem with realisation in where type Keywords: realisation, where type Submitter: Martin Elsman (mael@diku.dk) Date: 12/19/1997 Version: SML/NJ 110 System: - Severity: major Problem: The signature declaration below should not elaborate (I believe) but does under SML/NJ 110; the reason it should not elaborate is that when applying rule (64) then \varphi does not have the property that arity(t) = arity(\varphi(t)), hence \varphi is not a realisation. *) Code: signature S = sig datatype 'a t = A of 'a end where type 'a t = int Transcript: mael@frej> sml110 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "sig2.sml"; [opening sig2.sml] signature S = sig type 'a t = int end val it = () : unit - Comments: It is not obvious what damage such signatures could do to generation of code for functor bodies. [dbm, 1/7/98] This is not a problem of arity mismatch, since the "where" definition of t is of arity 1 like the specification of t in the signature body. We should probably check that the definition of t is a datatype (more precisely: eta-reduces to a datatype) and that this datatype is "compatible" with the spec (same arity, same constructor names, ...?). Fix: One needs to check that \varphi is indeed a realisation; this is done correctly for type sharing, that is, the following signature declaration fails to elaborate: signature S = sig type u datatype 'a t = A of 'a sharing type u = t end Test: bug1329.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1330 Title: Problem with type abbreviations in signatures Submitter: Martin Elsman (mael@diku.dk) Date: 12/19/1997 Version: SML/NJ 110 System: hppa-unix Severity: major Problem: None of the signature declarations below elaborates under SML/NJ though they should according to the Definition. I have partly reported this problem earlier but I don't think it was recognized as a bug - so here it is again.. Code: signature S = sig type t type s = t end where type s = int signature S = sig type t type s = t sharing type t = s end signature S = sig type s structure U : sig type 'a t type u = (int * real) t end where type 'a t = s end where type U.u = int Transcript: mael@frej> sml110 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "sig2.sml"; [opening sig2.sml] sig2.sml:4.1-7.23 Error: where type defn applied to definitional spec: s - mael@frej> sml110 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "sig2.sml"; [opening sig2.sml] sig2.sml:13.1-17.4 Error: dependency cycle in instantiate - mael@frej> sml110 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - use "sig2.sml"; [opening sig2.sml] sig2.sml:23.1-29.25 Error: where type defn applied to definitional spec: U.u - Fix: Treat type abbreviations as a derived form as specified in the Definition, and the problems should go away. Test: bug1330.1.sml, bug1330.2.sml, bug1330.3.sml Owner: dbm Status: not a bug ---------------------------------------------------------------------- Number: 1331 Title: eXene example code out of date Keywords: eXene, widgets, examples Submitter: Scholz, Enno scholz@inf.fu-berlin.de Date: 01/04/98 Version: 109.32 AND 110 System: Sparc Solaris Subsystem: Installation Severity: major Problem: When I run sml-cm in the directory /home/bwana/scholz/Sml/src/eXene/examples/widgets, I get the following error: simple-with-menu.sml:53.7-53.16 Error: unbound structure: CIO in path CIO.print simple-with-menu.sml:53.33-53.43 Error: unbound variable or constructor: makestring simple-with-menu.sml:58.21-58.35 Error: unbound structure: CIO in path CIO.input_line simple-with-menu.sml:58.36-58.46 Error: unbound structure: CIO in path CIO.std_in simple-with-menu.sml:36.25-36.60 Error: operator and operand don't agree [tycon mismatch] operator domain: OS.Process.status operand: unit in expression: RunCML.shutdown () !* CM error: compile: elaboration failed Code: Transcript: Comments: [dbm] Example code needs to be updated. Fix: Test: - Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1332 Title: signature mistakenly rejected Keywords: modules, signatures, where structure, sharing Submitter: Stephen Weeks Date: 1/7/98 Version: 110 System: x86-linux Severity: minor Problem: In the following, the signature BUG is rejected, with: Error: possibly inconsistent structure definitions at: B.Z Code: signature SIG = sig structure Z : sig end end signature BUG = sig structure A : sig end structure B : SIG where Z = A structure C : SIG where Z = A sharing B = C end Transcript: Comments: Fix: Test: bug1332.sml Owner: dbm Status: open (not a bug?) ---------------------------------------------------------------------- Number: 1333 Title: SML 110 CM sometimes keeps, sometimes drops top level defs Keywords: CM toplevel Submitter: Jeff Foster, jfoster@cs.berkeley.edu Date: 1/12/98 Version: 110 System: Sun Enterprise-5000 running Solaris 2.5.1 Severity: minor Problem: When compiling a project using CM, top level definitions are sometimes ignored and are sometimes compiled Code: Three files: (* sources.cm *) Group is top.sml util.sml ================ (* util.sml *) structure Util = struct fun applyOpt f zero NONE = zero | applyOpt f _ (SOME x) = f x end ================ (* top.sml *) fun parse filename = let val ind = TextIO.openIn filename val {sourceMap,tree=result} = (GenFront.parse (ind, filename) handle (Fail s) => (TextIO.closeIn ind; raise Fail s)) val _ = TextIO.closeIn ind in result end fun tc filename = let val p = parse filename in app CType.declaration p end Transcript: Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/sparc-unix/sources.cm.stable ... not usable] [parsing top.sml] top.sml:3.1-12.8: declaration not tracked by CM top.sml:14.1-18.8: declaration not tracked by CM [Creating directory CM/DEPEND ...] [parsing util.sml] [dependency analysis completed] [compiling util.sml -> CM/sparc-unix/util.sml.bin] [Creating directory CM/sparc-unix ...] [wrote CM/sparc-unix/util.sml.bin] [introducing new bindings into toplevel environment...] val it = () : unit Comments: Notice -- no error messages even though top.sml cannot possibly compile. Now if I make a simple change: (* top.sml *) structure A = TextIO <---------------- added this fun parse filename = let val ind = TextIO.openIn filename val {sourceMap,tree=result} = (GenFront.parse (ind, filename) handle (Fail s) => (TextIO.closeIn ind; raise Fail s)) val _ = TextIO.closeIn ind in result end fun tc filename = let val p = parse filename in app CType.declaration p end It does the right thing now: Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/sparc-unix/sources.cm.stable ... not usable] [parsing top.sml] top.sml:5.1-14.8: declaration not tracked by CM top.sml:16.1-20.8: declaration not tracked by CM [Creating directory CM/DEPEND ...] [parsing util.sml] [dependency analysis completed] [compiling util.sml -> CM/sparc-unix/util.sml.bin] [Creating directory CM/sparc-unix ...] [wrote CM/sparc-unix/util.sml.bin] [compiling top.sml -> CM/sparc-unix/top.sml.bin] top.sml:7.33-7.47 Error: unbound structure: GenFront in path GenFront.parse top.sml:19.6-19.23 Error: unbound structure: CType in path CType.declaration !* CM error: compile: elaboration failed Comment: So top.sml is not being compiled if it doesn't export any module level names. On the other hand, if the util.sml file is eliminated (from sources.cm), then top.sml does get compiled, and the error message about unbound structure Ctype is generated. Fix: Probably CM should print a warning or message when a file like atom.sml will not be compiled, or when a file has no module-level declarations. Test: - Owner: Matthias, dbm Status: fixed in 110.20 [Matthias] ---------------------------------------------------------------------- Number: 1334 Title: problem with type checking abstype Keywords: abstype, type checking, sharing violation Submitter: Martin Elsman (mael@diku.dk) Date: 01/14/1998 Version: 110.0.1 System: hppa-hpux Severity: major Problem: There is a problem with correctly propagation of type information through the with-part of an abstype-construct. The functor f below should propagate the type name associated with the type constructor t in the argument to the type name associated with the type constructor t in the result. Code: signature A = sig type t end functor f (structure a : A) : A = struct abstype u = B with type t = a.t end end functor k (structure a : A structure b : A sharing type b.t = a.t) : A = struct type t = b.t end functor g (structure a : A) = struct structure b = f (structure a = a) structure c = k (structure a = a structure b = b) end Transcript: mael@frej> sml-cm Standard ML of New Jersey, Version 110.0.1, January, 12, 1998 [CM; autoload enabled] - use "functors.sml"; [opening functors.sml] functors.sml:12.19-13.24 Error: type sharing violation: b.t # a.t - Comments: When I recognized the problem, I could easily lift the type declaration outside of the abstype-construct, to make the problematic module type-check. Fix: Test: bug1334.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1335 Title: nonexhaustive match failure in mips code generator Keywords: mips, code generation Submitter: Lorenz Huelsbergen (lorenz@research.bell-labs.com) Date: 1.13.98 Version: 110.0.1, 110, 109.35,... System: Mips/Irix, but not Sparc/Solaris Severity: critical Problem: CG exception Code: at MH, files in slocum:/usr/lorenz/tmp/mips-cg-bug.tar Transcript: $ uname -a IRIX slocum 5.3 11091811 IP19 mips $ /usr/local/sml/bin/sml-cm Standard ML of New Jersey, Version 110.0.1, January, 12, 1998 [CM; autoload enabled] - CM.make (); ... asm.sml:2.5-824.8 Warning: match nonexhaustive (lab as Label (_,offset),(relopt,r as ref NONE,line,section_pos), entry_opt) => ... asm.sml:47.40-49.31 Warning: match nonexhaustive (Byte,i) => ... (HalfWord,i) => ... (Word,i) => ... GC #0.0.0.1.5.125: (54 ms) GC #0.0.0.1.6.140: (44 ms) GC #0.0.0.1.7.151: (82 ms) GC #0.0.0.1.8.165: (75 ms) GC #0.0.0.2.9.187: (144 ms) GC #0.0.0.2.10.213: (20 ms) uncaught exception nonexhaustive match failure raised at: mips/mips.sml:790.39 util/stats.sml:164.40 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 Comments: seems to only affect mips Fix: [Lal, 1/15/98] The problem was that in the function 'ibranch' it is necessary to implement signed comparisons on 32-bit word values. This problem affects both the mips and rs6000. The files affected are: mips/mips.sml and rs6000/rs6000.sml. Test: bug1335.sml Owner: Lal Status: fixed in 110.0.2 [Lal, 1/14/98] ---------------------------------------------------------------------- Number: 1336 Title: Alarming "Approximating!" message Keywords: messages Submitter: Andrew Kennedy andrew@persimmon.co.uk Date: 01/13/98 Version: 109.32, 110.0.7 System: Any/All Any Unix Subsystem: SML compiler Severity: cosmetic Problem: The message "Approximating!" is displayed during compilation. I don't think that this is a bug but it's rather an alarming message (approximating what? the semantics of my program?). Code: (from Allen Stoughton, 2/1/2001) fun f x = let fun g y = let fun h _ = if x = y orelse x = y orelse x = y orelse x = y then x = y else if x = y then f(x + 1) else if x = y then g(x + 1) else if x = y then h(x + 1) else true in h 0 end in g 0 end; Transcript: (110.0.7) Approximating! 408 409 val f = fn : int -> bool Comments: [Matthias, 2/1/2000] This "bug" has recently been "fixed" (by me) -- there is no such message generated by the feedback-new.sml module which replaced feedback.sml. (The quotation marks are there to indicate that the thing was not really a bug, and that I did not really fix anything. I just cleaned up the code.) Fix: commented out diagostic message in src/sml-nj/util/feedback.sml file in 110.0.x. Also commented out in src/compiler/MiscUtil/util/feedback.sml in 110.32+, but this version seems to be using feedback-new.sml instead of feedback.sml (which should therefore be discarded/renamed). Test: bug1336.1.sml Owner: Lal Status: fixed in 110.33 and 110.0.8 ---------------------------------------------------------------------- Number: 1337 Title: exporfFn in CML produces large images Keywords: exportFn, CML Submitter: John Reppy Date: Version: 110.0.1 (but not 110.0) System: all? Severity: major Problem: Some change made to the compiler (or CM) causes the heap images exported by RunCML.exportFn to include the whole compiler. This was not a problem in 110. Furthermore, the CML code did not change between 110 and 110.0.1. Code: (SMLofNJ.Internals.CleanUp.clean SMLofNJ.Internals.CleanUp.AtExportFn; Unsafe.CInterface.c_function "SMLNJ-RunT" "exportFn" ("hi", SMLofNJ.Cont.isolate (fn ()=>()) )) Transcript: Comments: Fix: Replace an unnecessary casts in the definition of Isolate.isolate. Test: - Owner: jhr, Zhong, Andrew Status: fixed in 110.0.2 [Appel, 1/14/98] ---------------------------------------------------------------------- Number: 1338 Title: uncaught Unbound while compiling MLKit Keywords: Submitter: Martin Elsman Date: 1/14/97 Version: 110.0.1 System: ? Severity: critical Problem: uncaught Unbound exception while compiling MLKit Code: (bug1338.sml) signature SIG4 = sig structure S : sig type t structure A: sig structure B : sig val x : t end end end type s type t = s sharing type t = S.t end; functor F(X : SIG4) = struct end; Transcript: mael@frigg> sml-cm Standard ML of New Jersey, Version 110.0.1, January, 12, 1998 [CM; auto...] - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/hppa-unix/sources.cm.stable ... not usable] [scanning Common/common.cm] ... [compiling Common/Execution.sml -> Common/CM/hppa-unix/Execution.sml.bin] GC #15.348.482.876.2224.58936: (50 ms) ... GC #15.352.489.883.2251.59658: (20 ms) uncaught exception Unbound raised at: translate/transmodules.sml:80.33-80.43 translate/translate.sml:129.39 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 Comments: [dbm, 1/14/98] The code in bug1338.1.sml actually should be illegal, because the type t in the sharing constraint in SIG4 is rigid because of the definitional type spec for t. There is some controversy about this, though, since a loose interpretation of the Defn of SML 97 would treat t as flexible because the right hand side is a simple flexible type. However, that interpretation is certainly not in the spirit of the revised definition, which is to eliminate interaction between definitional type specs and type sharing specs. Fix: Test: bug1338.1.sml Owner: Zhong, dbm Status: fixed in 110.0.2 [Zhong, 1/15/98] ---------------------------------------------------------------------- Number: 1339 Title: overstrict structure consistency checking in instantiate? Keywords: modules, signatures, opaque signatures, instantiate Submitter: Mikolaj Konarski Date: 1/15/98 Version: 110.0.1 System: - Severity: minor Problem: Compiler complains about possibly inconsistent structure definitons when instantiating an opaque signature when one of the structures being defined is empty. Code: signature CAT = sig end; signature L_F = sig structure Cat : CAT end; signature TRANSLATOR = sig structure Cat : CAT structure LF : L_F where Cat = Cat end; functor Translator ( structure Cat : CAT structure LF : L_F ) :> (* with `:' here it goes through *) TRANSLATOR where Cat = Cat where LF = LF = struct structure Cat = Cat structure LF = LF end; Transcript: - use "b1.sml"; [opening b1.sml] signature CAT = sig end signature CAT = sig end signature L_F = sig structure Cat : sig end end signature TRANSLATOR = sig structure Cat : sig end structure LF : sig structure Cat : end end b1.sml:17.9-27.4 Error: possibly inconsistent structure definitions at: LF.Cat Comments: [dbm, 1/15/98] This is really a borderline case, where one can argue either way. The "abstract" result of the functor Translator is computed by instantiating the signature TRANSLATER after it is modified by the where definitions. Since the agrument structures Cat and LF are now known, the compiler cannot tell whether the specification of LF in signature TRANSLATOR, including the definition of it's substructure Cat, is satisfied. However, since in theory the structure definition clause is just an abbreviation for implied type definition clauses, and Cat has no type components, one can argue that here the where clauses defining Cat have no effect. If Cat contained a formal type spec, then there certainly would be a potential inconsistency, and the error message would be justified. Fix: Test: bug1339.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1340 Title: Segmentation fault on Sparc, x86, Alpha, and MIPS Keywords: seg fault, words, vectors Submitter: Drew Dean ddean@cs.princeton.edu Date: 01/30/98 Version: 110.0.2 System: Sparc Solaris 5.5.1 Subsystem: SML compiler Severity: critical Problem: The attached program causes a seg fault on an UltraSparc (Solaris 2.5.1) and x86 Linux (2.0 24) Code: structure segfault = struct open Word32 fun F (x, y, z) = orb(andb(x, y), andb(notb x, z)) fun <<< (x, s) = let val rs = Word31.-(0w32, s) in orb(<<(x, s), >>(x, rs)) end infix 5 <<< val sub = Vector.sub infix 8 sub fun hash (X, (a, b, c, d)) = (a + F(b, c, d) + (X sub 0)) <<< 0w3 end Transcript: caesar:~/research/phi% ~blume/Research/ML/0.2/bin/sml Standard ML of New Jersey, Version 110.0.2, January 16, 1998 [CM; autoload enabled] - use "foo2.sml"; [opening foo2.sml] GC #0.0.0.0.1.5: (0 ms) structure segfault : sig type word = ?.word32 val * : word * word -> word val + : word * word -> word val - : word * word -> word val < : word * word -> bool val << : word * Word31.word -> word val <<< : word * Word31.word -> word val <= : word * word -> bool val > : word * word -> bool val >= : word * word -> bool val >> : word * Word31.word -> word val F : word * word * word -> word val andb : word * word -> word val compare : word * word -> order val div : word * word -> word val fmt : StringCvt.radix -> word -> string val fromInt : int -> word val fromLargeInt : Int32.int -> word val fromLargeWord : word -> word val fromString : string -> word option val hash : word vector * (word * word * word * word) -> word val max : word * word -> word val min : word * word -> word val mod : word * word -> word val notb : word -> word val orb : word * word -> word val scan : StringCvt.radix -> (char,'a) StringCvt.reader -> (word,'a) StringCvt.reader val sub : 'a vector * int -> 'a val toInt : word -> int val toIntX : word -> int val toLargeInt : word -> Int32.int val toLargeIntX : word -> Int32.int val toLargeWord : word -> word val toLargeWordX : word -> word val toString : word -> string val wordSize : int val xorb : word * word -> word val ~>> : word * Word31.word -> word end val it = () : unit - segfault.hash(#[0w128, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0], (0wx67452391, 0wxefcdab89, 0wx98badcfe, 0wx10325476)); Segmentation fault Comments: Also seg faults on x86 Linux (2.0.24), Alpha (DEC OSF/1 3.2), MIPS (Irix 5.3). Does not segfault on PA-RISC (HP-UX 9.05). [From Zhong] It seems that the vector constructor #[0w0 : Word32.word is not implemented correctly in 110.0.2. In fact, just typing #[0w0 : Word32.word]; would cause the segmentation fault. Fix: new translate/wrapping.sml Test: bug1340.1.sml Owner: zsh Status: fixed in 110.0.3 [Zhong, 1/30/98] ---------------------------------------------------------------------- Number: 1341 Title: configuration script error re: GLOBALS_HAVE_UNDERSCORE Keywords: configuration Submitter: Christopher League Date: 01/17/1998 Version: 110 System: x86-linux Severity: very minor Problem: I got a link error while building the runtime on some (but not all) Linux systems. The config/install.sh script runs config/chk-global-names.sh to determine whether global names should have underscores. On my system they do NOT, but the script said they DO. Here is why. The script compiles a program containing a `main' function, then runs `nm(1)' and greps for "_main". The grep succeeds in finding the symbol `_IO_switch_to_main_get_area', because "_main' is a substring. So it mistakenly outputs -DGLOBALS_HAVE_UNDERSCORE. Code: Transcript: Comments: Fix: In config/chk-global-names.sh, I changed grep -q "_main" to grep -q -w "_main" I don't know whether it is a "standard" option, but -w causes grep to match whole words only. So it fails to match `_IO_switch_to_main_get_area' but would still match `main' if that symbol were present. Test: * Owner: jhr Status: fixed in 110.0.3 ---------------------------------------------------------------------- Number: 1342 Title: heap image size. Keywords: Submitter: Nikolaj nikolaj@cs.stanford.edu Date: 01/19/98 Version: 110.0.2 System: Sparc Solaris Subsystem: Concurrent ML Severity: critical Problem: The heap image size is now back to the days of 109.27. This used to be "fixed" to some extent in 109.32: Now: 33790344 Jan 19 14:28 step-110.sparc-solaris Then: 15123292 Dec 18 01:07 step-109.32.sparc-solaris We are using Compiler.PrettyPrint, but do not use much else that could justify the size. At least the size increase seems to be a bug introduced while fixing other bugs: 1337. exporfFn in CML produces large images as reported in PATH-2. Code: Transcript: Comments: Fix: Test: Owner: jhr Status: fixed in 110.0.3? ---------------------------------------------------------------------- Number: 1343 Title: building runtime on x86 using gcc 2.8.0 fails Keywords: Submitter: Mikael Pettersson (mikpe@sophia.inria.fr) Date: 01/20/98 Version: all System: all x86 Unixen Severity: major Problem: The problem is the pre-processing of runtime/mach-dep/X86.prim.asm that is done to evaluate and substitute symbolic constants before assembling prim.s --> prim.o. Standard Unix x86 assembly syntax requires literals to be prefixed with dollar signs. During pre-processing, it is necessary to consider constructs such as "$REQ_SIG_RETURN" as two tokens, replace REQ_SIG_RETURN by its numerical value, and finally emit "$value" without any blanks separating the "$" and the value. gcc has implemented an "-ansi" option which has had the effect of passing the "-$" option to its pre-processor, which causes it to _not_ consider "$" part of identifiers. Fine. But in gcc 2.8.0, "-ansi" no longer causes "-$" to be sent to the pre-processor, so no constant substitution occurs and the assembler complains about invalid instruction syntax. A "simple" fix would be to modify the definition of CPP in the mk.x86-* makefiles to invoke gcc with -Wp,-$ in order to force the desired behaviour. This actually has to be written '-Wp,-\$$$$' to protect it from the several layers of makefiles and shell commands. It's fragile and IMHO not The Right Thing. Below you'll find a patch for runtime/mach-dep/X86.prim.asm that should solve this problem permanently. I'm using it on my Linux box. The idea is to replace symbolic literals "$NAME" with macro calls "IMMED(NAME)". The latter evaluates NAME, then prefixes it with "$". This should work with any ANSI/ISO-C pre-processor, not just gcc. Code: Transcript: Comments: Fix: --- runtime/mach-dep/X86.prim.asm.~1~ Thu Nov 20 21:42:53 1997 +++ runtime/mach-dep/X86.prim.asm Mon Jan 19 21:29:28 1998 @@ -7,6 +7,7 @@ #include "ml-base.h" #include "asm-base.h" +#define IMMED(X) CONCAT($,X) #include "ml-values.h" #include "tags.h" #include "ml-request.h" @@ -172,7 +173,7 @@ 1:; \ jb 9f; \ lea 1b, temp; /* temp holds resume address */ \ - movl $maskval, mask; \ + movl IMMED(maskval), mask; \ jmp via CSYM(saveregs); \ 9: @@ -182,8 +183,8 @@ ML_CODE_HDR(sigh_return_a) movl mlstate_ptr, temp - movl $REQ_SIG_RETURN, request_w - movl $RET_MASK, mask + movl IMMED(REQ_SIG_RETURN), request_w + movl IMMED(RET_MASK), mask jmp CSYM(set_request) /* sigh_resume: @@ -193,10 +194,10 @@ ENTRY(sigh_resume) movl mlstate_ptr, temp - movl $REQ_SIG_RESUME, request_w -/* movl $RET_MASK, mask + movl IMMED(REQ_SIG_RESUME), request_w +/* movl IMMED(RET_MASK), mask */ - movl $FUN_MASK, mask + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) /* pollh_return_a: @@ -204,8 +205,8 @@ */ ML_CODE_HDR(pollh_return_a) movl mlstate_ptr, temp - movl $REQ_POLL_RETURN, request_w - movl $RET_MASK, mask + movl IMMED(REQ_POLL_RETURN), request_w + movl IMMED(RET_MASK), mask jmp CSYM(set_request) /* pollh_resume: @@ -213,22 +214,22 @@ */ ENTRY(pollh_resume) movl mlstate_ptr, temp - movl $REQ_POLL_RESUME, request_w -/* movl $RET_MASK, mask + movl IMMED(REQ_POLL_RESUME), request_w +/* movl IMMED(RET_MASK), mask */ - movl $FUN_MASK, mask + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) ML_CODE_HDR(handle_a) movl mlstate_ptr, temp - movl $REQ_EXN, request_w - movl $EXN_MASK, mask + movl IMMED(REQ_EXN), request_w + movl IMMED(EXN_MASK), mask jmp CSYM(set_request) ML_CODE_HDR(return_a) movl mlstate_ptr, temp - movl $REQ_RETURN, request_w - movl $RET_MASK, mask + movl IMMED(REQ_RETURN), request_w + movl IMMED(RET_MASK), mask jmp CSYM(set_request) /* Request a fault. The floating point coprocessor must be reset @@ -240,8 +241,8 @@ ENTRY(request_fault) call CSYM(FPEEnable) /* Doesn't trash any general regs. */ movl mlstate_ptr, temp - movl $REQ_FAULT, request_w - movl $EXN_MASK, mask + movl IMMED(REQ_FAULT), request_w + movl IMMED(EXN_MASK), mask jmp CSYM(set_request) /* bind_cfun : (string * string) -> c_function @@ -249,22 +250,22 @@ ML_CODE_HDR(bind_cfun_a) CHECKLIMIT(FUN_MASK) movl mlstate_ptr, temp - movl $REQ_BIND_CFUN, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_BIND_CFUN), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) ML_CODE_HDR(build_literals_a) CHECKLIMIT(FUN_MASK) movl mlstate_ptr, temp - movl $REQ_BUILD_LITERALS, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_BUILD_LITERALS), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) ML_CODE_HDR(callc_a) CHECKLIMIT(FUN_MASK) movl mlstate_ptr, temp - movl $REQ_CALLC, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_CALLC), request_w + movl IMMED(FUN_MASK), mask /* fall into set_request */ ENTRY(set_request) @@ -330,7 +331,7 @@ movl request_w,creturn /* Pop the stack frame and return to run_ml(). */ - addl $ML_FRAME_SIZE, %esp + addl IMMED(ML_FRAME_SIZE), %esp CALLEE_RESTORE ret @@ -364,7 +365,7 @@ jmp do_gc /* and handle event in the C runtime */ reset_limit: /* reset limit ptr */ - shll $POLL_GRAIN_BITS,pfreq /* mult by POLL_GRAIN_CPSI */ + shll IMMED(POLL_GRAIN_BITS),pfreq /* mult by POLL_GRAIN_CPSI */ movl allocptr,limitptr addl pfreq,limitptr #undef pfreq @@ -453,8 +454,8 @@ #undef temp2 /* Pop the stack frame and return to run_ml(). */ - movl $REQ_GC,creturn - addl $ML_FRAME_SIZE, %esp + movl IMMED(REQ_GC),creturn + addl IMMED(ML_FRAME_SIZE), %esp CALLEE_RESTORE ret @@ -464,7 +465,7 @@ #define temp2 %ebx /* Allocate and initialize the ML stack frame. */ - subl $ML_FRAME_SIZE, %esp + subl IMMED(ML_FRAME_SIZE), %esp MOVE( tempmem_w, temp2, tempmem) MOVE( tempmem2_w, temp2, tempmem2) MOVE( ExnPtrOffMSP(temp), temp2, exncont) @@ -558,15 +559,15 @@ CHECKLIMIT(FUN_MASK) movl 0(stdarg),temp /* desired length into temp */ sarl $1,temp /* untagged */ - cmpl $SMALL_OBJ_SZW,temp + cmpl IMMED(SMALL_OBJ_SZW),temp jge 3f #define tmpreg misc1 pushl tmpreg movl temp,tmpreg /* build descriptor in tmpreg */ - sall $TAG_SHIFTW,tmpreg - orl $MAKE_TAG(DTAG_array),tmpreg + sall IMMED(TAG_SHIFTW),tmpreg + orl IMMED(MAKE_TAG(DTAG_array)),tmpreg movl tmpreg,0(allocptr) /* write descriptor */ addl $4,allocptr movl 4(stdarg),tmpreg /* initial values */ @@ -585,8 +586,8 @@ CONTINUE 3: movl mlstate_ptr, temp - movl $REQ_ALLOC_ARRAY, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_ALLOC_ARRAY), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) @@ -596,7 +597,7 @@ movl stdarg,temp /* desired length into temp */ sarl $1,temp /* untagged */ shll $1,temp /* size in words */ - cmpl $SMALL_OBJ_SZW,temp + cmpl IMMED(SMALL_OBJ_SZW),temp jge 2f #define tmpreg misc1 @@ -604,8 +605,8 @@ shrl $1,temp /* size in reals */ movl temp,tmpreg /* build descriptor in tmpreg */ - sall $TAG_SHIFTW,tmpreg - orl $MAKE_TAG(DTAG_realdarray),tmpreg + sall IMMED(TAG_SHIFTW),tmpreg + orl IMMED(MAKE_TAG(DTAG_realdarray)),tmpreg movl tmpreg,0(allocptr) /* write descriptor */ addl $4,allocptr movl allocptr,stdarg /* stdarg gets ptr to new array */ @@ -617,8 +618,8 @@ CONTINUE 2: movl mlstate_ptr, temp - movl $REQ_ALLOC_REALDARRAY, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_ALLOC_REALDARRAY), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) @@ -629,7 +630,7 @@ sarl $1,temp /* untagged */ addl $3,temp /* round */ sarl $2,temp /* to words */ - cmpl $SMALL_OBJ_SZW,temp + cmpl IMMED(SMALL_OBJ_SZW),temp jge 2f #define tmpreg misc1 @@ -637,8 +638,8 @@ movl stdarg,tmpreg /* build descriptor in tmpreg */ sarl $1,tmpreg - sall $TAG_SHIFTW,tmpreg - orl $MAKE_TAG(DTAG_bytearray),tmpreg + sall IMMED(TAG_SHIFTW),tmpreg + orl IMMED(MAKE_TAG(DTAG_bytearray)),tmpreg movl tmpreg,0(allocptr) /* write descriptor */ addl $4,allocptr movl allocptr,stdarg /* stdarg gets ptr to new str */ @@ -651,8 +652,8 @@ CONTINUE 2: movl mlstate_ptr, temp - movl $REQ_ALLOC_BYTEARRAY, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_ALLOC_BYTEARRAY), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) @@ -663,7 +664,7 @@ sarl $1,temp /* untagged */ addl $4,temp /* round */ sarl $2,temp /* to words */ - cmpl $SMALL_OBJ_SZW,temp + cmpl IMMED(SMALL_OBJ_SZW),temp jge 2f #define tmpreg misc1 @@ -671,8 +672,8 @@ movl stdarg,tmpreg /* build descriptor in tmpreg */ sarl $1,tmpreg - sall $TAG_SHIFTW,tmpreg - orl $MAKE_TAG(DTAG_string),tmpreg + sall IMMED(TAG_SHIFTW),tmpreg + orl IMMED(MAKE_TAG(DTAG_string)),tmpreg movl tmpreg,0(allocptr) /* write descriptor */ addl $4,allocptr movl allocptr,stdarg /* stdarg gets ptr to new str */ @@ -686,8 +687,8 @@ CONTINUE 2: movl mlstate_ptr, temp - movl $REQ_ALLOC_STRING, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_ALLOC_STRING), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) /* create_v_a : int * 'a list -> 'a vector @@ -698,15 +699,15 @@ CHECKLIMIT(FUN_MASK) movl 0(stdarg),temp /* desired length into temp */ sarl $1,temp /* untagged */ - cmpl $SMALL_OBJ_SZW,temp + cmpl IMMED(SMALL_OBJ_SZW),temp jge 3f #define tmpreg misc1 pushl tmpreg movl temp,tmpreg /* build descriptor in tmpreg */ - sall $TAG_SHIFTW,tmpreg - orl $MAKE_TAG(DTAG_vector),tmpreg + sall IMMED(TAG_SHIFTW),tmpreg + orl IMMED(MAKE_TAG(DTAG_vector)),tmpreg movl tmpreg,0(allocptr) /* write descriptor */ addl $4,allocptr movl 4(stdarg),tmpreg /* list of initial values */ @@ -715,7 +716,7 @@ movl 0(tmpreg),temp /* temp <- hd(tmpreg) */ stosl /* 0(allocptr++) <- temp */ movl 4(tmpreg),tmpreg /* tmpreg <- tl(tmpreg) */ - cmpl $ML_nil,tmpreg /* end of list */ + cmpl IMMED(ML_nil),tmpreg /* end of list */ jne 2b popl tmpreg @@ -724,8 +725,8 @@ CONTINUE 3: movl mlstate_ptr, temp - movl $REQ_ALLOC_VECTOR, request_w - movl $FUN_MASK, mask + movl IMMED(REQ_ALLOC_VECTOR), request_w + movl IMMED(FUN_MASK), mask jmp CSYM(set_request) /* try_lock: spin_lock -> bool. @@ -889,7 +890,7 @@ fldl (temp) /* Load it into temp. */ fscale /* Multiply exponent by scalar. */ - movl $DESC_reald, (allocptr) + movl IMMED(DESC_reald), (allocptr) fstpl 4(allocptr) /* Store resulting Test: Owner: jhr, Lal Status: fixed in 110.0.3 ---------------------------------------------------------------------- Number: 1344 Title: Unimplemented real conversions Keywords: reals Submitter: Emden R. Gansner erg@research.att.com Date: 01/20/98 Version: 110.0.2 System: Any/All Any Unix Subsystem: SML compiler Severity: minor Problem: Real.toLargeInt and Real.toInt only partially implemented. Code: For example, Real.toLargeInt IEEEReal.TO_NEGINF 1073741824.0; Transcript: - Real.toLargeInt IEEEReal.TO_NEGINF 1073741824.0; uncaught exception overflow raised at: boot/real64.sml:90.16-90.32 - Comments: Fix: Test: bug1344.sml Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1345 Title: Char.toString(#"\n") error Keywords: Submitter: Joe Turner turner@cs.clemson.edu Date: 01/21/98 Version: 1.10 (?) (latest) System: Any/All Any Unix Subsystem: SML basis library Severity: major Problem: The result of Char.toString(#"\n") is "\\n" (string of two characters: #"\\" and #"n". I categorized this as minor, but it is fairly major. It seems to require an ugly kluge to work around when reading from a text file. Another problem is that file output on Dos platforms (Win95 at least) outputs "\n" as a single character. Perhaps this is intended, but it is inconsistent with print("\n") on the same system. Code: Char.toString(#"\n"); Transcript: - Char.toString(#"\n"); val it = "\\n" : string Comments: [jhr, 1/23/97] I think that you must be confusing the semantics of Char.toString and String.str. The toString functions are supposed to produce printable results; String.str converts a character to a one character string. Fix: Test: Owner: jhr Status: not a bug ---------------------------------------------------------------------- Number: 1346 Title: Compiler bug: ModuleUtil: getStr: bad entity Keywords: modules, secondary error Submitter: Norman Ramsey Date: 1/25/98 Version: 110.0.2 System: - Severity: minor Problem: I got the following compiler error when I passed the wrong thing to a functor. Code: ? Transcript: [compiling NW/link1.sml (via: link1.sml@link.nw) -> NW/CM/x86-unix/link1.sml.bin] link.nw:7.46-7.74 Error: unmatched structure specification: Patterns link.nw:7.46-7.74 Error: unmatched structure specification: Constructor Error: Compiler bug: ModuleUtil: getStr: bad entity uncaught exception Error raised at: util/errormsg.sml:54.14-54.19 modules/sigmatch.sml:726.45 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:882.25 modules/sigmatch.sml:726.45 modules/sigmatch.sml:882.25 modules/sigmatch.sml:726.45 modules/sigmatch.sml:726.45 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:839.39 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:674.29 modules/sigmatch.sml:872.22 modules/sigmatch.sml:872.22 modules/sigmatch.sml:674.29 modules/sigmatch.sml:882.25 modules/sigmatch.sml:726.45 modules/sigmatch.sml:882.25 modules/sigmatch.sml:964.24 elaborate/elabmod.sml:1223.8 elaborate/elabmod.sml:1223.8 elaborate/elabmod.sml:1458.7 elaborate/elabmod.sml:1223.8 elaborate/elabmod.sml:1328.33 util/stats.sml:164.40 sched/recompile.sml:206.38-206.41 Comments: Fix: Test: Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1347 Title: Copying part of a recusive datatype gives constructors wrong types Keywords: modules, datatypes Submitter: Perry Cheng (pscheng@cs.cmu.edu) Date: 1/30/98 Version: 109.32 System: Alpha - DUX4.0 Severity: Major Problem: When one part of a recursive datatype is copied, the types of the constructors that are copied do not refer back to the original recursive datatype. Code: signature INNER = sig datatype a = A and b = B of a end; signature OUTER = sig structure Inner : INNER datatype b = datatype Inner.b end; functor Test(structure Inner : INNER structure Outer : OUTER sharing Outer.Inner = Inner) = struct (* Both functions should typecheck but the second one does not. *) fun good (Inner.B(Inner.A)) = 5 fun bad (Outer.B(Inner.A)) = 5 end; Transcript: - use "bad.sml"; [opening bad.sml] bad.sml:23.5-23.36 Error: constructor and argument don't agree in pattern [tycon mismatch] constructor: ?.a -> Inner.b argument: Inner.a in pattern: B A Comments: Notice that the datatype above is not really recursive. if the datatype in INNER were not declared recursively, the problem goes away. Of course, this doesn't help when the datatype really is recursive. Fix: Test: bug1347.1.sml Owner: dbm Status: fixed in 110.0.2 ---------------------------------------------------------------------- Number: 1348 Title: "Out of environment space" on Windows Keywords: Windows Submitter: Mitchell Wand Date: 2/2/98 Version: 110 System: Windows Severity: major Problem: I had written: > I downloaded SMLNJ 110 right out of the box, but when I go to start it I get > a DOS window that says: > > Out of environment space > Bad command or file name Analysis: on my system, at least, SMLNJ starts in a DOS window with the initial environment size set on "Auto". Hence, when the script assigns an environment variable SMLNJ_HOME, the shell immediately runs out of environment space (hence the "Out of environment space" message). Therefore the variable %SMLNJ_HOME% gets interpreted as the empty string, and so it tries to execute "bin\.run\whatver", which of course doesn't exist (hence the "bad command or file name" message) Code: Transcript: Comments: Fix: 1. Open up a file browser to look at c:\Windows\Start Menu\Program Files\Standard ML of New Jersey\ . 2. Select "Standard ML of New Jersey" and select File|Properties to open up the property sheet for the shortcut. 3. On the Memory tab, change the "Initial Environment" setting from "auto" to 1024. Suggestion: It would seem that the install scripts ought to be able to do this automatically. Test: Owner: Riccardo Status: open ---------------------------------------------------------------------- Number: 1349 Title: segmentation faults on Linux Keywords: Submitter: Roland Olsson Date: 2/5/98 Version: 109.xx System: x86/Linux Severity: major Problem: I have used versions 109.xx for varying xx during the last year and a half under LINUX 2.0.yy on a PentiumPro CPU. The entire time, there has been a very low frequency bug that causes segmentation faults. The frequency of crashes is about once per two weeks of CPU time, which is seldom enough to make the bug rather acceptable. The bug doesn't seem to be related to VM growth as suggested by John Reppy to me more than one year ago. I have now used gdb on run.x86-linux to try to track the problem and have a live gdb session going right now with the following output so far: Program received signal SIGSEGV, Segmentation fault. 0x44c71072 in ?? () (gdb) bt #0 0x44c71072 in ?? () #1 0x40121f44 in ?? () #2 0x42d70368 in ?? () #3 0xff2424 Cannot access memory at address 0x44c71072 Can you please suggest some course of action that would enable the bug to be traced? How likely is is that the bug does not exist in 110.zz? Code: Transcript: Comments: Fix: Test: Owner: Lal, jhr Status: open ---------------------------------------------------------------------- Number: 1350 Title: X86.prim.asm has a typo Keywords: runtime, assembly Submitter: Mikael Pettersson (mikpe@sophia.inria.fr) Date: 02/05/98 Version: 110.0.3 System: all x86 Severity: minor Problem: One occurrence of MAKE_TAG in runtime/mach-dep/X86.prim.asm wasn't rewritten correctly to use the IMMED macro. The assembler won't complain; instead it will record "MAKE_TAG" as an external symbol in the object file. When the runtime system is linked, the linker notices that "MAKE_TAG" doesn't exist and quits with an error. Code: Transcript: Comments: Fix: --- runtime/mach-dep/X86.prim.asm.~1~ Fri Jan 23 20:17:03 1998 +++ runtime/mach-dep/X86.prim.asm Wed Feb 4 21:14:34 1998 @@ -605,7 +605,7 @@ shrl IMMED(1),temp /* size in reals */ movl temp,tmpreg /* build descriptor in tmpreg */ sall IMMED(TAG_SHIFTW),tmpreg - orl IMMED(MAKE_TAG)(DTAG_realdarray),tmpreg + orl IMMED(MAKE_TAG(DTAG_realdarray)),tmpreg movl tmpreg,0(allocptr) /* write descriptor */ addl IMMED(4),allocptr movl allocptr,stdarg /* stdarg gets ptr to new array */ Test: Owner: jhr Status: fixed in 110.0.3 [jhr, 2/5/98] ---------------------------------------------------------------------- Number: 1351 Title: Datatype replication within abstypes Keywords: abstypes, datatype replication Submitter: Stephen Gilmore, stg@dcs.ed.ac.uk Date: 2/11/1998 Version: 110 System: sparc-solaris2.5 Severity: minor Problem: Abstypes cannot be replicated in their bodies. Code: abstype A = B with datatype A = datatype A end; Transcript: - abstype A = B with datatype A = datatype A end; uncaught exception nonexhaustive match failure raised at: print/ppdec.sml:158.6 util/pp.sml:554.6 Comments: The Definition of SML allows this. The constructor should be exported but not the equality on the absytype. Fix: Test: bug1351.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1352 Title: Equality status of reals is compromised Keywords: Equality, overloading, reals Submitter: Andrew Kennedy Date: 02/13/98 Version: 110.0.3 System: Any/All Any Unix Subsystem: SML compiler Severity: minor Problem: One can obtain equality on reals by forcing a type to admit both division and equality. Code: fun f (x,y) = (x=y, x/y) Transcript: - fun f (x,y) = (x=y,x/y); val f = fn : real * real -> bool * real - f (2.0, 2.0); val it = (true,1.0) : bool * real - f (2.0, 4.0); val it = (false,0.5) : bool * real Comments: Fix: The softInst function in softUnify in overload.sml has to check for the consistency of equality properties. Test: bug1352.sml Owner: dbm Status: fixed in 110.9, 110.0.4 ---------------------------------------------------------------------- Number: 1353 Title: unnecessary(?) recompilation of grm.sml and lex.sml files using sml as a batch compiler Keywords: CM,ML-Lex,ML-Yacc Submitter: Gergely Buday Date: 16.2.1998. Version: 110.0.3 System: x86-linux Severity: minor Problem: I modify only the top-level code of my parser, but it does recompile grm.sml and lex.sml files. It does this only if I use my script that reinvoke sml and CM.make(). From an interactive session the problem does not raise. I do not supply my code since it does not depend on the code - at least I suppose. Code: *********** sources.cm *********** Group is ml-yacc-lib.cm tool.grm tool.lex doctool.sml *********** my stupid script *********** run sml <doctool chmod +x doctool *************** Transcript: a lot of GC messages Comments: Maybe it's not a bug - it's a feature :-) [Matthias, 3/5/97] I was unable to reproduce bug 1353, so I checked back with Gergely Buday (who reported this problem). He suggested that something was wrong with his script, so the bottom line is that probably there is no bug. Fix: Test: - Owner: Matthias Status: not a bug ---------------------------------------------------------------------- Number: 1354 Title: spurious "possibly inconsistent structure definitions" Keywords: modules, signatures, structure definition specs Submitter: Ed Osinski Date: 2/10/98 Version: 110.0.3 System: - Severity: major Problem: "possibly inconsistent structure definitions" occurs Code: Transcript: - use "tests/bug1354.1.sml"; [opening tests/bug1354.1.sml] tests/bug1354.1.sml:33.1-39.4 Error: possibly inconsistent structure definitions at: UC.Type.Ir Comments: [dbm, 8/13/98] The error message was generated in the buildStrClass/constrain function, which detects a secondary definition after a class already has a definition (classDef is SOME _). It appears to be safe to adopt a lenient policy of just ignoring secondary definitions (while generating a warning message). This may allow more bogus signatures to be instantiated, but they will not be matchable. Fix: In instantiate.sml, have constrain function (in buildStrClass) ignore secondary definitions on structure (and type) elements, and generate a warning about multiple defs. Test: bug1354.1.sml, bug1354.2.sml, bug1354.3.sml Owner: dbm Status: fixed in 110.0.4 and 110.9 ---------------------------------------------------------------------- Number: 1355 Title: exportFn image size increase on alpha32x-osf1 Keywords: Submitter: Mikael Pettersson, mikpe@sophia.inria.fr Date: 02/18/98 Version: 110.2 System: alpha32x-osf1 Severity: major Problem: sudden increase in size of exportFn images on alpha32x-osf1 Code: Transcript: Comparing vanilla builds of 110.0.3 and 110.2: bahia_1_ls -l 110.{0.3,2}/bin/heap/*.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 640528 Feb 4 14:57 110.0.3/bin/.heap/ml-burg.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 455240 Feb 4 14:52 110.0.3/bin/.heap/ml-lex.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 761000 Feb 4 14:52 110.0.3/bin/.heap/ml-yacc.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 7925928 Feb 4 14:57 110.0.3/bin/.heap/sml-cm.alpha32x-osf1 lrwxrwxrwx 1 mikpe croap2 20 Feb 4 14:50 110.0.3/bin/.heap/sml.alpha32x-osf1@ -> sml-cm.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 859664 Feb 18 15:17 110.2/bin/.heap/ml-burg.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 604744 Feb 18 15:11 110.2/bin/.heap/ml-lex.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 1033384 Feb 18 15:11 110.2/bin/.heap/ml-yacc.alpha32x-osf1 -rw-r--r-- 1 mikpe croap2 10404828 Feb 18 15:17 110.2/bin/.heap/sml-cm.alpha32x-osf1 lrwxrwxrwx 1 mikpe croap2 20 Feb 18 15:02 110.2/bin/.heap/sml.alpha32x-osf1@ -> sml-cm.alpha32x-osf1 Comments: On two other systems I've tested, sparc-solaris2 and x86-linux, the heap images have not increased at all (well, by less than 1%). Here we're suddenly seeing a 31%-36% size increase. (The SML code I'm working on now grew by 37% from 1208K to 1648K.) Since SPARC and x86 aren't affected, I supect something Alpha-specific in the code generator. The recent MLRISC changes perhaps? [Lal, 2/18/98] There is a major problem with the register allocator. The problem will also exist on the hppa. Correct code is currently generated by 110.2, except that it is very bad code. Fix: found Test: Owner: Lal, jhr, Zhong? Status: open ---------------------------------------------------------------------- Number: 1356 Title: Inflexibility in installation and CM Keywords: installation CM Submitter: Emden R. Gansner erg@research.att.com Date: 02/20/98 Version: 110 System: Any/All Any Unix Subsystem: Installation Severity: minor Problem: The script config/install.sh assumes the system is built where it is going to be installed, and that once installed, the tree will never be moved. In certain environments, neither of these is true. Minimally, I'd like to be able to build the system in some directory with a given installation directory in mind. I could almost handle this with changes to install.sh, fixing the script to build the system, then change the absolute path names in the bin and lib directories. In addition, CM could be built with the installation path, but used to construct the system by setting CM_PATH in the script. Alas, the path of ml-yacc (for burg) is built into CM and cannot be overridden. (A CM_TOOL or CM_YACC environment variable would be nice.) So, we build CM twice, once to build the system, once for its final installation. Everything then works fine, up until the final clause when autoloading is enabled. I'd like to build in the appropriate installed library paths, but CM wants to analyze the .cm files now and they haven't been installed yet. Here's where another indirection would be useful. [Blume, 5/5/98] When CM invokes one of the standard tools (Yacc, Lex, Burg, ...) it will now always first consult the corresponding environment variable (CM_YACC, CM_LEX, ...). In effect, the tool locations are no longer hard-wired into CM (although defaults for these locations still do exist). This partially fixes bug #1356. The remaining part of this bug has to do with autoloading. To fix it would require a major reorganization of all of CM. I believe that autoloading as a feature is of rather limited utility so that such a big change is hard to justify. If the installation of SML/NJ is to be moved to a different location in the file system, then I would recommend building it with autoloading disabled. A separate script could be provided for selectively enabling autoload *after* the move. Code: Transcript: Comments: Fix: Test: Owner: Matthias Status: fixed in 110.6 (partially: see Blume's comment) ---------------------------------------------------------------------- Number: 1357 Title: rebinding of constructors and exceptions not allowed Keywords: rebinding, constructors, SML97 Submitter: Konrad Slind Date: 2/20/97 Version: 110.0.3 System: - Severity: minor Problem: Quoting from the rule (26) on page 24 of the revised Definition: ... Also note that C + VE may overwrite identifier status. For example, the program datatype t = f; val rec f = fn x => x is legal. Unfortunately, neither MoscowML or SML/NJ 110 allow this. Code: datatype t = f; val rec f = fn x => x Transcript: - datatype t = f; val rec f = fn x => x; datatype t = f stdIn:16.25-16.38 Error: rebinding data constructor "f" as variable Comments: There's a user-level workaround: - define a datatype with the problem constructor in a structure S; - give the datatype an abstract type in the signature of S - open S After this, the constructor has lost its constructor status and can be redeclared. The following works in SML/NJ 110. datatype t = f; local structure S :sig type mask val f: mask end = struct datatype mask = f end in open S end; val rec f = fn x => x; Fix: delete calls of checkBoundConstructor in elabVALREC(strict) and elabFUNdec in elabcore.sml Test: bug1357.sml Owner: dbm Status: fixed in 110.0.4 and 110.9 [dbm, 8/14/98] ---------------------------------------------------------------------- Number: 1358 Title: bad error message line numbers in interactive system Keywords: error message, line numbers, source Submitter: Dave MacQueen Date: 2/24/98 Version: 110.2 System: - Severity: major Problem: The line numbers produced for error messages in the interactive system are incorrect. Transcript: Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled] - val nil x = []; stdIn:16.5-16.15 Error: constant constructor applied to argument in pattern:nil - val nil x = []; stdIn:1.5-2.10 Error: constant constructor applied to argument in pattern:nil Comments: Fix: Test: Owner: dbm, Andrew Status: open ---------------------------------------------------------------------- Number: 1359 Title: unexpected diagnostic message Keywords: messages, equality Submitter: Allen Stoughton Date: 2/24/98 Version: 110.0.3 System: - Severity: minor Problem: It's not that it produces an incorrect result, it's just that it issues the unexpected message int-equality used for ptr-equality Transcript: > Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled] > - let fun g(n, f) = if f = f then (n, true) else f > = in g(0, (0, true)) end; > int-equality used for ptr-equality > val it = (0,true) : int * bool Comments: A harmless diagnostic message that should have been deleted. Fix: Test: bug1359.sml Owner: Zhong Status: fixed in 110.0.6 and 110.7 ---------------------------------------------------------------------- Number: 1360 Title: uncaught exception FPRegEA Keywords: fwrap Submitter: Edoardo S. Biagioni esb@maru.ics.hawaii.edu Date: 02/25/98 Version: 110.2 System: Any/All Any Unix Subsystem: SML compiler Severity: major Problem: Code: signature EXTERN = sig type T end signature PRINTABLE = sig type T end signature KEY = sig include PRINTABLE end signature EXTERN_KEY = sig include EXTERN end signature EXTERNAL = sig include PRINTABLE end signature PROTOCOL = sig structure Address: KEY structure Pattern: KEY structure Connection_Key: KEY structure Outgoing: EXTERNAL type connection_extension type listen_extension type session_extension datatype connection = C of {send: unit -> unit, abort: unit -> unit, extension: connection_extension} datatype listen = L of {stop: unit -> unit, extension: listen_extension} datatype handler = H of Connection_Key.T -> {connection_handler: connection -> unit, data_handler: connection * unit -> unit, status_handler: connection * unit -> unit} datatype session = S of {connect: Address.T * handler -> unit, listen: Pattern.T * handler * unit -> listen, extension: session_extension} val session: (session -> 'a) -> 'a end ; functor Connection (structure Address: KEY structure Pattern: KEY structure Connection_Key: KEY structure Outgoing: EXTERNAL type connection_extension type listen_extension type session_extension type connection_state type protocol_state): PROTOCOL = struct structure Address = Address structure Pattern = Pattern structure Connection_Key = Connection_Key structure Outgoing = Outgoing type connection_extension = connection_extension type listen_extension = listen_extension type session_extension = session_extension datatype connection = C of {send: unit -> unit, abort: unit -> unit, extension: connection_extension} datatype listen = L of {stop: unit -> unit, extension: listen_extension} datatype handler = H of Connection_Key.T -> {connection_handler: connection -> unit, data_handler: connection * unit -> unit, status_handler: connection * unit -> unit} datatype session = S of {connect: Address.T * handler -> unit, listen: Pattern.T * handler * unit -> listen, extension: session_extension} exception Y fun session _ = raise Y end; functor Tcp (structure Lower: PROTOCOL): PROTOCOL= struct structure Tcp_Connection = struct structure Tcp_Key = struct type T = unit end structure Tcp_Address = struct type T = unit end structure Tcp_Pattern = struct type T = unit end structure Tcp_Host_Id = struct type T = unit end type host_id = unit type port = unit structure Outgoing = Lower.Outgoing type outgoing = Outgoing.T datatype tcp_connection_extension = Tcp_Connection_Extension of {urgent_send: Outgoing.T -> unit} type session_extension = unit type protocol_state = unit type connection_state = protocol_state datatype transport_listen_extension = Listen_Extension of {local_port: port, additional: unit} type listen_extension = transport_listen_extension type connection_internals_record = {tcp_send: (unit -> unit) ref, tcp_abort: (unit -> unit) ref, urgent_send: (Outgoing.T -> unit) ref} datatype connection_internals = Connection_Internals of connection_internals_record type connection_extension = (tcp_connection_extension * connection_internals) ref structure Conn = Connection (structure Address = Tcp_Address structure Pattern = Tcp_Pattern structure Connection_Key = Tcp_Key structure Outgoing = Outgoing type connection_extension = connection_extension type listen_extension = listen_extension type session_extension = session_extension type connection_state = connection_state type protocol_state = protocol_state) end local structure Conn: sig structure Address: KEY structure Pattern: KEY structure Connection_Key: KEY structure Outgoing: EXTERNAL type listen_extension type session_extension datatype listen = L of {stop: unit -> unit, extension: listen_extension} end = Tcp_Connection.Conn in open Conn end structure Conn = Tcp_Connection.Conn structure Transport_Address = Tcp_Connection.Tcp_Address structure Transport_Pattern = Tcp_Connection.Tcp_Pattern structure Transport_Key = Tcp_Connection.Tcp_Key structure Host_Id = Tcp_Connection.Tcp_Host_Id type host_id = Tcp_Connection.host_id type port = Tcp_Connection.port local structure Export_Listen_Extension: sig datatype transport_listen_extension = Listen_Extension of {local_port: port, additional: unit} end = Tcp_Connection in open Export_Listen_Extension end type additional_listen_extension = unit local structure Internals: sig datatype connection_internals = Connection_Internals of Tcp_Connection.connection_internals_record datatype tcp_connection_extension = Tcp_Connection_Extension of {urgent_send: Outgoing.T -> unit} end = Tcp_Connection in open Internals end type connection_extension = tcp_connection_extension datatype connection = C of {send: unit -> unit, abort: unit -> unit, extension: connection_extension} datatype handler = H of Connection_Key.T -> {connection_handler: connection -> unit, data_handler: connection * unit -> unit, status_handler: connection * unit -> unit} datatype session = S of {connect: Address.T * handler -> unit, listen: Pattern.T * handler * unit -> listen, extension: session_extension} exception Y exception Bad_Get_Tcb fun get_tcb _ = raise Bad_Get_Tcb fun add_to_window _ = raise Y fun start_user_timer _ = raise Y fun stop_user_timer _ = raise Y local fun match_ack actual registered = false val x = ref (SOME ()) fun signal_send (send, ack) = case ! send of NONE => () | _ => signal_send (send, ack) in fun execute_actions (connection as Connection_Internals internals) = let fun loop () = (signal_send (x, true); loop ()) in loop () end end fun tcp_send_packet (internals, packet, urgent) = raise Y fun close_or_abort _ = raise Y fun convert_connection _ = raise Y fun create_tcb (open_fun, key, conn_send) = let fun tcp_send _ = raise Y fun urgent_send _ = raise Y fun tcp_abort _ = raise Y val connection_internals = Connection_Internals {tcp_send = ref tcp_send, tcp_abort = ref tcp_abort, urgent_send = ref urgent_send} in connection_internals end fun do_connect (key, (conn as Conn.C {send, abort, extension}), open_fun) = let val internals = create_tcb (open_fun, key, send) val Connection_Internals {urgent_send, ...} = internals fun urgent_send_fun packet = (! urgent_send) packet fun build_extension () = let val tcp_extension = Tcp_Connection_Extension {urgent_send = urgent_send_fun} in (tcp_extension, internals) end in extension := build_extension () end fun no_op _ = () val handler_exception_value = {connection_handler = no_op, data_handler = no_op, status_handler = no_op} fun tcp_handler (open_fun, tally_open, tally_close, H tcp_handler_fun) = let fun conn_handler_fun key = let val started = ref false val tcp_connection_handler = ref (no_op: connection -> unit) fun start_connection conn = if ! started then ! tcp_connection_handler else ((started := true; do_connect (key, conn, open_fun); let val {connection_handler, data_handler, status_handler} = tcp_handler_fun key handle x => handler_exception_value in tcp_connection_handler := connection_handler; connection_handler end) handle x => (! tcp_connection_handler)) fun register conn = if ! started then ! tcp_connection_handler else start_connection conn fun conn_data_handler (conn as Conn.C {extension, ...}, packet) = (register conn; ()) fun conn_status_handler (conn as Conn.C {extension, ...}, status_value) = (register conn; ()) fun conn_connection_handler (connection as Conn.C {send, abort, extension}) = (let val tcp_connection_handler = register connection val (tcp_extension, Connection_Internals {tcp_send, tcp_abort, ...}) = ! extension val tcp_connection = C {send = ! tcp_send, abort = ! tcp_abort, extension = tcp_extension} in tally_open (); tcp_connection_handler tcp_connection; tally_close () end) in {connection_handler = conn_connection_handler, data_handler = conn_data_handler, status_handler = conn_status_handler} end in Conn.H conn_handler_fun end fun tcp_session session_fn conn_session = let val connection_count = ref 0; fun tally_open () = connection_count := ! connection_count + 1 fun tally_close () = (connection_count := ! connection_count - 1; if ! connection_count < 0 then () else ()) fun active_open (s, _, _) = s fun tcp_connect (Conn.S {connect = conn_connect, ...}) (address, handler) = conn_connect (address, tcp_handler (active_open, tally_open, tally_close, handler)) fun tcp_listen (Conn.S {listen = conn_listen, ...}) (pattern, handler, count) = raise Y fun tcp_extension (Conn.S {extension = conn_extension, ...}) = conn_extension val tcp_session = S {connect = tcp_connect conn_session, listen = tcp_listen conn_session, extension = tcp_extension conn_session} fun after_session () = () in (session_fn tcp_session before after_session ()) handle x => (after_session (); raise x) end fun session (session_fn: session -> 'a) = Conn.session (tcp_session session_fn) end ************* (* another version from Stephen Weeks (3/27/98, x86-linux) val i = fn _ => 13 val f : (unit -> 'a) * ('a -> int) -> int = fn _ => 14; functor G(type t) = struct val _ = f(fn () => (raise Bind) : t -> t, i) end Transcript: ... listen:Pattern.T * handler * unit -> listen} val session : (session -> 'a) -> 'a end functor Connection : uncaught exception FPRegEA raised at: cps/generic.sml:98.67-98 Comments: An fwrap operation is being invoked on a lambda variable that is not bound to a floating point type. [dbm, 12/6/99] Was marked as fixed in 110.4 [Zhong, 4/2/98]. Still broken on sparc/alpha in 110.24. (bug1360.1.sml and bug1360.2.sml result in "uncaught exception RegMap") Fix: - Test: bug1360.1.sml, bug1360.2.sml, bug1360.3.sml Owner: Zhong Status: open (alpha32-dunix) ---------------------------------------------------------------------- Number: 1361 Title: Equality between variables and constants in Word32. Keywords: equality, word, literals Submitter: George Russell george@persimmon.com Date: 02/27/98 Version: 110.2 System: Alpha Digital Unix 4.0 (564) Subsystem: SML compiler Severity: major Problem: Result of equality test is unexpected. Code: val i = 0wx7fffffff : Word32.word; i = 0wx7fffffff ; Transcript: Standard ML of New Jersey, Version 110.2, February 16, 1998 [CM; autoload enabled] - val i = 0wx7fffffff : Word32.word; val i = 0wx7fffffff : Word32.word - i = 0wx7fffffff ; val it = false : bool Comments: Also happens on OSF3.2 but not x86-linux or sparc-solaris. [Lal, 2/27/98] Nearly, all operations on the alpha have a 32 bit variant, however comparisons don't. This is fine if everything is sign extended, because a LDL (Load Long) will sign extended into 64 bits and the upper bytes can be ignored. Overflows will generate a trap discarding incorrectly sign extended values, etc. The problem is that the code to load up 0wx7ffffff into a register does not have the correct sign extension. So: val x = 0wx7fffffff : Word32.word; loads up 0wx7fffffff into a register and writes out the lower 32 bits even though the sign extension was wrong. In comparing x = 0wx7fffffff the problem shows up. I will try and get a fix for this into 110.3 and as a patch for the release. Fix: Test: bug1361.sml Owner: Lal Status: fixed in 110.7.1 [George, 6/5/98] ---------------------------------------------------------------------- Number: 1362 Title: Real.toManExp o Real.fromManExp Keywords: reals Submitter: Daniel C. Wang danwang@cs.princeton.edu Date: 03/04/98 Version: 110 System: Any/All Any Unix Subsystem: SML basis library Severity: major Problem: Bogus exponent returned from Real.toManExp causes Real.fromManExp to raise overflow. Code: Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled] - Real.toManExp 0.0; val it = {exp=~1022,man=0.0} : {exp:int, man:real} - val id = Real.fromManExp o Real.toManExp; val id = fn : real -> real - id 1.1 val it = 1.1 : real - id 0.0; uncaught exception overflow raised at: Transcript: val it = {exp=~1022,man=0.0} : {exp:int, man:real} - val id = Real.fromManExp o Real.toManExp; val id = fn : real -> real - id 1.1 val it = 1.1 : real - id 0.0; uncaught exception overflow raised at: Comments: The basis definition is also ambigious about the actual semantics of these functions, so I'm not sure if these are really bugs or not. This probably means there's a bug in the basis definition [dbm,3/4/98] See also bugs 1319 and 1228. Fix: (* Work Around *) structure RealFix = struct open Real val zero_r = 0.0 fun toManExp x = (if (Real.==(x,zero_r)) then {man=zero_r,exp=0} else Real.toManExp x) fun fromManExp {man,exp} = (if (Real.==(man,zero_r)) then zero_r else (Real.fromManExp {man=man,exp=exp})) end Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1363 Title: lexer doesn't detect EOF in string literals Keywords: compiler, lexer, EOF Submitter: Mikael Pettersson (mikpe@sophia.inria.fr) Date: 03/06/98 Version: 110.2, probably many more System: all Severity: minor Problem: lexer doesn't detect EOF in string literals Code: Transcript: brewer_1_echo -n 'val a = 5; "foo' | sml Standard ML of New Jersey, Version 110.2, February 16, 1998 [CM; autoload enabled] - val a = 5 : int brewer_2_echo -n 'val a = 5; (*' | sml Standard ML of New Jersey, Version 110.2, February 16, 1998 [CM; autoload enabled] - val a = 5 : int stdIn:17.12-17.14 Error: unclosed comment Comments: Fix: --- sml-nj/lex/ml.lex.~1~ Tue Feb 10 22:10:20 1998 +++ sml-nj/lex/ml.lex Thu Mar 5 19:41:21 1998 @@ -39,11 +39,14 @@ } type arg = lexarg type ('a,'b) token = ('a,'b) Tokens.token -fun eof ({comLevel,err,stringstart,sourceMap, ...} : lexarg) = let +fun eof ({comLevel,err,charlist,stringstart,sourceMap, ...} : lexarg) = let val pos = Int.max(!stringstart+2, SourceMap.lastChange sourceMap) in if !comLevel>0 then err (!stringstart,pos) COMPLAIN "unclosed comment" nullErrorBody + else if !charlist <> [] + then err (!stringstart,pos) COMPLAIN + "unclosed string, character, or quotation" nullErrorBody else (); Tokens.EOF(pos,pos) end Test: Owner: Andrew Status: fixed in 110.3 [Zhong] ---------------------------------------------------------------------- Number: 1364 Title: Mistakenly accepted datatype spec when signature matching. Keywords: datatype spec, matching Submitter: Stephen Weeks Date: 3/6/98 Version: 110.0.3 System: x86-linux Severity: minor Problem: SML/NJ accepts the following program. It should be rejected, because the specification requires type 't' to carry a constructor 'T', and it does not. Code: structure S : sig datatype t = T end = struct datatype u = T type t = u end; Transcript: Comments: [Zhong, 3/6/98] Dave, this bug is the side effect of your implementation of "datatype replication". It works correctly in older versions, e.g. 109.24, etc. [dbm, 8/14/98] The call of TU.unWrapDefStar in checkTycBinding in sigmatch.sml is the cause of the bug. At some point, replicated datatypes were represented as DEFtycs (eta-expansions of the original datatype), but this appears to have changed, and replicated datatypes are also bound as GENtycs. Note that the following variant of the above code (bug1364.2.sml) is legal. structure S : sig datatype t = T end = struct datatype u = T datatype t = datatype u end; Fix: Remove the call of TU.unWrapDefStar in checkTycBinding (sigmatch.sml). It is not necessary, because datatype replications are represented as GENtycs, not DEFtycs. Test: bug1364.1.sml, bug1364.2.sml Owner: dbm Status: 110.9 [dbm, 8/14/98] ---------------------------------------------------------------------- Number: 1365 Title: datatype representation across functor boundary Keywords: datatype representation Submitter: Daniel C. Wang danwang@cs.princeton.edu Date: 04/13/98 Version: 110.x System: Any/All Any Unix Subsystem: SML compiler Severity: Problem: There's a bug with the way the compiler is handling datatypes which carry unit as a value. The source code below reproduces the bug. I should get a list of all "A" but get one suprious "B" this seems to happen only when passing a structure as a functor argument. I've verified this on 110.0.3 (Linux) and 110.5 (Solaris) Code: signature S = sig type t datatype foo = A of t | B val a : unit -> foo val f : foo -> string end functor F(structure T:S) = struct fun f (T.A _) = "A" | f (T.B) = "B" end structure S1 : S = struct type t = unit datatype foo = A of t | B fun a () = A () fun f (A _) = "A" | f (B) = "B" end structure S2 : S = struct type t = int datatype foo = A of t | B fun a () = A 1 fun f (A _) = "A" | f (B) = "B" end structure Test = struct structure T1 = F(structure T = S1) structure T2 = F(structure T = S2) val it = [(S1.f (S1.a()),T1.f (S1.a ())), (S2.f (S2.a()),T2.f (S2.a ()))] end Transcript: - use "broken.sml"; [opening broken.sml] GC #0.0.0.0.1.15: (0 ms) signature S = sig type t datatype foo = A of t | B val a : unit -> foo val f : foo -> string end functor F : structure S1 : S structure S2 : S structure Test : sig structure T1 : structure T2 : val it : (string * string) list end val it = () : unit - Test.it; val it = [("A","B"),("A","A")] : (string * string) list Comments: Fix: Test: bug1365.1.sml Owner: Zhong Status: fixed in 110.6 and 110.0.4 [Zhong, 4/16/98] ---------------------------------------------------------------------- Number: 1366 Title: opaque signatures and functor specs Keywords: opaque signatures, functor argument signatures Submitter: Manuel Fahndrich, manuel@cs.berkeley.edu Date: 3/1/98 Version: 110 System: all Severity: major Problem: Opaque signature matching of a structure containing a functor doesn't handle the types of the functor arguments correctly. The functor argument types cannot be made to match. It seems as if the compiler uses the newly generated types in matching the functor argument signature, instead of the transparent ones. Code: structure Opaque :> sig type sort val base : sort functor Next(val s : sort) : sig val t : sort end end = struct type sort = int val base = 0 functor Next(val s : sort) = struct val t = s + 1 end end Transcript: /tmp/ml056YNw:1.1-22.6 Error: value type in structure doesn't match signature spec name: s spec: int actual: ?.Opaque.sort Comments: I don't know if this is supposed to work. If not, I'd like to know how opaque signature matching works with functor specs. [Zhong, 3/2/98] The above is actually not supposed to work. The reason is that functor signature matching follows the contravariant rule (just as when you perform subtyping on function types), so the argument structure of the actual functor Next must have "less information" than that of the abstract functor Next (in the signature). Unfortunately, under opaque signature matching, type "sort" in the functor spec is an abstract type while type "sort" in the "actual" functor has type "int", thus the above error message. The above works under transparent signature matching, because "sort" in the signature is equal to int as well. [Fahndrich, 3/2/98] Hmm, that's not a convincing argument. If it was solely due to contravariance, then the same reason would apply to functions, and it would be impossible to write structure Opaque :> sig type sort val base : sort val Next : sort -> sort end = struct type sort = int val base = 0 fun Next (s : sort) = s + 1 end There's gotta be more to it. Do you have an example that breaks the type system if what I expected to work is allowed? [Zhong, 3/2/98] Yes, theoretically, you could make your Next functor work, just handle it as the Next function above. But functor argument also contains type componentss in general, also, signature matching allows dropping certain components, so the "subtyping" relationship in signature matching is real and more complex --- in contrast to the core-ML functions (which have virtually none). [Fahndrich, 3/2/98] My example was the simplest possible. Of course I do want to use the generativity of types in my functor. To be more complete, there is one type T in the functor that I want to generate at each application: You still haven't told me why my example is disallowed. If I can match something using a transparent signature, then I should also be able to match it with an opaque signature, shouldn't I? Where are opaque signatures described? I thought they were a special feature of SML/NJ, but I can't find any info on it. Are opaque sigs part of the SML97 definition? (I only have the original one). structure Opaque :> sig type sort val base : sort functor Next(val s : sort) : sig type T val t : sort end end = struct type sort = int val base = 0 functor Next(val s : int) = struct type T = string val t = s + 1 end end [Fahndrich, 3/4/98] I talked to Mads Tofte about my problem. It turns out that this is part of SML/NJ's extension, even though not really a higher order functor. According to him, he sees no reason why my example shouldn't work. In particular, any structure that matches transparently should also match opaquely. Is there documentation about SML/NJ's signature matching procedure? Fix: Test: bug1366.1.sml Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1367 Title: *** Internal error: undefined sigTbl entry for signal 2 *** Keywords: Submitter: George Russell george@persimmon.com Date: 03/10/98 Version: 110.2 System: Alpha Digital Unix Subsystem: SML compiler Severity: minor Problem: After an attempt at exportFn which failed because it wasn't able to open the file to write the image, the signals seem mucked up: EG > Signals.inqHandler Signals.sigINT; produces > *** Internal error: undefined sigTbl entry for signal 2 *** Code: Please ask if you need more information. Transcript: Comments: Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1368 Title: 1+2 = 102 in IntInf Keywords: IntInf parsing Submitter: George Russell george@persimmon.com Date: 03/11/98 Version: 110.2 System: Alpha Digital Unix Subsystem: SML/NJ Library Severity: minor Problem: 1+2 = 102 Code: (IntInf.toString o valOf o IntInf.fromString) "1+2"; Transcript: (IntInf.toString o valOf o IntInf.fromString) "1+2"; val it = "102" : string Comments: I think NumScan is buggered. I have been reworking all your IntInf code for my own purposes, cleaning it up somewhat and making it use Word32s throughout. Do you want a copy? Fix: Test: bug1368.1.sml Owner: jhr Status: fixed in 110.6 (fix to be included in 110.0.4) ---------------------------------------------------------------------- Number: 1369 Title: Unbound exception on structure sharing violation Keywords: modules, signatures, sharing, structure sharing Submitter: Zhong Shao Date: 3/19/98 Version: 110 System: - Severity: major Problem: In 109.31, the compiler prints out: stdIn:39.24-39.39 Error: structure sharing violation: C # R which is correct, but starting from 109.32 (including 110), the compiler would raise Unbound exception ... Code: signature COM = sig structure C: sig structure P: sig end end end signature SIG = sig structure R : COM structure C : COM end signature SIG2 = sig structure R : COM structure C : COM sharing C = R end functor AutoLoadFun (X : SIG2) = struct end functor H (S : SIG) = struct structure AutoLoad = AutoLoadFun (S) end Transcript: Comments: Fix: Test: bug1369.1.sml Owner: dbm Status: fixed in 110.6, 110.0.4 ---------------------------------------------------------------------- Number: 1370 Title: op keyword pedantry Keywords: op Submitter: George Russell (george@persimmon.com) Date: 26/03/1998 Version: 110.2 System: Alpha/Digital Unix Severity: (very) minor Problem: op isn't parsed correctly Code: val k=op Int.precision; Transcript: (SML doesn't consider this a complete statement) Comments: Fix: Test: bug1370.sml Owner: dbm, Andrew Status: open ---------------------------------------------------------------------- Number: 1371 Title: signal-sysdep.h on HPUX10.01 Keywords: Submitter: Anthony Shipman als@tusc.com.au Date: 03/27/98 Version: 110.0.3 System: HPPA HPUX 10.01 Subsystem: Installation Severity: major Problem: The file src/runtime/mach-dep/signal-sysdep.h does not compile. The following link may be missing on some machines. It was on mine. /lib/cpp.ansi -> /opt/langtools/lbin/cpp.ansi Code: Transcript: Comments: Fix: In src/runtime/mach-dep/signal-sysdep.h at line 306 insert #ifdef SS_WIDEREGS /*if not on HPUX 10.01 */ #endif around the block of defines for the sc_ symbols. Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1372 Title: missing links in smlnj-110.0-3.i386.rpm Keywords: rpm,linux,package Submitter: Gergely Buday gergoe@math.bme.hu Date: 03/30/98 Version: 110.0.3 System: x86 Linux Red Hat 4.1 Subsystem: Installation Severity: cosmetic Problem: When I installed the package smlnj-110.0-3.i386.rpm I typed sml and nothing was started. The problem is /usr/share/smlnj/bin is not in the PATH. Obviously, it's trivial to make the symlinks, but rpms usually do that. See my fix for the problem. It's a matter of taste, but for me, links should go to /usr/local/bin. And, the documentation files are awaited to /usr/doc/smlnj-. Code: Transcript: garfield:~$ rpm -ivh smlnj-110.0-3.i386.rpm ... garfield:~$ sml bash: sml: command not found Comments: Otherwise, thanks for building an rpm! It's easier to convince the sysadm to install that than to compile all the stuff :-) [Blume, 5/1/98] Since we don't even officially support the RPM package, I would suggest we drop bugs 1372 and 1373 from the list. I don't have a Linux box with an older version of the C libraries, so there is nothing I can do about 1373. Personally, I also don't like to have those links in /usr/local/bin that 1372 claims are "missing", so to me this is "not a bug". Fix: ln -s /usr/share/smlnj/bin/.run-sml /usr/local/bin/sml ln -s /usr/share/smlnj/bin/.run-sml /usr/local/bin/ml-lex ln -s /usr/share/smlnj/bin/.run-sml /usr/local/bin/ml-yacc ln -s /usr/share/smlnj/bin/.run-sml /usr/local/bin/ml-burg ln -s /usr/share/smlnj/bin/.run-sml /usr/local/bin/sml-cm Test: Owner: Matthias Status: not a bug ---------------------------------------------------------------------- Number: 1373 Title: smlnj-110.0-3.i386.rpm works only with libc.so.6 Keywords: rpm,linux, libc Submitter: Gergely Buday gergoe@math.bme.hu Date: 04/01/98 Version: 110 System: x86 Linux <= Red Hat 4.2 Subsystem: Installation Severity: minor Problem: trying to install that rpm on a Red Hat 4.2, it complains about missing libc.so.6. Unfortunately, this can be cured only by upgrading to Red Hat 5.0. Or, if you put src.rpm on the ftp server. Would you like to do it? Me, and other 4.2 users would be happy. Code: Transcript: Comments: [Blume, 5/1/98] Since we don't even officially support the RPM package, I would suggest we drop bugs 1372 and 1373 from the list. I don't have a Linux box with an older version of the C libraries, so there is nothing I can do about 1373. Personally, I also don't like to have those links in /usr/local/bin that 1372 claims are "missing", so to me this is "not a bug". Fix: Test: Owner: Matthias Status: not a bug ---------------------------------------------------------------------- Number: 1374 Title: Datatype replication causes nonexhaustive match error. Keywords: datatype replication Submitter: Stephen Weeks Date: 4/3/97 Version: 110.0.3 System: x86-linux Severity: Problem: Ill-formed datatype declaration causes nonexhaustive match failure in elaborate/elabtype. Code: datatype t = T and u = datatype t Transcript: uncaught exception nonexhaustive match failure raised at: elaborate/elabtype.sml:232.43 Comments: Fix: Added Repl case to preprocess function in elabDATATYPEdec (elabtype.sml). Test: bug1374.1.sml Owner: dbm Status: fixed in 110.9, 110.0.4 [dbm, 8/14/98] ---------------------------------------------------------------------- Number: 1375 Title: Word31.fromString disagrees with Basis Library specification Keywords: Word31.fromString Submitter: Stephen Weeks Date: 4/8/98 Version: 110.0.3 System: x86-linux Severity: Problem: The expression: Word31.fromString "0wa" returns: SOME 0wxa I believe that it should return NONE, since the specification says that the string must be of the form: (0wx|0wX|0x|0X)?[0-9a-fA-F]+ This behavior is confusing, since the expression: 0w123 yields a different word than the expression: Word31.fromString "0w123" Here is another bug along the same lines: - Word31.fromString "100000000"; (* JHR: should return NONE *) uncaught exception overflow raised at: boot/num-scan.sml:136.50-136.58 Code: Transcript: Comments: It seems strange to me that the syntax for arguments to fromString is not the same as (or a superset of) the syntax for constants in the language. Is there a reason for this? [jhr, 4/9/98] We decided that we didn't want to deal with the "0x" and "0w" prefixes in the fromString functions, which forces a choice of radix. Otherwise, fromString accepts a larger set (e.g., "-" is accepted as a sign). Fix: Test: bug1375.1.sml, bug1375.2.sml Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1376 Title: cycle in datatype specs not detected Keywords: signatures, sharing, equality, dependency cycle Submitter: Zhong Shao Date: 4/4/98 Version: 110.4 System: - Severity: major Problem: bug109.sml now causes a "dependency cycle in instantiate" error Code: Transcript: signature EQSIG = sig type r datatype s = S of r datatype t = T of s sharing type t = r end bug109.sml:12.23-12.30 Error: operator and operand don't agree [equality type required] operator domain: ''Z * ''Z operand: X.t * X.t in expression: x = x Comments: Should report "dependency cycle in instantiate" Fix: Test: bug109.sml Owner: dbm Status: fixed in 110.5 [Zhong] ---------------------------------------------------------------------- Number: 1377 Title: OS.FileSys.tmpName differs in unspecified behaviour on Windows and Unix Keywords: basis Submitter: Andrew Kennedy andrew@persimmon.co.uk Date: 04/21/98 Version: 110.0.3 System: Any/All Any Unix Subsystem: SML basis library Severity: minor Problem: OS.FileSys.tmpName () differs between Unix and Windows in its behaviour when the current directory is not writeable. On Unix the /tmp directory is used so guaranteeing writeability, on Windows the current directory is used so that it raises an exception if this directory is not writeable. This should at least be mentioned in the basis spec. BETTER: use the temporary directory on Windows that is set by the environment variable TMP (also TEMP). Code: Transcript: Comments: [jhr, 4/21/98] Note, OS.FileSys.tmpName does not create a file, just a filename. I agree that the Windows implementation should probably use the standard temporary directory to generate these names, but this still not a guarantee that the file can be written. [Lorenz, 4/21/98] The implementation has been changed to call the win32 GetTempPath function to fill in the path slot for the GetTempFile function. >From the documentation we have, it's unclear where GetTempPath gets the path, but a good guess is that it looks for TMP,TEMP in the environment. This modification will be reflected in a release shortly. Fix: fixed to use windows' notion of the temp directory as a prefix for the temp filename. Use environment variable TMP or TEMP on Windows systems. Test: Owner: jhr, Lorenz Status: fixed in 110.6, 110.0.4 ---------------------------------------------------------------------- Number: 1378 Title: Incorrect behaviour of String.from{C}String on nonprintable chars Keywords: basis Submitter: Andrew Kennedy andrew@persimmon.co.uk Date: 04/21/98 Version: 110.0.3 System: Any/All Any Unix Subsystem: SML basis library Severity: minor Problem: According to the spec, String.fromString and String.fromCString should just "stop" when reaching a non-printable character or illegal escape sequence. In SML/NJ, they return NONE. Code: String.fromString "a\n" Transcript: - String.fromString "a\n"; val it = NONE : string option Comments: Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1379 Title: CM write permission error when CM (unnecessarily?) recompiles lib sources Keywords: "cm", "permissions", "openOut", "io", "dependencies" Submitter: Rona Machlin rona@saul.cis.upenn.edu Date: 04/27/98 Version: 110.0.3 System: Sparc SunOS 5.5.1 Subsystem: Compilation manager (CM) Severity: critical Problem: CM seems to recompile library sources unnecessarily. When the user doesn't have write permission to the existing bin, this error becomes critical. Transcript: gradine:/mnt/saul/home/rona/arrays/work/tmpbug> sml-cm Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled] - CM.make(); [starting dependency analysis] [scanning sources.cm] [checking CM/sparc-unix/sources.cm.stable ... not usable] [scanning /pkg/sml-110/lib/smlnj-lib.cm -> /pkg/sml-110/src/smlnj-lib/Util/sources.cm] [checking /pkg/sml-110/src/smlnj-lib/Util/CM/sparc-unix/sources.cm.stable ... not usable] GC #0.0.0.0.1.9: (0 ms) [parsing /pkg/sml-110/src/smlnj-lib/Util/atom-binary-map.sml] [writing /pkg/sml-110/src/smlnj-lib/Util/CM/DEPEND/atom-binary-map.sml failed] Comments: [Blume, 5/1/98] I don't think that 1379 is actually a bug in CM. It more looks like a problem with the local library installation that Rona was using. Also, the error does not pertain to the writing of binfiles but to the writing of dependency files. CM only does that if it finds a dependency file to be outdated. My guess is that somebody "moved" the library by copying - something that may have messed up the time stamps... Fix: Test: Owner: Blume Status: open ---------------------------------------------------------------------- Number: 1380 Title: Scan.[s]scanf does not allow ordinary [ character Keywords: library Submitter: Emden R. Gansner erg@research.att.com Date: 04/28/98 Version: 110 System: Any/All Any Unix Subsystem: SML/NJ Library Severity: minor Problem: There is no escape mechanism for specifying literal [ characters in format strings. Actually, [ should be treated as a literal unless preceded by a % character, following the C conventions. Code: Transcript: Comments: Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1381 Title: ml-yacc looping Keywords: ml-yacc, EOF Submitter: Nikolaj Bjorner Date: 2/5/98 Version: 110 System: - Severity: major Problem: [Mark Pichora ] I have discovered that parser2.sml (SMLNJ source file in ml-yacc) has a bug in it. I can't pin the bug down more than to say that parser1.sml works well in its place (the version that has no error recovery). For some reason the parser2.sml gets stuck sometimes when it finds an error in the input. Have you noticed this problem at all in the other parsers used in STeP? The bug is manifested by the parser2.sml continually calling lex() even after seeing an EOF symbol when parser2.sml is doing error recovery. I may look into the problem further, but for now parser1.sml does the job for the purposes of testing large files... [jhr] There is a bug in the error recovery that can send it into an infinite loop shifting EOF. The workaround is to make add %noshift EOF to the grammar. Code: Transcript: Comments: Fix: Test: tests.special/bug1381 Owner: Andrew? Status: open ---------------------------------------------------------------------- Number: 1382 Title: space leak in CML Keywords: continuations Submitter: John Reppy jhr@research.bell-labs.com Date: 05/04/98 Version: 110.0.1 System: Any/All Any Unix Subsystem: SML compiler Severity: critical Problem: Changes in the way that the compiler handles continuations has introduced a space leak in CML code, by breaking makeing choice non-tail recursive. Code: local open CML in fun test () = let val ch1 = channel () val ch2 = channel () fun rloop () = select [ wrap (recvEvt ch1, fn _ => rloop()), wrap (recvEvt ch2, fn () => ()) ] fun sloop i = (send(ch1, i); sloop(i+1)) in spawn rloop; sloop 0 end fun doit () = RunCML.doit(test, SOME(Time.fromMilliseconds 100)) end Transcript: - doit(); GC #0.0.0.1.4.105: (20 ms) GC #0.0.0.2.5.128: (220 ms) GC #0.0.1.3.6.151: (310 ms) GC #0.1.2.4.7.174: (400 ms) GC #1.2.3.5.8.197: (570 ms) GC #1.3.4.6.9.220: (60 ms) GC #1.4.5.7.10.243: (70 ms) GC #2.5.6.8.11.266: (860 ms) GC #2.6.7.9.12.289: (70 ms) GC #2.7.8.10.13.312: (70 ms) GC #2.8.9.11.14.335: (70 ms) GC #2.9.10.12.15.358: (80 ms) GC #2.10.11.13.16.381: (80 ms) GC #2.11.12.14.17.404: (80 ms) GC #2.12.13.15.18.427: (70 ms) GC #3.13.14.16.19.450: (1500 ms) GC #3.14.15.17.20.473: (90 ms) GC #3.15.16.18.21.496: (80 ms) GC #3.16.17.19.22.519: (70 ms) GC #3.17.18.20.23.542: (70 ms) GC #3.18.19.21.24.565: (80 ms) GC #3.19.20.22.25.588: (80 ms) ... Comments: This bug first appeared in 110.0.1 (it did not occur in 110.0.0) and is present in 110.0.3. Note that there were no changes to the CML source between 109.35 and 110.0.1. Fix: Test: tests.special/bug1382.sml Owner: Zhong? Status: fixed in 110.6, 110.0.4 ---------------------------------------------------------------------- Number: 1383 Title: Basis Library Specification of Char.toCString and String.toCString Keywords: toCString Submitter: Stephen Weeks Date: 5/7/98 Version: 110.0.3 System: x86-linux Severity: Problem: Char.toCString(chr 0) returns \0 instead of \000 This causes String.toCString to have strange behavior on strings containing embedded null characters followed by integer digits. For example, String.toCString("hello\000123there") produces hello\0123there which is a C string of length 12 instead of length 5. I propose that the Basis Library specification be changed so that Char.toString, when it returns an octal escape sequence, always returns a sequence of three octal digits. Code: Transcript: Comments: Reppy and Berry have agreed; spec will change accordingly. Fix: Test: bug1383.1.sml Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1384 Title: incorrect complaint about "inconsistent structure definitions" Keywords: modules, signatures, where structure defns Submitter: Mikolaj Konarski Date: 5/8/98 Version: 110.0.3 System: - Severity: major Problem: The following code should elaborate, but doesn't. Code: signature CAT = sig datatype t = c end; signature L_F = sig structure Cat : CAT end; signature TRANSLATOR = sig structure Cat : CAT structure LF : L_F where Cat = Cat end; functor Translator ( structure Cat : CAT structure LF : L_F where Cat = Cat ) :> TRANSLATOR where Cat = Cat where LF = LF = struct structure Cat = Cat structure LF = LF end; Transcript: Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled] - [opening /home/m/Dule/bug.sml] signature CAT = sig datatype t = c end signature L_F = sig structure Cat : sig datatype t = c end end signature TRANSLATOR = sig structure Cat : sig datatype t = c end structure LF : sig structure Cat : end end /home/m/Dule/bug.sml:15.11-26.6 Error: possibly inconsistent structure definitions at: LF.Cat *) Comments: Same as bug 1354 Fix: (see bug 1354) Test: bug1384.1.sml Owner: dbm Status: fixed in 110.9, 110.0.4 [dbm, 8/13/98] ---------------------------------------------------------------------- Number: 1385 Title: functor defn including "where" structure defs shouldn't elaborate Keywords: modules, signatures, functors, where structure Submitter: Mikolaj Konarski Date: 5/8/98 Version: 110.0.3 System: - Severity: major Problem: Following code elaboarates, but shouldn't, since the definition spec in LF substructure of TRANSLATOR signature is not satisfied (Cat and LF.Cat in the functor argument are unrelated). Code: signature CAT = sig datatype t = C end; signature L_F = sig structure Cat : CAT end; signature TRANSLATOR = sig structure Cat : CAT structure LF : L_F where Cat = Cat end; functor Translator ( structure Cat : CAT structure LF : L_F ) : TRANSLATOR where Cat = Cat where LF = LF = struct structure Cat = Cat structure LF = LF end; Transcript: Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled] - [opening /home/m/Dule/bug2.sml] signature CAT = sig datatype t = c end signature L_F = sig structure Cat : sig datatype t = c end end signature TRANSLATOR = sig structure Cat : sig datatype t = c end structure LF : sig structure Cat : end end functor Translator : val it = () : unit *) Comments: [dbm, 8/17/98] The basic bug is that signature matching is not verifying structure definitional specs. bug1385.3.sml is a more direct example. After fix of 1354, the secondary definition of LF.Cat in the functor result is not detected and doesn't produce a warning because the result signature is not instantiated. bug1385.4.sml is a variant that declares something like the functor result signature, and it generates a secondary definition warning. Fix: In matchStr1 (sigmatch.sml), the call of matchDefStr in the STRspec case needs to be passed the element list for this specs signature, not the inherited sigElements from the containing signature. Test: bug1385.1.sml, bug1385.2.sml, bug1385.3.sml Owner: dbm Status: fixed in 110.0.3, 110.9 [dbm, 8/17/98] ---------------------------------------------------------------------- Number: 1386 Title: redefinition of a type spec is not detected Keywords: signatures, where type, where structure Submitter: Mikolaj Konarski Date: 5/8/98 Version: 110.0.3 System: - Severity: major Problem: The code is incorrect, and should generate an error, but not the error that is currently generated. The type Cat.cat in signature L_F is defined by the where type definition, and cannot be redefined (indirectly) but the "where Cat = Cat" definition in the parameter specification of the Translator functor. This redefinition should have been detected, causing a different error, something like - signature S = = sig = type t = int = end = where type t = int; stdIn:17.1-21.19 Error: where type defn applied to definitional spec: t Code: signature CAT = sig eqtype cat val c : cat end; signature L_F = sig eqtype t structure Cat : CAT where type cat = t val r : t end; functor Translator ( structure Cat : CAT structure LF : L_F where Cat = Cat ) = struct val w = (Cat.c = LF.r) end; Transcript: Standard ML of New Jersey, Version 110.0.3, January 30, 1998... - [opening /home/m/Dule/bug3.sml] signature CAT = sig eqtype cat val c : cat end signature L_F = sig eqtype t structure Cat : sig type cat = t val c : cat end val r : t end /home/m/Dule/bug3.sml:19.15-19.29 Error: operator and operand don't agree [tycon mismatch] operator domain: ?.cat * ?.cat operand: ?.cat * ?.t in expression: Cat.c = LF.r *) Comments: [dbm, 8/17/98] This is related to bug 1354. The fix for that bug ignores the secondary redefinition of LF.Cat.c caused by the "where Cat = Cat" clause, generating a warning message. This warning message is incorrect because of the "" used to describe the tycon spec in question. It should be "cat", or "Cat.cat". See bug 1420. test/bugs/bug1386.1.sml:17.9-22.4 Warning: multiple defs at tycon spec: (secondary definitions ignored) test/bugs/bug1386.1.sml:21.13-21.27 Error: operator and operand don't agree [tycon mismatch] operator domain: ?.cat * ?.cat operand: ?.cat * ?.t in expression: Cat.c = LF.r the type error message is still generated because the redefinition of LF.Cat.cat does not take effect. Fix: see bug 1354 Test: bug1386.1.sml Owner: dbm Status: fixed in 110.9, 110.0.4 [dbm] ---------------------------------------------------------------------- Number: 1387 Title: scanning hex numbers from strings Keywords: StringCvt Submitter: Satish Chandra schandra@lucent.com Date: 05/07/98 Version: 110 (Dec 7,97) System: Mips Irix 6.4 Subsystem: SML basis library Severity: minor Problem: There seems to be a problem in scanning hex numbers from strings. (see comments below). Code: StringCvt.scanString (LargeInt.scan StringCvt.HEX) "0xffffffff"; Transcript: uncaught exception overflow raised at: boot/num-scan.sml:255.12-255.20 Comments: Same problem if you try to scan "0x80000000", which is LargeInt.minInt. However maxInt, i.e. "0x7fffffff" scans just fine. The problem appears only if the MSB of the word should be set. Fix: Test: bug1387.1.sml Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1388 Title: SML/NJ does not follow Basis Library Spec on div, mod, quot, rem Keywords: div mod quot rem Submitter: Stephen Weeks Date: 5-7-98 Version: 110.0.3 System: x86-linux Severity: major Problem: SML/NJ does not produce results that agree with the Basis Library Spec when div, mod, quot, or rem is applied to (minInt,~1). Here is a table of expressions, the result that SML/NJ returns, and my understanding of what the Basis Library Spec says. Expression SML/NJ Basis Library Spec ---------------------------------------- ---------- -------------------- Int31.div(Option.valOf Int31.minInt, ~1) Overflow Overflow Int31.mod(Option.valOf Int31.minInt, ~1) Overflow 0 Int31.quot(Option.valOf Int31.minInt, ~1) Overflow Overflow Int31.rem(Option.valOf Int31.minInt, ~1) Overflow 0 Int32.div(Option.valOf Int32.minInt, ~1) Div Overflow Int32.mod(Option.valOf Int32.minInt, ~1) 0 0 Int32.quot(Option.valOf Int32.minInt, ~1) Div Overflow Int32.rem(Option.valOf Int32.minInt, ~1) Div 0 Comments: [dbm,5/11/98] Different incorrect results returned on mipseb and sparc. Fix: Test: bug1388.1.sml Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1389 Title: core dump on Sparc/Solaris Keywords: code generation Submitter: Steve Brackin (Elsa Gunter, John Reppy) Date: 5/14/98 Version: 110.0.3 System: sparc-solaris Severity: critical (core dump!) Problem: HOL and SML code showing a problem in hol90.10 and/or smlnj110.0.3, in the form of gzipped, uuencoded text, is enclosed. It might be related to your earlier problem with swap space, but maybe not -- I get the problem on a Sun Ultra 1 running Solaris 2.5.1 with 286,560 1024-blocks of swap space. After you uudecode and gunzip the appropriate sections of this note, you should have the files bgny.sml, decide.sml, and main.hsc. If you put all three of these files in one UNIX directory, go there, and type hol90 < bgny.sml where "hol90" invokes hol90.10 made with smlnj110.0.3, then this produces a hol90 executable named phol.sparc-solaris. If you then type hol90 -u ./phol.sparc-solaris < main.hsc then this outputs the standard HOL90 banner, the messages Creating theory main Declaring theory "main" Theory "bgny" already consistent with disk, hence not exported Bus Error - core dumped Killed Files bgny.sml and decide.sml together define a HOL90 implementation of the BGNY belief logic and functions for automatically constructing proofs in this logic of desired properties of particular cryptographic protocols; they are two of the three pieces of the Automatic Authentication Protocol Analyzer (AAPA). File main.hsc defines a theory over the BGNY logic of the main-sequence protocol from CyberCash, Inc, a series of messages sent between customer software, merchant software, and CyberCash, for making secure and authenticated credit-card purchases. File main.hsc was produced by a specification translator, the third piece of the AAPA; you do not need to have this translator, since how it produced main.hsc is irrelevant to the hol90.10/smlnj110.0.3 problem. The thing about these files that's most likely to be relevant is that they're huge; CyberCash's main-sequence protocol is the largest, most detailed, protocol to ever be formally modeled and analyzed. None of my other examples caused a core dump. But all of my examples, including the main-sequence protocol one, ran successfully under hol90.8 and smlnj109. All my examples also ran significantly faster under hol90.8/smlnj109 -- 15.9 rather than 21.3 seconds in a typical small example. The computations I will need to perform in the future will probably be much more demanding than even the main-sequence protocol example; I will use a much more detailed logic for making inferences, and my company hopes to develop the AAPA into a commercial product. I'd appreciate anything you could do to find and fix the problem that's causing the core dump, and if possible to also speed up the computations. Code: See /home/sml/Dev/hol-bug Transcript: Comments: [jhr, 5/14/98] With help from Elsa, I've been able to reproduce the HOL core-dump bug on our Sparc/Solaris machine. I ran the HOL preprocessor by hand and then fed it into the HOL image running under the debugger. The bug looks like a compiler bug. (gdb) run @SMLload=phol < main.out Starting program: /usr/local/sml/110.0.3/src/runtime/objs/run.sparc-solaris @SMLload=phol < main.out ... GC #3.42.49.76.213.47451: (10 ms) GC #3.42.49.76.214.47479: (10 ms) GC #3.42.49.76.215.47522: (0 ms) Program received signal SIGBUS, Bus error. 0xef362c30 in ?? () (gdb) where #0 0xef362c30 in ?? () #1 0xedda3cd8 in ?? () #2 0x17e54 in RunML (msp=0x4dcc0) at ../kernel/run-ml.c:84 #3 0x17cfc in LoadML (loadImage=0xeffffc1f "phol", heapParams=0x4d1e8) at ../kernel/load-ml.c:38 #4 0x161f0 in main (argc=2, argv=0xeffffacc) at ../kernel/main.c:76 (gdb) disassemble 0xef362c20 0xef362c40 Dump of assembler code from 0xef362c20 to 0xef362c40: 0xef362c20 <_END_+4012989004>: add %g6, 4, %l5 0xef362c24 <_END_+4012989008>: add %g6, 0xc, %g6 0xef362c28 <_END_+4012989012>: ld [ %i1 + 0xff8 ], %o3 0xef362c2c <_END_+4012989016>: mov 0x82, %o5 0xef362c30 <_END_+4012989020>: ld [ %o3 + 0xc ], %o2 <==== CORE DUMP HERE 0xef362c34 <_END_+4012989024>: mov 1, %o4 0xef362c38 <_END_+4012989028>: st %o4, [ %g6 + 4 ] 0xef362c3c <_END_+4012989032>: st %o5, [ %g6 ] End of assembler dump. The value of $o3 looks a lot like an object descriptor: (gdb) print /x $o3 $5 = 0x82 The register %i1 is pointing into the allocation space. I don't have any ideas about how to track this down. Fix: Test: (/home/sml/Dev/hol-bug) Owner: Lal, jhr? Status: obsolete (new MLRISC sparc code generator) ---------------------------------------------------------------------- Number: 1390 Title: incorrect parsing of sigb sequences Keywords: parsing, grammar, signatures, where type, shift-reduce conflict Submitter: Gerhard Schneider Date: 5/15/98 Version: 110.0.3 System: - Severity: minor Problem: When implementing a parser for SML 97 we've found what we consider to be a discrepancy between the language definition and the implementations we have at our disposal. SML/NJ & MLWorks are able to parse this signature X = sig type i; type j; val f : i -> j; end where type i = int where type j = real; SML/NJ parses but MLWorks fails signature X = sig type i; type j; val f : i -> j; end where type i = int and type j = real; Both SML/NJ and MLWorks fail signature X = sig type i; type j; val f : i -> j; end where type i = int and Y = sig type t; end; The question is: Is this a bug in the definition (Figure 19 in Appendix A), in the imlementations or have we misunderstood this? Furthermore, since this doesn't seem to be of practical importance, why has this derived form been included in the definition. Code: Transcript: Comments: [dbm, 5/15/98] You could characterize this as an example of poor syntax design (I would). We didn't realize until too late that the addition of the "where type" construct introduced another shift-reduce conflict into the LALR1 (approximate) grammar. More precisely, in signature X = sig type i; type j; val f : i -> j; end where type i = int and ... the "and" can be followed either by another type definition or by another signature declaration. The yacc-style parser used in SML/NJ resolves the shift-reduce conflict by shifting the "and", which is why the version followed by a second type definition parses, but the one followed by a second signature declaration doesn't. I would have prefered to fix this problem by dropping the useless signature S1 = ... and S2 = ... form. This has to be categorized as a bug in SML/NJ, but a fairly low priority one. Someday we may fix it. In the meantime, just write signature S1 = ... signature S2 = ... Fix: Test: bug1390.1.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1391 Title: Compiler bug - TransTypes: unexpected wildcard-type in toTyc Keywords: datatype replication Submitter: Edgar Lederer lederer@ifi.unibas.ch Date: 05/20/98 Version: 110.0.3 System: Sparc Solaris Subsystem: SML compiler Severity: major Problem: The bug occurs when using datatype replication. See source code and transcript. Code: signature SIG1 = sig datatype ('a,'b) dt = C of ('a,'b) dt end signature SIG2 = sig structure Struct1 : SIG1 datatype dt = datatype Struct1.dt (* datatype replication *) end signature SIG3 = sig structure Struct2 : SIG2 val f : (unit, unit) Struct2.Struct1.dt -> unit (* OK! *) (* val f : (unit, unit) Struct2.dt -> unit (* Problem! *) *) end functor Fun (structure Struct2 : SIG2) : SIG3 = struct structure Struct2 = Struct2 (* fun f (Struct2.Struct1.C _) = () (* OK! *) *) fun f (Struct2.C _) = () (* Problem! *) end Transcript: Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled] - use "bug.sml"; [opening bug.sml] Error: Compiler bug: TransTypes: unexpected wildcard-type in toTyc Comments: Fix: [dbm] corrected bogus definition of mkStrict in typesutil.sml. Test: bug1391.1.sml Owner: dbm, Zhong Status: fixed in 110.7.? and 110.0.4 [dbm, 6/16/98] ---------------------------------------------------------------------- Number: 1392 Title: bad regions for "match nonexhaustive" messages Keywords: error messages, regions, match nonexhaustive Submitter: Norman Ramsey Date: 5/20/98 Version: 110.0.2 System: - Severity: medium Problem: The source location given for `match nonexhaustive' error messages appears to be the structure containing the offending function, rather than the function itself. It would be more useful if the offending match were isolated more precisely. Code: Transcript: Standard ML of New Jersey, Version 110.0.3, January 30, 1998 - use "tests/bug1392.1.sml"; [opening tests/bug1392.1.sml] tests/bug1392.1.sml:4.1-14.4 Warning: match nonexhaustive nil => ... structure S : sig val f : 'a list -> int val x : int val y : int val z : int end val it = () : unit Comments: Fix: Test: bug1392.1.sml, bug1392.2.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1393 Title: Overflow in std_out, memory leak while printing? Keywords: PervEnv/IO Submitter: Nikolaj S. Bjorner nikolaj@cs.stanford.edu Date: May 20'th 98 Version: 110.5 System: sparc-solaris2.5 Severity: critical Problem: After running printing to std_out for some hours with diagnostic information I got the following feedback: uncaught exception Io: output failed on "" with exception overflow /step/sml/bin/sml-cm: Fatal error -- Uncaught exception Io with raised at PervEnv/IO/text-io-fn.sml:444.14-444.56 Code: Perhaps a simple program that keeps printing to std_out will work. Comments: [Bjorner, 5/20/98] I noticed that my test program also requires more and more memory as it runs and suspect that this problem is connected with the exception. (this could naturally also be my bug...) [jhr, 5/20/98] Most likely, you are writing out more than 2^30 characters of data, which would result in an overflow in the file position counter. I guess we can use Int32.int for this counter, but that only doubles the time before you will get a crash. I don't think that the memory leak is connected to this exception. If you were running a CML program, I would say that it is probably a space leak that was introduced in 110.2 (we now have a fix for it). Fix: Test: Owner: jhr Status: not a bug (?) ---------------------------------------------------------------------- Number: 1394 Title: "*" not allowed as record label pattern abbreviation Keywords: record label Submitter: Stephen Weeks Date: 5/19/98 Version: 110.0.3 System: x86-linux Severity: minor Problem: SML/NJ complains with a parse error on the following: - val {*} = {* = 13}; stdIn:2.2-2.7 Error: syntax error: deleting RBRACE EQUALOP LBRACE stdIn:32.1-32.7 Error: syntax error: deleting ASTERISK EQUALOP INT However it accepts the following: val {* = op *} = {* = 13}; I believe the Definition says that both are legal. Code: Transcript: Comments: [Weeks, 5/27/98] I've changed my mind on the first example. I think SML/NJ agrees with what the Definitinon says, although it's error message is misleading. According to p. 57, val {*} = {* = 13} is a derived form for val {* = *} = {* = 13} This is not a valid program, since * is infix. However, the following program is valid, and SML/NJ rejects it. nonfix * val {*} = {* = 13} Fix: Test: bug1394.1.sml Owner: dbm, Andrew Status: open ---------------------------------------------------------------------- Number: 1395 Title: OS.FileSys.modTime fails for open file on Windows 95. Keywords: basis, OS.FileSys.modTime, file system, file modification time Submitter: Andrew Kennedy Andrew.Kennedy@persimmon.co.uk Date: 05/13/98 Version: 110 System: x86 Windows 95 Subsystem: SML basis library Severity: minor Problem: On all systems (including Windows NT) except for Windows 95, OS.FileSys.modTime succeeds when applied to a file that is currently open. On Windows 95 it raises an exception. Transcript: - OS.FileSys.modTime "myfile"; val it = TIME {sec=888240358,usec=0} : Time.time - val f = TextIO.openIn "myfile"; val f = - : TextIO.instream - OS.FileSys.modTime "myfile"; uncaught exception SysErr: modTime: cannot get file time raised at: boot/Win32/os-filesys.sml:27.27-27.71 Comments: If the bug cannot be `fixed', then (1) The basis documentation should be amended (2) The exception should be changed to "file is open" Fix: Test: Owner: jhr, Lorenz Status: open ---------------------------------------------------------------------- Number: 1396 Title: uncaught exception ltUnbound (secondary error) Keywords: Flex records Submitter: Andrew Kennedy andrew@persimmon.co.uk Date: 05/27/98 Version: 110.6 System: Any/All Any Unix Subsystem: SML compiler Severity: medium Problem: Compiler bug error message follows "unresolved flexible record" error message. Code: Transcript: - fun x y = 1; val x = fn : 'a -> int - x # y; stdIn:38.3-38.6 Error: unresolved flexible record pattern: {y=y,...} **** hmmm, I didn't find the variable 82 uncaught exception ltUnbound raised at: FLINT/kernel/ltybasic.sml:284.32-284.41 FLINT/plambda/flintnm.sml:569.23 Comments: Fix: Test: bug1396.1.sml Owner: Zhong Status: open ---------------------------------------------------------------------- Number: 1397 Title: Compiler bug caused by "val rec lazy" declaration Keywords: lazy sml, val rec lazy, compiler bug Submitter: Matthias Blume Date: 5/27/98 Version: 110.6 System: - Severity: major Problem: A "val rec lazy" declaration of a cyclical lazy list produces "Compiler bug: TransTypes: unexpected wildcard-type in toTyc". Transcript: Standard ML of New Jersey v110.6 [FLINT v1.41], May 21, 1998 [CM&CMB] val it = () : unit - Compiler.Control.lazysml := true; val it = () : unit - datatype lazy l = Nil | Cons of int * l; datatype l = Cons of int * l ?.susp | Nil type l = ?.l ?.susp - val rec lazy ones = Cons (1, ones); GC #0.0.0.0.1.1: (0 ms) Error: Compiler bug: TransTypes: unexpected wildcard-type in toTyc Comments: Fix: Corrected paths (e.g. "InLine.:=" instead of ":=") in defining assignVar and bangVar in Semant/elaborate/elabcore.sml. Test: tests.lazy/bug1397.1.sml Owner: dbm Status: fixed in 110.7.2 [dbm, 6/12/98] ---------------------------------------------------------------------- Number: 1398 Title: bus error in using Compiler.Profile Keywords: profiling, bus error Submitter: Nikolaj Bjorner Date: 5/22/98 Version: 110.0.3? System: ? Severity: major Problem: In an attempt to use Compiler.Profile to get some idea of performance and memory usage I encountered the following error: GC #2.10.19.54.3484.638472: (0 ms) %time cumsec #call name Bus error (core dumped) when trying to invoke: Compiler.Profile.reportAll TextIO.stdOut It had been called for the 1022'nd time before the error happened. Before then it would routinely print something like: %time cumsec #call name 78.80 52491 16 Test..dp.dp.simplify.simplify 19.28 65337 0 Minor GC 1.20 66142 0 Run-time System .70 66611 0 Major GC .00 66611 1 Test..dp.dp .00 66611 1 Test..dp.dp.axioms .00 66611 0 Compilation .00 66611 0 Other .00 66611 0 Test..debug.debug .00 66611 0 Test..debug.debug.axioms .00 66611 0 Test..debug.debug.simplify.simplify .00 66611 0 Test..getEq.getEq .00 66611 0 Test..getEq.getEq.anon This happened in a compilation done entirely without CML. I have also noticed some problems in using Compiler.Profile.reportAll when TextIO is bound to CML (but this could be expected I take). I was wondering if there were any ways to also monitor memory usage in some systematic way too. Did Tolmach's debugger support anything like that (well at first I found the concept of a debugger for ML somewhat weird: programs are "just correct" as soon as they are type-checked, but not knowing whether to find particular memory problems one place or the other it may be useful.) Comments: Fix: Test: Owner: Andrew? Status: open ---------------------------------------------------------------------- Number: 1399 Title: Overloaded operations done before type is known. Keywords: integers, alpha, arithmetic Submitter: George Russell george@persimmon.com Date: 06/03/98 Version: 110.6 System: Alpha Digital Unix 4.0B Subsystem: Installation Severity: minor Problem: This code raises Overflow when it shouldn't. Code: val m : Int32.int = 2147483647 val a : Int32.int = 2147 val q = m div a; Transcript: Standard ML of New Jersey v110.6 [FLINT v1.41], May 21, 1998 [CM; autoload enabled] - use "/tmp/test"; [opening /tmp/test] uncaught exception overflow raised at: Comments: [dbm, 6/3/98] Note that the bug only appears if input is a single declaration. In other words, nothing goes wrong if it is broken down into three separate declarations: - val m : Int32.int = 2147483647; val m = 2147483647 : Int32.int - val a : Int32.int = 2147; val a = 2147 : Int32.int - val q = m div a; val q = 1000225 : Int32.int Fix: Test: bug1399.1.sml Owner: Lal Status: fixed in 110.7.1 [George, 6/5/98] ---------------------------------------------------------------------- Number: 1400 Title: Prettyprinter bug Keywords: prettyprinter, constructor shadowing, multiple declarations Submitter: Matthias Blume blume@cs.princeton.edu Date: 06/04/98 Version: 110.6.3 System: Sparc Solaris Subsystem: SML compiler Severity: minor Problem: When defining a variable and -- within the same compilation unit -- a datatype constructor by the same name, then the pretty printer seems to get confused. Code: val a = 0 datatype t = a; Transcript: - val a = 0 = datatype t = a; val a = datatype t = a Comments: Fix: Test: bug1400.1.sml Owner: dbm Status: open ----------------------------------------------------------------------