Number: 801 Title: pretty printing problems Keywords: printing, pretty printer Submitter: John Reppy Date: 8/5/93 Version: 0.93 Severity: serious Problem: I've discovered several problems with the Pretty Printing in 0.93: 1) flush_ppstream does not seem to interact well with add_newline. Here is the code of a simple example: (* pp-bug.sml * * executing "doit" causes the PP_FAIL exception to be raised; removing either * the call to "flush_ppstream" or the "add_newline" avoids the exception. * * Also, if one doesn't have an enclosing block then PP_FAIL is raised on the * first break. *) fun pp ppStrm = let open System.PrettyPrint in add_string ppStrm "hello"; add_newline ppStrm; flush_ppstream ppStrm end; fun doit () = pp (System.PrettyPrint.mk_ppstream{ consumer = IO.outputc IO.std_out, linewidth = 80, flush = fn () => IO.flush_out IO.std_out }); 2) An "add_break" that doesn't have an enclosing block causes a PP_FAIL too. There ought to be an implicit block around the entire sequence of operations on a ppstream. 3) The exception PP_FAIL is not visible at top-level, so it isn't possible to get its string argument to understand the bug. Either, it should be replaced by the Fail exception, or it should be made visible, or, at least, the top-level exception handler should handle it. 4) The structure PrettyPrint should be split into a library module that implements pretty-printing, and a module for binding pretty-printers. Many applications will use the former, but not the latter. Owner: dbm Status: open ---------------------------------------------------------------------- Number: 802 Title: missing signature PRETTYPRINT Keywords: Submitter: John Reppy Date: 8/9/93 Version: 0.93 Severity: minor Problem: the signature PRETTYPRINT is not in the environment as advertised Owner: dbm Status: fixed in 109.30 [dbm, 7/14/97] --------------------------------------------------------------------- Number: 803 Title: Subscript exception during elaboration Keywords: Submitter: Andrew Appel Date: 8/12/93 Version: 0.93 Severity: major Problem: There's a bug in elaborate when compiling the following file. The message is "uncaught exception Subscript". I suspect it has to do with the higher-order functors. Code: (* viscomp.sml *) signature PRINTHOOKS = sig (* all output goes to Control.Print.out *) val prAbsyn : StaticEnv.staticEnv -> Absyn.dec -> unit val prLambda : Lambda.lexp -> unit val prLamFun : Lambda.lexp -> int -> unit end signature VISCOMP = sig structure Stats : STATS structure Control : CONTROL structure Source : SOURCE structure ErrorMsg : ERRORMSG structure Symbol : SYMBOL structure Index : INDEX structure StaticEnv : STATICENV structure DynamicEnv : DYNENV structure Environment : ENVIRONMENT structure ModuleId : MODULE_ID structure ModuleTable: MODULE_TABLE structure Watcher : WATCHER structure Recorder : RECORDER structure PickleEnv : PICKLE_ENV structure PersStamps : PERSSTAMPS structure PrettyPrint : PRETTYPRINT structure Ast : AST structure Compile : COMPILE functor RegSpec : REGSPECFUN functor CPSopt : CPSOPTFUN functor CPStrans : CPSTRANSFUN functor Convert : CONVERTFUN functor Contract : CONTRACTFUN functor Eta : ETAFUN functor Expand : EXPANDFUN functor Closure : CLOSUREFUN functor Spill : SPILLFUN structure Limit : LIMIT functor CPSgen : CPSGENFUN structure Interact : INTERACT structure Machm : CODEGENERATOR structure AllocProf : sig val reset : unit -> unit val print : outstream -> unit end structure PrintHooks : PRINTHOOKS val version : string val architecture: string end functor VisComp(Machm : CODEGENERATOR) = struct local structure V : VISCOMP = struct structure Stats = Stats structure Control = Control structure Source = Source structure ErrorMsg = ErrorMsg structure Symbol = Symbol structure Index = Index structure StaticEnv = StaticEnv structure DynamicEnv = DynamicEnv structure Environment = Environment structure ModuleId = ModuleId structure ModuleTable = ModuleTable structure Watcher = Watcher structure Recorder = Recorder structure PickleEnv = PickleEnv structure PersStamps = PersStamps structure PrettyPrint = PrettyPrint structure Ast = Ast structure Compile = CompileF(Machm) functor RegSpec = RegSpec functor CPSopt = CPSopt functor CPStrans = CPStrans functor Convert = Convert functor Contract = Contract functor Eta = Eta functor Expand = Expand functor Closure = Closure functor Spill = Spill structure Limit = Limit functor CPSgen = CPSgen structure Interact = Interact(EvalLoopF(Compile)) structure Machm = Machm structure AllocProf = struct val reset = AllocProf.reset val print = AllocProf.print_profile_info end structure PrintHooks : PRINTHOOKS = struct fun prAbsyn env d = PrettyPrint.with_pp (ErrorMsg.defaultConsumer()) (fn ppstrm => PPAbsyn.ppDec(env,NONE) ppstrm (d,200)) fun prLambda lexp = (MCprint.printLexp lexp; print "\n") fun prLamFun lexp v = (MCprint.printFun lexp v; print "\n") end val version = "Standard ML of New Jersey, Version 0.99, 13 August 1993" val architecture = Machm.architecture end in open V structure Lambda = Lambda structure LambdaType = LambdaType structure CPS = CPS structure Intmap = Intmap end end Comment: [dbm, 8/13/94] Almost certainly the same as bug 860. Status: fixed in 107 (dbm) ---------------------------------------------------------------------- Number: 804 Title: Substring exception caused by decimal fractions Keywords: Submitter: Roderick Moten rodmoten@cs.cornell.edu Date: 8/13/93 Version: 0.97 Severity: major Problem: The following cause a Substring exception to be raised. val j = 0.5; makestring 0.5; However let val j = 0.5 in j + j end; and val j = 1.0 work fine. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 805 Title: incompatibility between profiling and IO.execute (under A/UX) Keywords: Submitter: Richard Bornat Date: 8/17/93 Version: 0.93 Severity: major Problem: The profiling tool issued with version 0.93 seems to be incompatible with IO.execute. Symptoms: IO.execute works normally following Profile.profileOff(); after Profile.profileOn() then the execute doesn't actually launch a new process. This is on a Mac IIfx running A/UX 3.0; I don't know if it is an A/UX problem or not. (Also, I'm having trouble with profiling and sourcegroups: presumably I have to build smlp *and then* smlp.sg. Certainly it doesn't work the other way around). Owner: John Status: obsolete ---------------------------------------------------------------------- Number: 806 Title: profiling under sourcegroup (or SC) Keywords: Submitter: Richard Bornat Date: 8/17/93 Version: 0.93 Severity: major Problem: There seems to be no way (?) to make sourcegroups sensitive to the Profile tool, so that stuff compiled by a sourcegroups compiler can't be profiled. I've tried compiling profile-script in an sg compiler; I've tried compiling sg in a profiling compiler; nothing seems to do any good. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 807 Title: nongeneric weak type variable error when not at top-level Keywords: Submitter: Dave Berry, daveb@harlequin.co.uk Date: 8/18/93 Version: 0.93 System: SPARC, SUNOS 4.1.3 Severity: Minor? Problem: nongeneric weak type variable error when not at top-level Code: structure Foo = struct local val r = ref NONE in end end; Transcript: - structure Foo = = struct = local = val r = ref NONE = in = end = end; std_in:15.1-15.14 Error: nongeneric weak type variable r : '0Z option ref - Comments: In version 0.75 this happens outside structures as well. In 0.93 it only happens inside structures. Status: fixed in 1.05 (dbm-105b) ---------------------------------------------------------------------- Number: 808 Title: directory stripping behavior of IO.execute Keywords: Submitter: Bernard Sufrin (Bernard.Sufrin@prg.oxford.ac.uk) Date: 8/20/93 Version: 0.93 Problem: In boot/perv.sml you go to some trouble to eliminate the directory prefix of the pathname of the command being executed from the ``zeroth'' argument as it appears in the argument list. The C shell -- and as far as I can tell other program-calling program -- don't do this; moreover several programs need to know the path via which they were executed, and this ``feature'' causes them some confusion. Why not leave the decision whether or not to ``directory strip'' up to the caller? ======= fun execute_in_env (cmd, args, env) = let fun basename s = let val len = slength s fun f i = if ieql(i, len) then s else if ieql(ordof(s, i), 47 (* ordof "/" *)) then g (i+1, i+1) else f (i+1) and g (base, i) = if ieql(i, len) then PreString.substring(s, base, len-base) else if ieql(ordof(s, i), 47 (* ordof "/" *)) then g (i+1, i+1) else g (base, i+1) in f 0 end fun mapCString [] = [] | mapCString (s::r) = (c_string s)::(mapCString r) val cArgs = mapCString ((basename cmd) :: args) val cEnv = mapCString env val (fdin, fdout) = exec (c_string cmd, cArgs, cEnv) Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 809 Title: transFctLty compiler bug Keywords: Submitter: Appel Date: 9/16/93 System(s) and Version: MIPS (presumably all) SML/NJ Version: 1.00 Machine: MIPS Severity: minor Problem: compiler bug Code: funsig A() = sig end functor F(functor S : A) = struct end funsig FS () = sig end signature U = sig functor FF : FS end structure T : U = struct functor FF = F end Transcript: bug.sml:8.11-10.3 Error: unmatched structure spec: S Error: Compiler bug: transFctLty on wrong objects Fix: added "ERROR_FCT => BOGUSty" to two matches, in transFctLty, and transFctLty0. Status: fixed in 1.05b --- dbm/105b ---------------------------------------------------------------------- Number: 810 Title: signatureless abstractions Keywords: Submitter: Andrew Appel Date: 9/21/93 Version: 1.01 Severity: major Problem: abstraction declaration without a signature constraint is accepted. Code: Transcript: Standard ML of New Jersey, Version 1.01, 16 September 1993 - abstraction S = struct val x = 6 end; structure S : sig val x : int end - Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 811 Title: Unix.exit does not flush open streams Keywords: Submitter: Emden R. Gansner, erg@ulysses.att.com Date: 9/22/93 Version: 1.01 System: all Severity: minor Problem: Unix.exit does not flush open streams Code: Transcript: Standard ML of New Jersey, Version 1.01, 16 September 1993 [SC 56a] val it = () : unit - fun main(_,_) = (print "hello\n"; System.Unix.exit 0); val main = fn : 'a * 'b -> 'c - exportFn ("tst",main); [Major collection... 99% used (2253660/2271116), 730 msec] [Major collection... 0% used (5988/2259160), 0 msec] [Decreasing heap to 295k] w) ./tst hello w) ./tst > out w) cat out w) Comments: Since exit was promoted out of Unsafe to Unix, it seems reasonable to adopt Unix semantics and have it flush open streams. [Mikael Pettersson (mpe@ida.liu.se), 8/25/94] If the final "System.Unix.exit 0" is replaced with "System.CleanUp.cleanup System.CleanUp.CleanForQuit; System.Unix.exit_ 0" then the buffer flushing works as it should. BUT, unless I am very much mistaken, this is how System.Unix.exit was defined in the first place... Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 812 Title: strange floating point error Keywords: Submitter: Mr. Jon S. Squire Date: 9/21/93 Version: 0.93 System: SGI IRIX 4.0.5c Severity: minor Problem: code dies with "strange floating point error, 14." Then exits sml. Code: fun how_big(x:real):unit*unit*real = (print x, print "\n", #3(how_big(2.0*x))); how_big 2.0; (* should give largest value then "uncaught exception Overflow"*) Comments: generally seems to problem in C library when IEEE arithmetic returns infinity Owner: Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 813 Title: limited length of directory name in cd Keywords: Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 9/26/93 Version: 101 System: Decstation Ultrix Severity: minor Problem: limited length of directory name in cd Code: (* There is a sub-directory called "knuth-bendix" in the current directory *) System.Directory.cd "knuth-bendix"; (* There is a sub-directory called "knuth-bendi" in the current directory *) System.Directory.cd "knuth-bendi"; Transcript: - System.Directory.cd "knuth-bendix"; uncaught exception NotDirectory - System.Directory.cd "knuth-bendi"; val it = () : unit Comments: As long as the directory name is longer than 11 charaters, the System.Directory.cd raises the NotDirectory exception. [dbm] Works ok for OS.FileSys.chDir in 109.21. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 814 Title: missing install_pp Keywords: Submitter: Elsa Gunter Date: 9/29/93 Version: 101 Severity: major Problem: install_pp is now in PPTable: PPTABLE, which is not incorporated in Compiler Fix: Add PPTable to VISCOMP and VisComp in build/viscomp.sml. Status: fixed in 1.02 (access via PPTable) ---------------------------------------------------------------------- Number: 815 Title: incorrect paths printed for types (missing structures) Keywords: Submitter: Dave MacQueen Date: 10/13/93 Version: 102d Severity: major Problem: incorrect paths printed for types (missing structures) Code: functor F(X: sig functor G() : sig type t end end) = struct structure A = X.G() end; structure Rint = F(struct functor G() = struct type t = int end end); structure Rbool = F(struct functor G() = struct type t = bool end end); Transcript: Standard ML of New Jersey, Version 1.01, 16 September 1993 - use "hack.sml"; [opening hack.sml] functor F : structure Rint : sig structure A : ... end structure Rbool : sig structure A : ... end val it = () : unit - 3: Rint.A.t; val it = 3 : ?.Rint.t - true : Rbool.A.t; val it = true : ?.Rbool.t - 3 : Rbool.A.t; std_in:5.1-5.13 Error: expression and constraint don't agree (tycon mismatch) expression: int constraint: ?.Rbool.t in expression: 3 Fix: Add path field to APPLY variant of Functor type. Status: fixed in 1.06 (dbm-106a) ---------------------------------------------------------------------- Number: 816 Title: repeated component names in signatures Keywords: Submitter: Mark Lillibridge (mdl@cs.cmu.edu) Date: 10/4/93 SML/NJ Version: 0.93, February 15, 1993 Machine: DECstation 5000/125, MACH OS Severity: minor Problem: The handling of field names in signatures is screwed up. A perfectly legal program fragment is rejected simply because it repeats a field name in two different structure specs. (See code & transcript example) Note that renaming the outer structure results in the error going away. Code: signature s = sig structure a : sig structure a : sig type t end val x : a.t end end; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "sml-bug2.sml"; [opening sml-bug2.sml] sml-bug2.sml:5.11-5.13 Error: unbound structure: a in path a.a.t - Comments: There are undoubtly other bugs caused by the same underlying problem. A similar problem may exist for structure definitions. I regard this as a minor bug because it can always be programmed around by never repeating structure names in a structure and its components. Owner: Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 817 Title: spec scope confusion Keywords: Submitter: Mark Lillibridge (mdl@cs.cmu.edu) Date: 10/4/93 SML/NJ Version: 0.93, February 15, 1993 Machine: DECstation 5000/125, MACH OS Severity: minor Problem: This is probably related to the last bug report I sent in (bug 816). SML/NJ seems to think (incorrectly) that the scope of a structure spec in a signature starts immediately instead of after the spec is completed. It does this both on output and input of signatures, resulting in illegal signatures being both accepted and printed. The third example below demonstrates how this sometimes results in signatures being read incorrectly. Code: Compiler.Control.Print.signatures := 20; signature prints_wrong = sig structure y : sig type b val x : b end end; signature illegal_sig = sig structure y : sig type b val x : y.b end end; signature wrong_sig = sig structure y : sig type b end structure z : sig structure y : sig type b val x : y.b end end end; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "sml-bug.sml"; [opening sml-bug.sml] val it = () : unit signature prints_wrong = sig structure y : sig type b val x : y.b [Wrong! No y in scope here] end end signature illegal_sig = sig structure y : sig type b val x : y.b [Ditto!] end end signature read_wrong_sig = sig structure y : sig type b end structure z : sig structure y : sig type b val x : z.y.b [Wrong! This should refer to the ] end [first b, not the second. Also, z] end [is not in scope here.] end val it = () : unit - Comments: The type of x in prints_wrong show print as just "b". The second signature is not legal and should be rejected. (Note that there is no y structure floating around here at top level.) The type of x in read_wrong_sig should be "y.b". Owner: Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 818 Title: Compiler bug: UsageMap on .... in cps/contract.sml Keywords: Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 10/6/93 Version: 1.01* System: Decstation Ultrix Severity: minor Problem: Compiler bug: UsageMap on .... in cps/contract.sml Code: (* for a compiler with representation analysis turned off and argument flattening turned on *) Compiler.Control.CG.representations; Compiler.Control.CG.flattenargs; use "bmark.sig"; use "vliw.sml"; (* standard vliw benchmark *) Transcript: (* Compiler.Control.CG.representations = ref false *) (* Compiler.Control.CG.flattenargs = ref true *) [opening vliw.sml] vliw.sml:3504.2-3504.22 Warning: match nonexhaustive INT i => ... vliw.sml:3307.3-3401.30 Warning: match nonexhaustive FETCH {dst=(d,_),immutable=_,offset=ofst,ptr=(p,_)} => ... STORE {offset=ofst,ptr=(p,_),src=(s,_)} => ... GETLAB {dst=(d,_),lab=(l,_)} => ... GETREAL {dst=(d,_),value=v} => ... MOVE {dst=(d,_),src=(s,_)} => ... ARITH {dst=(d,_),oper=opn,src1=(s1,_),src2=(s2,_)} => ... ARITHI {dst=(d,_),oper=opn,src1=(s1,_),src2=n1} => ... JUMP {dst=(d,_),live=_} => ... BRANCH {dst=(labnum,_),live=_,src1=(s1,_),src2=(s2,_), test=comp} => ... NOP => ... LABEL {lab=_,live=_} => ... LABWORD {lab=_} => ... WORD {value=_} => ... Error: Compiler bug: UsageMap on 49077 Comments: UsageMap is an exception defined in the new contract.sml. This bug only occurs in compilers that does not do representation analysis but does do argument flattening. Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 819 Title: changes for 386bsd Keywords: Submitter: Mark H. Linderman (linder@box.EE.CORNELL.EDU) via Mark Leone (mleone@cs.cmu.edu) Date: 10/5/93 System(s) and Version: 386bsd SML/NJ Version: 0.93 Machine: 386/486 PCs running 386bsd (*not* bsd/386) Severity: minor Problem: Getting SML/NJ to run under 386bsd Code: Transcript: Comments: 386bsd is a free bsd implementation for 386/486 machines. It is based on the net2 release of bsd, and was ported by Bill and Lynne Jolitz. It's available by anonymous ftp at agate.berkeley.edu. It's not the same as bsd/386, which is a commercial product by BSDI. The current 386 Mach/BSD runtime works fine under 386bsd except for export, because 386bsd uses a different executable file format. A quick-and-dirty fix is to build the compiler with "-i386 bsd386" after applying the patch below. A better approach would be to add a new flag to makeml, #define a new symbol (say, NET386BSD), and add that symbol to the appropriate #ifdefs. The documentation should also be updated to indicate that we now support this OS. *** export.c.dist Tue Nov 17 18:05:23 1992 --- export.c Mon Dec 21 11:15:47 1992 *************** *** 108,121 **** # define ZMAGIC 0413 #endif - #ifdef BSD386 - # ifdef ZMAGIC - # undef ZMAGIC - # endif ZMAGIC - #define ZMAGIC QMAGIC - #endif BSD386 - - /* Garbage collection is already done. * Data to be saved is: * 0 -> ceil(etext) text --- 108,113 ---- *************** *** 232,238 **** } #endif ! #if sony_news || MORE {int i, nzeros = getpagesize()-bytcount; char zeros[4096]; for(i=0;i unit - val (I,O) = execute("/bin/date",[]); std_in:3.1-3.35 Error: operator and operand don't agree (tycon mismatch) operator domain: string operand: string * 'Z list in expression: execute ("/bin/date",nil) tiree% /usr/local/sml/bin/sparc/sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - execute; val it = fn : string * string list -> instream * outstream - val (I,O) = execute("/bin/date",[]); val I = - : instream val O = - : outstream Comments: The version of execute that is in the top-level loop of sml can be found as IO.execute in smld. Fix: Rename UserDebugCommands.execute in dbguser/commands.sml to something else. Perhaps this is too extreme, but it is awkward having the same identifier bound to different functions in the top level of sml and smld. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 821 Title: Compiler bug: Instantiate:explore_tclass.5 Keywords: Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 10/21/93 Version: 1.01 System: Decstation Ultrix Severity: major Problem: Compiler bug: Instantiate:explore_tclass.5 Code: (* the standard ML-YACC benchmark *) use "yacc.sml"; Transcript: Standard ML of New Jersey, Version 1.01, 16 September 1993 - use "yacc.sml"; [opening yacc.sml] [Major collection... 63% used (2661924/4210724), 1816 msec] [Increasing heap to 8192k] [Major collection... 89% used (3775408/4229428), 2656 msec] [Increasing heap to 11388k] [Major collection... 84% used (4944692/5860300), 3437 msec] [Increasing heap to 14764k] [Major collection... 39% used (3011648/7591656), 2129 msec] [Decreasing heap to 9008k] yacc.sml:1488.1-1586.3 Error: The constructor PARSER_NAME of datatype control has different representations in the signature and the structure. Change the definition of the types carried by the constructors in the functor formal parameter and the functor actual parameter so that they are both abstract, or so that neither is abstract. Error: Compiler bug: Instantiate:explore_tclass.5 - Comments: No problem for complaining about the different datatype representations. But the warning about "Instantiate: explore_tclass.5" is obviously a bug. This bug doesnot occur if I turn the Compiler.Control.CG.newconreps flag off. However, the bug does not show up on the following simple program either, signature HEADER = sig type symbol datatype control = NODEFAULT | VERBOSE | PARSER_NAME of symbol end functor HeaderFun () : HEADER = struct type symbol = string * int datatype control = NODEFAULT | VERBOSE | PARSER_NAME of symbol end structure A : HEADER = HeaderFun() Owner: Status: obsolete ---------------------------------------------------------------------- Number: 822 Title: Compiler bug: compType/checkweak (as secondary error) Keywords: Submitter: Emden R. Gansner, erg@research.att.com Date: 10/25/93 Version: 1.01 System: all Severity: minor Problem: Compiler bug reported on bad code Code: (* file: bug.sml *) signature STATIC_ARRAY = sig type elem type array val array : int * elem -> array end functor DynamicArray (A : STATIC_ARRAY) = struct end structure ModGraph = struct structure NodesArray = DynamicArray (struct type elem = G.node list type array = elem Array.array val array = Array.array end) end Transcript: - use "bug.sml"; [opening bug.sml] bug.sml:15.21-15.26 Error: unbound structure: G in path G.node Error: Compiler bug: compType/checkweak - Owner: Status: obsolete ---------------------------------------------------------------------- Number: 823 Title: quot and div are identical Keywords: Submitter: Emden R. Gansner, erg@research.att.com Date: 11/2/93 Version: 1.01 System: all Severity: minor Problem: quot and div are identical Code: Transcript: - ~3 div 2; val it = ~2 : int - ~3 quot 2; val it = ~2 : int (* should be ~1 *) Comments: Both quot and div are bound to InLine.inldiv in perv.sml Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 824 Title: Incorrect documentation Integer.rem Keywords: Submitter: Emden R. Gansner, erg@research.att.com Date: 11/2/93 Version: 1.01 System: all Severity: minor Problem: Incorrect documentation Integer.rem Code: Transcript: Comments: i rem j is described as a non-negative number, which is incorrect. Also, the inequalities given for i mod j are unnecessary. Given the definitions of div and quot, mod and rem can be defined as i rem j = i - j(i quot j) and i mod j = i - j(i div j). Owner: Status: obsolete ---------------------------------------------------------------------- Number: 825 Title: sml-mode.el incompatible with emacs 19 Keywords: Submitter: Jeffrey Hsu Date: 10/2/93 Version: 0.93 Severity: major Problem: The sml-mode.el calls make-shell, which is no longer defined in shell.el in emacs 19. Fix: [dbm:] use sml-mode 3.1, which works with Emacs 19.xx. Status: fixed ---------------------------------------------------------------------- Number: 826 Title: zombie sml processes Keywords: Submitter: Elsa Gunter Date: 10/27/93 Version: 1.01 + SC System: SPARC 2 Severity: minor Problem: I have been witnessing some very strange behaviour with sml-sc version 1.01 when running inside a shell in emacs over the internet. Three times now, I have lost my connection. I have then logged back into the same machine (tiree), restarted emacs, (done a few things like read my mail), started a shell and found myself suddenly in the middle of the sml process that was running in the old shell in the old emacs. I report this to you because whatever all the problem is, it seems like a potential source of arrant sml processes living forever (well until someone explicitly kills them) and possibly consuming lots of resources in the meantime. Owner: John Status: obsolete [new runtime] ---------------------------------------------------------------------- Number: 827 Title: exportML including future evaluations Keywords: Submitter: Jeff Ullman Date: 6/11/93 Version: 0.93 (?) Severity: minor Problem: Both of you took me to task for believing (see p. 51, ch. 23) that exportML can export things from its own future. Seemed weird to me, and I had trouble believing it. However, here is the ML program I executed to create a file "foo": ********************************************************** exportML("foo"); fun comb1(n,m) = let exception BadN; exception BadM; in if n <= 0 then raise BadN else if m < 0 orelse m > n then raise BadM else if m=0 orelse m=n then 1 else comb1(n-1,m) + comb1(n-1,m-1) end; comb1(10,5); *********************************************************** and here is the result of running foo: ************************************************** val it = true : bool val comb1 = fn : int * int -> int val it = 252 : int - ************************************************** This seems to justify my bullet at the end of Ch. 23. it also substantiates the claim that when foo is run (even with the code of Fig. 23.2 rather than the code above) it will echo the value of comb. Owner: Status: open ---------------------------------------------------------------------- Number: 828 Title: PPDec.getVal bug when "opening" structures Keywords: Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 11/17/93 Version: 1.01 System: Decstation Ultrix Severity: major Problem: PPDec.getStamp bug when "opening" structures Code: (* anytime in the compiler *) open String List IO Bool Real; Transcript: Standard ML of New Jersey, Version 109.21, October 28, 1996 [CM; autoload enabled] - open String List IO Bool Real; GC #0.0.0.1.2.38: (45 ms) open String List IO Bool Real val translate = fn : (char -> string) -> string -> string val tokens = fn : (char -> bool) -> string -> string list val toString = fn : string -> string val substring = fn : string * int * int -> string val sub = : string * int -> char val str = fn : char -> string val size = : string -> int val maxLen = 33554431 : int val isPrefix = fn : string -> string -> bool val implode = fn : char list -> string val fromString = fn : string -> string option val fields = fn : (char -> bool) -> string -> string list val explode = fn : string -> char list val concat = fn : string list -> string val compare = fn : string * string -> order val collate = fn : (char * char -> order) -> string * string -> order val ^ = fn : string * string -> string Error: Compiler bug: PPDec.getVal - Comments: This is an interesting bug, because "open String List IO Bool" still works, or even "open String List" and "open IO Bool Real". The error message is printed out from print/ppdec.sml complaining about the non-LVAR and non-INLINE access of some program identifiers. [dbm - check this] Owner: dbm, Zhong Test: bug828.sml Status: fixed in 109.26 (or earlier) ---------------------------------------------------------------------- Number: 829 Title: Division does not work right on negative integers Keywords: Submitter: Andrzej Filinski Date: 11/9/93 System(s) and Version: Compiler SML/NJ Version: 1.01 (16 September 1993) Machine: all Severity: major Problem: Division does not work right on negative integers Transcript: - ~10 div 10; val it = ~2 : int -- should be ~1 - ~10 mod 10; val it = 10 : int -- should be 0 Comments: Possibly confusion div/quot in inlining Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 830 Title: error in makeml -- Solaris option Keywords: Submitter: Lal George Date: 11/5/93 Version: 1.01 System: Solaris 2.x Severity: major Problem: The runtime system files have SOLARIS changes, however, the makeml script is in error. In 101/src/makeml, the SOLARIS operating system is an option of -m68, instead of -sun4. Fix: The following lines: solaris|sunos5) MAKE=/usr/ccs/bin/make AS=/usr/ccs/bin/as CPP=/usr/ccs/lib/cpp DEFS="$DEFS -DSUNOS" OPSYS=SOLARIS ;; should be deleted as an operationg system option for the m68 and added to -sun4. See the file /usr/local/sml/SOLARIS/src98/makeml. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 831 Title: document Solaris option Keywords: Submitter: John R. Durand (jrd@galileo.ebt.com) Date: 11/9/93 Version: 1.01 System: Solaris Severity: major Problem: you might want to update the README file and the Release Notes to reflect this fact. the README file does not mention that Solaris is supported. also, the Release Notes don't mention the Solrais 2.x support or the tar file and the man page for makeml does not mention "-sun4 solairs" as a valid option. an interesting fact is that the manual that is included in the doc subdirectory does have a correct man page for makeml that lists "solaris" as a valid option. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 832 Title: parse phase stats always 0 Keywords: Submitter: Lal George Date: 12/6/93 Version: 1.01 System: all Severity: minor Problem: I have tried compiling small and big files, and the "010 Parse" time always seems to be 0.0. Is this correct? As far as I can tell the meaning of parse has not changed, and the parse phase in 0.93 takes about 2s for simple. Below is the summary for simple. ------------- Code Size 174076 Source Lines 925 Compiler 004 UnPickle 0.0u 0.0s 0.0g Compiler 010 Parse 0.0u 0.0s 0.0g Compiler 030 Elaborate 4.010000u 0.0s 0.740000g ... Fix: (Andrew Appel) In build/compile.sml, insert after line 41: val parser = Stats.doPhase parsePhase parser Then delete this line: val parseOne = Stats.doPhase parsePhase parseOne Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 833 Title: Compiler bug: getSymbols Keywords: Submitter: Bernd Fischer (fisch@ips.cs.tu-bs.de) Date: 11/25/93 SML/NJ Version: <0.93> Machine: SUN Sparcstation ELC, SunOS 4.1.1 Severity: major Problem: Well, ..., a functor which is passed as a parameter to another functor cannot find the appropriate names when applied to some other parameters. Transcript: - use "SIGMA.sml"; ... val it = () : unit - use "BR_SIGMA.sml"; ... val it = () : unit - use "BR_Sigma.sml"; [opening BR_Sigma.sml] structure BR_Sigma : BR_SIGMA val it = () : unit - use "NAME_GEN.sml"; ... val it = () : unit - use "Name_Gen.sml"; [opening Name_Gen.sml] structure Name_Gen : NAME_GEN val it = () : unit - use "TERM_FUNCTOR.sml"; [opening TERM_FUNCTOR.sml] ... val it = () : unit - use "Term.sml"; [opening Term.sml] functor Term : val it = () : unit - structure br_term = Term( structure s = BR_Sigma and n = Name_Gen); ... - use "Scanner.sml"; [opening Scanner.sml] ... - structure br_scan = Scanner( structure s = BR_Sigma ); ... - use "SCANNER_FUNCTOR.sml"; [opening SCANNER_FUNCTOR.sml] ... use "Term.sml"; functor Term : val it = () : unit - functor br_curry_parser = Parser( functor t = Term ); functor br_curry_parser : - functor br_lex_curry_parser = br_curry_parser( functor lex = Scanner ); functor br_lex_curry_parser : - structure br_parser = br_lex_curry_parser( structure s = BR_Sigma and n = Name_Gen ); structure br_parser : sig structure s_term : ... end - open br_parser; open br_parser structure s_term : ... - open s_term; Error: Compiler bug: getSymbols Code: /usr/local/sml/bugs/833 Comments: Perhaps the compiler gets lost between the same names in different scopes: > functor Parser ( functor t : TERM_FUNCTOR ) > ( functor lex : SCANNER_FUNCTOR ) > ( structure s : SIGMA > structure n : NAME_GEN ) = > struct > structure s_term = t(structure s = s and n = n) > end > funsig TERM_FUNCTOR ( structure s : SIGMA > structure n : NAME_GEN ) = > sig > ... > end Fix: (Pierre Cregut) Here is a reduced version of the program producing the bug: signature s = sig datatype dt = foo end functor i(X:s) = X; structure a = struct datatype dt = foo end functor r(functor f(x:s):s) (y:s)= struct structure c = f(y) end; functor p = r(functor f =i); structure b = p(a); open b; open c; The fix is changing getSymbols in elaborate/elabstr.sml. The case where the opened structure came from a functor application with an APP constructor wasn't treated: fun getSymbols(SIMPLE{env,...}) = let val r = ref([]: Symbol.symbol list) in Env.app (fn (s,_) => r := s::(!r)) env; !r end | getSymbols(INSTANCE{sign=SIG{symbols,...},...}) = !symbo ls | getSymbols ERROR_STR = [] (* forgotten -> *) | getSymbols (APPLY{res,...}) = getSymbols res | getSymbols _ = ErrorMsg.impossible "getSymbols" Status: fixed in 106 ---------------------------------------------------------------------- Number: 834 Title: accepts duplicate names in funsig parameters Keywords: Submitter: Philip Santas (santas@inf.ethz.ch) Date: 1/5/94 Version: Standard ML of New Jersey, Version 0.93, February 15, 1993 Machine: Sparc (all?) Severity: major Problem: duplicate use of parameter name in funsig definition is accepted. It prefers the second occurence of the name. Comments: The same happens for functors. Code: funsig S1 (T:sig end) (T:sig type t end) = sig val x:T.t end functor F1(T:sig end) (T:sig type t end) = struct type t = T.t end Transcript: - funsig S1 (structure T:sig end structure T:sig end) = sig end; std_in:0.0 Error: duplicate specifications for structure T in signature - funsig S1 (T:sig end) (T:sig end) = sig end; funsig S1(T:) = sig functor : end - funsig S1 (T:sig end) (T:sig type t end) = sig val x:T.t end; funsig S1(T:) = sig functor : end - funsig S1 (T:sig type t end) (T:sig end) = sig val x:T.t end; std_in:0.0-0.0 Error: unbound type constructor: t in path ..t - functor F1(structure T:sig end structure T:sig end) = struct end; std_in:39.48 Error: duplicate specifications for structure T in signature - functor F1(T:sig end) (T:sig end) = struct end; functor F1 : - functor F1(T:sig end) (T:sig type t end) = struct type t = T.t end; functor F1 : - functor F1(T:sig type t end) (T:sig end) = struct type t = T.t end; std_in:38.61-38.63 Error: unbound type constructor: t in path T.t Comment [dbm, 11/7/96] This is not a bug, just normal shadowing of bindings. Works just like "fn x: int => fn x: string => x ^ "a"" Test: bug834.sml Owner: dbm Status: not a bug ---------------------------------------------------------------------- Number: 835 Title: large comments parse slowly Keywords: Submitter: Morten Welinder (Referencing Kristian Nielsen ) Date: 1/10/94 System(s) and Version: ? (Field not understood.) SML/NJ Version: 0.93 Machine: hp9000s700 under hpux; sun4 under sunos Severity: major Problem: Large comments make sml use enormous amounts of memory, and take forever to parse. Code: A file containing "(*\n" and the 10000 lines each consisting of 70 "x"s. Comments: The parsing cannot be interrupted by C-c since sml will almost immediately go into garbage collecting. Transscript (sml killed by kill -9 xxxx): Yes, Sally? sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "ttt.sml"; [opening ttt.sml] [Major collection... [Increasing heap to 2986k] [Increasing heap to 4246k] [Increasing heap to 10546k] 96% used (2174736/2255004), 1970 msec] [Increasing heap to 10962k] [Major collection... [Increasing heap to 14782k] 91% used (6173796/6731560), 6120 msec] [Increasing heap to 19714k] [Major collection... 89% used (9495912/10664996), 9609 msec] [Increasing heap to 31246k] [Major collection...Killed Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 836 Title: no integer overflow, change in exception behavior Keywords: Submitter: Markus Bleicher, bleicher@informatik.uni-muenchen.de Date: 1/19/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: HPPA/HP-UX 9.01 Severity: minor Problem: No Integer Overflow Code: - val a=1111111111; Transcript: val a = ~1036372537 : int - val b=1.0/0.0; uncaught exception Div - val a=1111111111; uncaught exception Div Comments: There are some more exceptions changing the behavior. Owner: Test: bug836.1.sml, bug836.2.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 837 Title: exception handlers and / don't work together Keywords: Submitter: Markus Bleicher, bleicher@informatik.uni-muenchen.de Date: 1/19/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: HPPA/HP-UX 9.01 Severity: minor Problem: exception handlers and / work not together Code: exception NoInverse; fun finv (x,y) = x/y; val vinv = op /; fun h f x = f(x) handle _ => raise NoInverse; Transcript: - [opening /tmp/sml.tmp.g01926] exception NoInverse val finv = fn : real * real -> real val vinv = : real * real -> real val h = fn : ('a -> 'b) -> 'a -> 'b val it = () : unit - h vinv (1.0,0.0); uncaught exception NoInverse - h finv (1.0,0.0); uncaught exception NoInverse - h op / (1.0,0.0); uncaught exception NoInverse No problem until here...- vinv(1.0,0.0) handle _ => raise NoInverse; bug => uncaught exception Div - finv(1.0,0.0) handle _ => raise NoInverse; uncaught exception NoInverse - 1.0/0.0 handle _ => raise NoInverse; bug => uncaught exception Div Comments: No problems with other functions. Owner: Test: bug837.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 838 Title: Compiler bug: inststr, pos = 15 Keywords: Submitter: Rod Moten Date: 1/19/94 Version: 1.02 System: sparc-SunOS Severity: major Problem: When trying to compile a functor which takes three arguments, one functor and two structures, the following message is reported "Error: Compiler bug: inststr, pos = 15". Code: The error occurs when trying the functor with the heading below. functor ProofManager (functor TTree :TTREE structure ThmProverEng :THM_PROVER_ENG structure CompUnitLib :COMP_UNIT_LIB ): PROOF_MANAGER Is has the functor signature funsig PROOF_MANAGER (structure ThmProverEng :THM_PROVER_ENG functor TTree : TTREE structure CompUnitLib :COMP_UNIT_LIB) = PROOF_MANAGER The functor signature TTREE is given below. funsig TTREE (structure ThmProver :THM_PROVER) = TTREE Transcript: Comments: If need I could send more code upon request. Owner: dbm Status: not reproducible, probably obsolete ---------------------------------------------------------------------- Number: 839 Title: wrong type for install_pp Keywords: Submitter: John Reppy (jhr@research.att.com) Date: 1/23/94 System(s) and Version: Compiler SML/NJ Version: 1.01, pre 1.02 Machine: any Severity: major Problem: The interface for installing pretty-printers (Compiler.PPTable) is val install_pp : string list -> (ppstream -> object -> unit) -> unit instead of val install_pp : string list -> (ppstream -> 'a -> unit) -> unit which makes it hard to use. Code: Transcript: [compiling install-pp.sml] install-pp.sml:9.1-9.51 Error: operator and operand don't agree (tycon mismatch) operator domain: ?.PrettyPrint.ppstream -> System.Unsafe.object -> unit operand: ?.PrettyPrint.ppstream -> ?.Absyn.program -> unit in expression: install "Absyn" :: "program" :: nil ppPrgm Comments: Fix: The fix, which I'm putting into 1.02, is to make the PPTable signature in build/viscomp.sml be the polymorphic one, and to cast the binding. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 840 Title: nonprintable characters allowed in string literals Keywords: Submitter: John Reppy (jhr@research.att.com) Date: 1/26/94 System(s) and Version: Compiler SML/NJ Version: 1.03 and earlier Machine: all Severity: minor Problem: The Definition requires that the characters of a string literal be printable, but SML/NJ doesn't enforce this. Code: Transcript: Standard ML of New Jersey, Version 1.02, December 23, 1993 - " "; val it = "\t" : string Comments: Note that tabs should be allowed between \ ... \. Fix: change ml.lex Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 841 Title: System.PrettyPrint.mk_ppstream in stand-alone programs Keywords: Submitter: Klaus Elmquist Nielsen (klaus@tdr.dk) Date: 1/28/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: sparc/SunOS 4.1.3, mipsl/Ultrix 4.2A Severity: critical (for me!) Problem: If System.PrettyPrint.mk_ppstream is called from a standalone program, it will raise an exception named UNDEFINED. Code: fun olsen _ = (System.PrettyPrint.mk_ppstream {consumer = fn s => output (std_out, s), flush = fn () => flush_out std_out, linewidth = 79}; ()) val _ = exportFn ("abc",olsen) Transcript: % sml < ppbug.sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - = [Major collection... 3% used (17508/579348), 10 msec] [Decreasing heap to 98k] [Major collection... 94% used (18492/19648), 10 msec] % ./abc [Increasing heap to 162k] uncaught exception UNDEFINED % sml-noshare < ppbug.sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - = [Major collection... 15% used (595524/3906292), 80 msec] [Decreasing heap to 2934k] [Major collection... 40% used (243924/600300), 40 msec] [Decreasing heap to 1194k] % ./abc uncaught exception UNDEFINED Comments: I guess the UNDEFINED exception is the one from System.Hooks (src/boot/perv.sml). The consequence of this bug is that it is not possible to use the prettyprinter in a stand-alone program. An example of such a program is the compiler I am working on for the moment, as it writes its output using the prettyprinter. The prettyprinter works fine in an interactive system. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 842 Title: sharing constraints in functor sig Keywords: Submitter: Philip Santas Date: 1/31/94 Version: 0.93 System: SPARC Severity: major Problem: Bogus type sharing constraints accepted in result sig of functor sig. Code: - funsig S1 (type t sharing type t=string)= sig sharing type t = int type t end; funsig S1(:) = sig type t sharing type ..t = int end Comments: It seems to me that the body of S1 should report an error at sharing type t = int for two reasons: (a) type t in the argument equals to string (b) even if (a) was not true, we add constraints on the parameter in the result signature. Comment [dbm]: This code will be illegal (nonflexible sharing) in SML96. Must check that proper error message is generated. Owner: dbm Test: bug842.sml Status: obsolete ---------------------------------------------------------------------- Number: 843 Title: "ppDec raised exception" during bootstrapping Keywords: Submitter: John Reppy Date: 2/3/94 Version: 1.03 System: ? Severity: minor Problem: I noticed that when I use the -elab option to boot 1.03, I occasionally get the message "ppDec raised exception". Is this a bug? Here is a partial transcript: Transcript: ... [Elaborating boot/openio.sml] open IO exception Io = Io ppDec raised exception [Elaborating boot/makestring.sml] structure Makestring : MAKESTRING [Elaborating boot/print.sml] structure Print : PRINT [Elaborating boot/printol.sml] overload overload [Elaborating boot/weak.sml] structure Weak : WEAK structure Susp : SUSP [Elaborating boot/export.sml] structure Export : EXPORT [Elaborating boot/openexport.sml] ppDec raised exception Status: not a bug ---------------------------------------------------------------------- Number: 844 Title: callgc.c problems Keywords: Submitter: Soren Christensen (schristensen@daimi.aau.dk) Date: 2/3/94 Version: 0.93 System: ? Severity: Problem: schristensen@daimi.aau.dk (Soren Christensen) Subject: Two problems in callgc for 0.93 Cc: andreas@metasoft.com Hi, We have discovered two problems callgc.c for 0.93. 1) lastbreak should allways be alligned - this is vital for the increase_heapsize function, i.e., add the following line in restart_gc: lastbreak = (lastbreak + pagesize-1 ) & ~(pagesize-1); just below: resettimers(); lastbreak = EDATA; 2) there can be a overflow in increase_heapsize when calculating: p = (lastbreak+(p-pagesize))/2; this can be fixed by defining p to be unsigned: unsigned int p = arenabase+new_size; Both of these errors were discovered when running on a HPPA, the NJsml process would loop during startup if to little memory was available. Status: not important --- obsolete ---------------------------------------------------------------------- Number: 845 Title: local in signatures not reported as error Keywords: Submitter: Philip Santas Date: 2/3/94 Version: 0.93 System: SPARC Severity: minor Problem: Some functions defined in structures with a type which involves signatures with local specs cause Bus error. Code: Transcript: vinci.inf.ethz.ch46 Philip > sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - signature S = sig local structure A: sig type t end in val make: int -> A.t val destr: A.t -> int val add: A.t -> A.t -> A.t end end; std_in:3.3-8.6 Warning: LOCAL specs are only partially implemented signature S = sig val make : int -> A.t val destr : A.t -> int val add : A.t -> A.t -> A.t end - structure M1: S = struct local structure A = struct type t=int end in fun make(x:int) = x fun destr x = x fun add (x:int) y = x+y end end; structure M1 : S - open M1; open M1 val make = fn : int -> _ val destr = fn : _ -> int val add = fn : _ -> _ -> _ - val x1=make 3; val x1 = - : 'a - add x1 x1; Bus error Comment: [dbm] This should be detected and reported as a syntax error. Fix: eliminated rules for local and open forms of spec from grammar and eliminated LocalSpec and OpenSpec constructors from Ast. Owner: dbm Test: bug845.sml Status: fixed in 109.19m [by eliminating local from spec syntax] ---------------------------------------------------------------------- Number: 846 Title: endless compilation Keywords: Submitter: Kristian Nielsen (bombadil@diku.dk) Date: 2/8/94 System(s) and Version: SML/NJ with Eddingburg library SML/NJ Version: 0.93 (February 15, 1993) Machine: HP-PA/HPUX and sun4/SunOS. Severity: major Problem: Attempting to compile a machine-generated ML program of about 40 Kb does not terminate (or takes unreasonably long; several hours or more). Apparently the compiler either enters an infinite loop, or it attempts an optimization that is too expensive. The compiler does not increase its heap usage in any significant way, though it does perform major collections from time to time. After setting the flag - SML_NJ.Control.interp := true; the program is interpreted fine by SML/NJ. Code: Unfortunately, it appears very hard to extract a short example that reproduces the bug (being large and machine-generated, the program is very hard to read). The program is the output of the partial evaluator ML-MIX and is a specialized quicksort program. A smaller version of the same program does not exhibit any problem. Since the program is 40Kb (70Kb for a pretty-printed version), it is not included here (I am not going to flood your bugreport list unless you ask me to!). I will be happy to send it along if desired, of course. Would it be helpful to have the example (to reproduce the behaviour) even though it is not readable by humans? Transcript: - use "../../exp/quicksort/3specex2.sml"; [opening ../../exp/quicksort/3specex2.sml] [Major collection... 60% used (13621052/22644044), 3800 msec] [Major collection... 61% used (13958948/22550444), 3367 msec] (* This can go on for hours ... *) Interrupt Comment: [Appel] I put in a simple adjustment to the minimum-feedback-vertex-set algorithm that still guarantees optimality (so programs will have few heap limit checks) and yet runs very fast on this kind of input. There still could be functions on which the m-f-v-s algorithm runs exponentially slowly, however; but the kind shown in bug 846 (with lots of cycles of length 1) will not be a problem. [later...] On any real program (including the one in bug 846) the algorithm runs fast and produces optimal results. On artificial examples (20-node flow-graph, each node points to all the others but not to itself) program runs in N^k time and produces possibly sub-optimal results. I have chosen k=3. Previously, on artificial examples it could take N^N time. Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 847 Title: opening structures with variables conflicting with constructors Keywords: Submitter: Philip Santas Date: 2/21/94 Version: 0.93 System: SPARC Severity: major Problem: Opening a structure returns errors if it exports constants with the same name as some already defined constructors. Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - structure M: sig type t val D:t end = struct type t = int val D = 4 end; structure M : sig eqtype t val D : t end - datatype t = D; datatype t con D : t - open M; std_in:4.1-4.6 Error: pattern and expression in val dec don't agree (tycon mismatch) pattern: t expression: M.t in declaration: D = D Comment: same as 788 Status: fixed in 109.27 [dbm, 4/4/97] ---------------------------------------------------------------------- Number: 848 Title: realarray on HP Keywords: Submitter: Michael Lauer (mlauer@mechmail.cv.com) Date: 2/23/94 SML/NJ Version: 0.93 Machine: HP 715, HPUX 9.03 Problem: realarray crashes after lots of disk-hitting Code: see transcript Transcript: mrtoad 74: sml Standard ML of New Jersey, Version 0.93, February 15, 1993 Beta release version val it = () : unit - open RealArray; open RealArray exception RealSubscript = RealSubscript val array = fn : int * real -> realarray val length = : realarray -> int exception Size = Size val sub = : realarray * int -> real val update = : realarray * int * real -> unit - val foo = array (10, 1.0); Bus error (core dumped) Owner: Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 849 Title: sml-sg dumps core on RS/6000 Keywords: Submitter: Roland Olsson Date: 2/28/94 System(s) and Version: sml-sg SML/NJ Version: 0.93 Machine: IBM RS6000 model 980. AIX 3.2. Severity: critical Problem: The message "Illegal instruction (core dumped)" appears at "random". The most easily reproducible situation that gives a core dump is when .bin files are read. When the .bin files are removed and produced on the fly, things work fine for a little while longer, but the core dump comes eventually. The same application runs just fine on SparcStations and DECStations. Transcript: Script command is started on Mon Feb 28 12:04:21 GMT 1994.bluemaster>sml-sg Standard ML of New Jersey, Version 0.93, February 15, 1993 with SourceGroup 3.0 built on Mon Feb 28 11:41:14 GMT 1994 val it = () : unit - use "Makefile"; [opening Makefile] /use/rs1a/u1/olsson/lib/lib-base-sig.sml /use/rs1a/u1/olsson/lib/lib-base.sml /use/rs1a/u1/olsson/lib/random-sig.sml /use/rs1a/u1/olsson/lib/random.sml /use/rs1a/u1/olsson/lib/string-cvt-sig.sml /use/rs1a/u1/olsson/lib/string-cvt.sml /use/rs1a/u1/olsson/lib/hash-string.sml /use/rs1a/u1/olsson/lib/hash-key-sig.sml /use/rs1a/u1/olsson/lib/hash-table-sig.sml /use/rs1a/u1/olsson/lib/hash-table.sml /use/rs1a/u1/olsson/lib/static-array-sig.sml /use/rs1a/u1/olsson/lib/dynamic-array-sig.sml /use/rs1a/u1/olsson/lib/dynamic-array.sml /use/rs1a/u1/olsson/lib/time-limit.sml /use/rs1a/u1/olsson/my-lib/lib.sml base.sml ML.grm.sig ML.grm.sml ML.lex.sml predefined.sml ast.sml ast_lib.sml io.sml type.sml execute.sml [Major collection... [Increasing heap to 9688k] 28% used (2072432/7222288), 400 msec] [Increasing heap to 11332k] sort_spec.sml evaluate.sml exp_synt.sml bst_ins_spec.sml rev_spec.sml synt_lib.sml test_programs.sml atomic_trf_synt.sml case_dist.sml emb.sml compound_trf_synt.sml genealogical_search.sml ML.lex ML.grm val Home = "/use/rs1a/u1/olsson" : string val Lib = "/use/rs1a/u1/olsson/lib" : string val My_lib = "/use/rs1a/u1/olsson/my-lib" : string val Lib_files = ["lib-base-sig.sml","lib-base.sml","random-sig.sml","random.sml", "string-cvt-sig.sml","string-cvt.sml","hash-string.sml","hash-key-sig.sml", "hash-table-sig.sml","hash-table.sml","static-array-sig.sml", "dynamic-array-sig.sml",...] : string list val Lib_files = ["/use/rs1a/u1/olsson/lib/lib-base-sig.sml", "/use/rs1a/u1/olsson/lib/lib-base.sml", "/use/rs1a/u1/olsson/lib/random-sig.sml", "/use/rs1a/u1/olsson/lib/random.sml", "/use/rs1a/u1/olsson/lib/string-cvt-sig.sml", "/use/rs1a/u1/olsson/lib/string-cvt.sml", "/use/rs1a/u1/olsson/lib/hash-string.sml", "/use/rs1a/u1/olsson/lib/hash-key-sig.sml", "/use/rs1a/u1/olsson/lib/hash-table-sig.sml", "/use/rs1a/u1/olsson/lib/hash-table.sml", "/use/rs1a/u1/olsson/lib/static-array-sig.sml", "/use/rs1a/u1/olsson/lib/dynamic-array-sig.sml",...] : string list val group = 1 : ?.group val it = () : unit - use "make.sml"; [opening make.sml] val it = () : unit val it = () : unit [reading base.sml.bin] [reading /use/rs1a/u1/olsson/lib/hash-key-sig.sml.bin] Illegal instruction (core dumped) bluemaster>exit exit Script command is complete on Mon Feb 28 12:05:06 GMT 1994. Script command is complete on Mon Feb 28 12:05:06 GMT 1994. Comments: I transferred fresh copies of the entire sml-nj system from research.att.com, but this didn't change the problem. The system was built with the command "makeml -g -rs6000 aix". Owner: lal Status: obsolete ---------------------------------------------------------------------- Number: 850 Title: redefining nil breaks [] Keywords: Submitter: Pierre Cregut (cregut@LANNION.cnet.fr) Date: 3/3/94 Version: 0.93 Severity: minor Problem: At the level of Ast, identifiers stand for either variables or constructors. In particular, the identifier "nil" could be either a variable or constructor. [] is just an abbreviation for nil. Thus if I redefine nil, then I have changed the meaning of [] as well. Code: Transcript: - datatype t = nil; datatype t con nil : t - 1::[]; std_in:4.1-4.5 Error: operator and operand don't agree (tycon mismatch) operator domain: int * int list operand: int * t in expression: :: (1,nil) Fix: [Pierre Cregut, 3/3/94] In prim.sml: ("nil", nilDcon), ("cons::", consDcon), ("nil[]", nilDcon), In astutil.sml: val nilDcon = [varSymbol "nil[]"] val consDcon = [varSymbol "cons::"] This is invisible to the user and is much more resistant (you can still break it by giving a parse tree to the compiler but this is a very weird kind of use, I don't feel necessary to find a defense against it). Comment: According to The Definition of Standard ML, this is the right behavior. However, the Definition is silly. Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 851 Title: bogus "op" warnings Keywords: Submitter: Morten Welinder (terra@diku.dk) Date: 2/2/94 System(s) and Version: sml-nj SML/NJ Version: 0.93 Machine: irrelevant (sun4) Severity: minor Problem: bogus warnings about `op' Code: structure S = struct datatype tree = ADDI of tree*tree | ADDRLP | ASGNI of tree*tree | CNSTI | CVCI of tree | I0I | INDIRC of tree; datatype foo * rule = stmt_ASGNI_disp_reg of (foo * rule * tree) * (foo * rule * tree) | stmt_reg of (foo * rule * tree) | reg_ADDI_reg_rc of (foo * rule * tree) * (foo * rule * tree) | reg_CVCI_INDIRC_disp of (foo * rule * tree) | reg_IOI | reg_disp of (foo * rule * tree) | disp_ADDI_reg_con of (foo * rule * tree) * (foo * rule * tree) | disp_ADDRLP | rc_con of (foo * rule * tree) | rec_reg of (foo * rule * tree) | con_CNSTI | con_IOI withtype foo = int Array.array end; Transcript: - use "bug.sml"; [opening bug.sml] bug.sml:11.16 Warning: unnecessary `op' bug.sml:11.16 Warning: unnecessary `op' bug.sml:11.16 Warning: unnecessary `op' bug.sml:11.16 Warning: unnecessary `op' bug.sml:11.16 Error: syntax error found at ASTERISK - Comments: I grog the error message, but the warnings... This strange behaviour goes away if `structure' is removed or if the correct datatype is removed. FYI, the above came as a result of a search-and- replace command. Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 852 Title: include merging types Keywords: Submitter: Philip Santas Date: 2/25/94 Version: 0.93 Severity: major Problem: The following is allowed: signature AM = sig type R val plus:R->R->R and zero:R end signature MM = sig type R val times:R->R->R and one:R end signature S1 = sig include AM MM end; structure M:S1 = struct type R=int fun plus(x:int)y=x+y val zero=0 val one=1 fun times(x:int)y=x*y end; but this is not allowed: signature S1 = sig include AM type R end; Owner: dbm Status: open ---------------------------------------------------------------------- Number: 853 Title: exportML under Ultrix 4.3 Keywords: Submitter: Josh Pritikin Date: 2/12/94 SML/NJ Version: 0.93 Machine: Decstation, ULTRIX 4.3 Severity: critical Problem: can't exportML SML Code: src/makeml -decstation ultrix Transcript: see following --- [Loading boot/overloads.sml] structure Overloads : ... Go for it - [Major collection... 10% used (556732/5342920), 535 msec] [Decreasing heap to 2743k] [Major collection... 99% used (560944/561408), 511 msec] ==> Inconsistent object for export: !(sh->s_scnptr == headersize) uncaught exception Io "exportML "sml": Not a typewriter" --- Also, the /lib/cpp on my machine thinks that $'s are part of identifiers. This breaks prim.s. The work around I used was to use gcc's cpp with the -$ switch. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 854 Title: excessive spilling with large let expressions Keywords: Submitter: Kristian Nielsen (bombadil@diku.dk) Date: 2/14/94 System(s) and Version: SML/NJ with eddingburgh library SML/NJ Version: 0.93 Machine: sun4 /SunOS Severity: minor Problem: The SML/NJ compiler appears to handle (very) large let expressions (ie. let expressions containing many bindings) inefficiently. Comment: Lal is working on an improved spiller. Owner: lal Status: open ---------------------------------------------------------------------- Number: 855 Title: sharing in signatures Keywords: modules, signatures, sharing Submitter: Philip Santas Date: 2/19/94 Version: 0.93 Severity: major Problem: Some time ago, we were discussing if sharing constraints that identify the parameter structures T1 and T2 should be in the result signature or in the parameter signature. Now, the following behaviour puzzles me (once again): - signature C1 = sig type R val foo : R -> R end; - funsig Soo(structure T1:C1 structure T2:sig include C1 end)= = sig include C1 sharing T1 = T2 end; funsig Soo(:) = sig type R val foo : R -> R sharing ..T2 = ..T1 end Here the result signature includes sharings. And here comes again the example which started this query in the past: - functor Foo(structure T1:C1 structure T2:sig include C1 end): = sig include C1 sharing T1 = T2 end = = struct type R = T2.R val foo = T1.foo end; std_in:6.33-6.39 Error: definitional sharing constraint T1 = T2 can never be satisfied where the result signature should not include constraints on the arguments. Now, the interesting comes here: - functor Foo(structure T1:C1 structure T2:sig include C1 end sharing T1=T2): sig include C1 sharing T1 = T2 end = struct type R = T2.R val foo = T1.foo end; functor Foo : This is fine, since the sharing is propagated. (in a similar case we would have: - functor Goo(structure T1:C1): sig include C1 sharing T1 = T1 end = = struct type R = T1.R val foo = T1.foo end; functor Goo : The problem is that the type sharings are not propagated: - functor Foo(structure T1:C1 structure T2:sig include C1 sharing type R=T1.R end): sig include C1 sharing T1 = T2 end = struct type R = T2.R val foo = T1.foo end; = = = std_in:15.36-15.42 Error: definitional sharing constraint T1 = T2 can never be satisfied although this is accepted: - functor Foo(structure T1:C1 = structure T2:sig include C1 end = sharing T1=T2) = : sig sharing type T1.R = T2.R end = = struct type R = T2.R val foo = T1.foo end; functor Foo : Owner: dbm Status: obsolete ---------------------------------------------------------------------- Number: 856 Title: unique constructors not representationally transparent Keywords: Submitter: John Reppy Date: 2/22/94 Version: 1.02 Severity: major Problem: I was looking at the CPS produced by 1.02 for my 4x4 matrix code, and it seems that the datatype declaration datatype matrix = M of RealArray.realarray involves an extra level of indirection. This is supported by the fact that changing the representation to type matrix = RealArray.realarray saves 4uS per matrix multiplication (about 5%). I thought that declarations like this don't impose overhead! Comments: [Zhong Shao, 2/22/94] You can view this as a bug. When I was implementing the representation analysis, I put back an extra level of indirection even for transparent constructor to avoid extra boxing and unboxing operations (this is only true if you define datatype s = M of t where t is big record type). I'll fix this bug in my newer version of representation analysis code. [Lal, 10/28/99] Here is another instance of the bug: - datatype t = FOO of int; v86(v87[PV],v71[PV],v82[C],v83[PV],v84[PV],v85[PV],v73[PR1]) = v82(v82,v83,v84,v85,(I)0) datatype t = FOO of int - fun f(FOO 0) = 0 = | f(FOO i) = i+1; v53(v54[PV],v14[PV],v42[C],v43[PV],v44[PV],v45[PV],v21[PR2]) = {RK_ESCAPE 1,(L)v46} -> v63 {v63} -> v64 v42(v42,v43,v44,v45,v64) v46(v61[PV],v60[PV],v59[C],v58[PV],v57[PV],v56[PV],v55[PV]) = v55.0 -> v62[I] if i31<>((I)0,v62) [v33] then +i31(v62,(I)1) -> v15[I] v59(v59,v58,v57,v56,v15) else v59(v59,v58,v57,v56,(I)0) val f = fn : t -> int [Zhong, 10/29/99] Actually, anything other than int31 is supported correctly, for example, datatype t = FOO of int * int is represented as a pair without indirection. -Zhong PS. For those who know about the conreps, the single-constructor datatype is now represented as UNTAGGED; that is, datatype t = FOO of int is represented same as FOO in the following datatype: datatype t = FOO of int | BAR which has to box the FOO because BAR is represented using int31. Owner: Zhong Status: open ---------------------------------------------------------------------- Number: 857 Title: type error message points to wrong place Keywords: Submitter: John Reppy (jhr@research.att.com) Date: 3/6/94 System(s) and Version: Compiler SML/NJ Version: 1.02 Machine: any Severity: minor Problem: type errors in mutually recursive function bindings do not expose the source of the error, even when a type constraint is used. Code: fun f x = (h x)+0.1 (* this is the bug *) and g x = (h x)+1 and h (x) : int = 0; Transcript: Standard ML of New Jersey, Version 1.02, January 23, 1994 [SC 69a1] val it = () : unit - fun f x = (h x)+0.1 (* this is the bug *) = and g x = (h x)+1 = and h (x) : int = 0; std_in:5.13-5.19 Error: operator and operand don't agree (tycon mismatch) operator domain: real * real operand: real * int in expression: + : overloaded ((h x),1) std_in:4.3-6.21 Error: pattern and expression in val rec dec don't agree (tycon mismatch) pattern: 'Z -> real expression: 'Z -> int in declaration: h = (fn x => (0: int)) Comments: Note that errors were reported for the definition of both g and h, but not for f, which was the actual bug. Since h is constrained to have the return type of int, the use of h in f should be reported as an error. Test: bug857.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 858 Title: Compiler bug: DebugError:Static.locOfEvent bad APPev marking Keywords: Submitter: Fred C Yankowski (+1 708 979 5472, intgp1!fcy) Date: 3/9/94 Version: 0.93 System: sparc? Severity: major Problem: Compiler bug: DebugError:Static.locOfEvent bad APPev marking occurs during call of usedbg on iterative fibonacci. Code: [file itfib.ml, from "ML for the Working Programmer"] fun itfib (n, prev, curr) : int = if n=1 then curr else itfib(n-1, curr, prev+curr); fun fib2 (n) = itfib(n, 0, 1); Transcript: hrdcpy< ~gregg/bin/smld Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - usedbg "itfib.ml"; Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking - use "itfib.ml"; [opening itfib.ml] val itfib = fn : int * int * int -> int val fib2 = fn : int -> int val it = () : unit - fib2 5; val it = 5 : int Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 859 Title: bug 223 still open for HPPA Keywords: Submitter: Kristian Nielsen (bombadil@diku.dk) Date: 3/10/94 System(s) and Version: SML/NJ SML/NJ Version: 0.93 Machine: HPPA running HP-UX Severity: major Problem: Masterbug entry 223 ("nontty standard input and uncaught exceptions"), reported fixed for version 0.65, has not been fixed for the HPPA version of SML/NJ. Transcript: [128]narfe:~/smlmix/exp>rsh embla arch hp9000s700 [129]narfe:~/smlmix/exp>rsh embla sml Standard ML of New Jersey, Version 0.93, February 15, 1993 Beta release version val it = () : unit - foo; std_in:2.1-2.3 Error: unbound variable or constructor: foo uncaught exception (Loader): SystemCall [130]narfe:~/smlmix/exp>rsh embla sml Standard ML of New Jersey, Version 0.93, February 15, 1993 Beta release version val it = () : unit - set_term_in(std_in, true); val it = () : unit - foo; std_in:3.1-3.3 Error: unbound variable or constructor: foo uncaught exception (Loader): SystemCall [131]narfe:~/smlmix/exp>rsh garm arch sun4 [132]narfe:~/smlmix/exp>rsh garm sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - foo; std_in:2.1-2.3 Error: unbound variable or constructor: foo - Comments: The first two sml sessions are run on a HPPA machine (hp9000s700). They exhibit the same problem as the one reported in masterbugs entry 223. The second session shows that the fix given in masterbugs does not work. The third session is run on a sun4 machine. Here, the problem does not appear. [Lorenz, 4/4/97] bug 859 (aka 223) no longer manifests itself in 109.26: $ rsh islay "uname -a" HP-UX islay B.10.20 A 9000/778 2004213872 two-user license $ rsh islay /usr/local/sml/109.26/bin/sml Standard ML of New Jersey, Version 109.26, March 25, 1997 [new runtime] - foo; stdIn:7.1-7.4 Error: unbound variable or constructor: foo - ^D $ Owner: Lal Status: open ---------------------------------------------------------------------- Number: 860 Title: exception Subscript raised while compiling curried functors (same as 803?) Keywords: Submitter: Chris Okasaki Date: 3/16/94 System(s) and Version: Compiler SML/NJ Version: 1.02 Machine: DECstation 5000 running Mach Severity: minor/major Problem: exception Subscript raised while compiling curried functors Code: signature NUM = sig val n : int end functor LeftSection (structure A : NUM functor BinOp (structure A : NUM) (structure B : NUM) : NUM) (structure B : NUM) : NUM = struct structure Result = BinOp (structure A = A) (structure B = B) open Result end Transcript: cokasaki% sml Standard ML of New Jersey, Version 1.02z, 17 December 1993 [0.93 compatible] val it = () : unit - use "bug.sml"; (* contains the above code *) [opening simple.sml] uncaught exception Subscript - Comments: Problem goes away if the argument functor BinOp is uncurried, i.e. functor BinOp (structure A : NUM structure B : NUM) : NUM Status: fixed in 107 ---------------------------------------------------------------------- Number: 861 Title: won't build on NeXTSTEP/486 Keywords: Submitter: > Date: 3/15/94 System(s) and Version: gcc SML/NJ Version: 0.93 Machine: i486 & NeXTSTEP Severity: major Problem: It's imposible to compile sml for NeXTSTep on Intel Comments: I would realy like sml to run on our Intel-based NEXTSTEP machines. Fix: None yet. I have tried to adapt the sources. But aspecially export.c needs changes of internal sml-structures. ( Due to differences between mach/i386/thread_status.h and mach/m68k/thread_status.h its not posible to to make the following change) # ifdef NeXT_3_0 # ifdef I386 # include # define NeXT_THREAD_STATE_REGS i386_THREAD_STATE_REGS # define NeXT_THREAD_STATE_REGS_COUNT i386_THREAD_STATE_REGS_COUNT # define NeXT_thread_state_regs i386_thread_state_regs # else I386 # include # define NeXT_THREAD_STATE_REGS M68K_THREAD_STATE_REGS # define NeXT_THREAD_STATE_REGS_COUNT M68K_THREAD_STATE_REGS_COUNT # define NeXT_thread_state_regs m68k_thread_state_regs # endif # endif o i386_THREAD_STATE_REGS o i386_THREAD_STATE_REGS_COUNT o i386_thread_state_regs are not defined anymore. Owner: Status: obsolete [NextStep not currently supported.] ---------------------------------------------------------------------- Number: 862 Title: fun decl can create holes in contructor scope Keywords: Submitter: Jeff Lewis (jlewis@cse.ogi.edu) Date: 3/17/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: N/A Severity: minor Problem: Use of a `val rec' declaration can cause a `hole' in the scope of a value or exception constructor - i.e. you are correctly unable to redefine `nil' with a `val' decl, but you can with a `val rec'. See rule 4 in the middle of page 5 of the definition, and the subsequent elaboration in the following paragraph. The `fun' derived form also allows you to incorrectly redefine nil (although the phrase `ignoring derived forms' in the paragraph before the indicated set of rules makes interpretation of the standard harder, there is otherwise no indication of how to differently interpret the derived forms in this regard). Code: Neither of these should work, but do: val rec nil = fn x => x -- or -- fun nil x = x Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 863 Title: Compiler bug: PPObj.switch: none of the datacons matched Keywords: open, top level Submitter: Andrew Appel Date: 3/24/94 Version: 1.03f Severity: major Problem: Conflict of variables and constructors in top-level opens causes a compiler bug in PPVal. Code: Transcript: structure A = struct val p = 6 end structure B = struct val p = true end open B A Error: Compiler bug: PPObj.switch: none of the datacons matched Comment: same as bug 1000 Test: bug863.sml Owner: dbm, Zhong Status: fixed in 109.26 [Zhong] ---------------------------------------------------------------------- Number: 864 Title: Overflow is handled inconsisently (see also bug 786) Keywords: Submitter: Morten Welinder (terra@diku.dk) Date: 3/25/94 System(s) and Version: Compiler/Interpreter SML/NJ Version: 0.93 Machine: HP9000 model 735 running hpux (probably others, but with minor variations) Severity: minor Problem: Overflow is handled inconsisently Code: See transscript: Transcript: # sml Standard ML of New Jersey, Version 0.93, February 15, 1993 Beta release version val it = () : unit - 2147483648; val it = 0 : int (* That was 2^31 *) - 1073741824; std_in:9.1-9.10 Error: integer too large (* That was 2^30 *) - ~ (~1073741824); uncaught exception Overflow (* This is as expected, although the Definition has its own ideas about the exception to raise. *) - 32768 * 32768; val it = ~1073741824 : int (* No exception raised ??? *) val it = 1073741823 : int - 32768 * 32767 + 32768; uncaught exception Overflow (* Yet here one is! *) - ~1073741824 div ~1; uncaught exception Overflow (* And here. Appel suggested in earlier smlnj-docs that "div" should be able to raise Overflow and Div (for 1 div 0). FYI, it would be extremely difficult to differentiate those two situations on certain CPUs (like Intel 386). It would require disassembly of the offending instruction and actually checking the divisor. *) - ~1073741824 - 1; uncaught exception Overflow (* And here *) Comments: "*" doesn't seem to check for overflow. [DBM: may have been fixed, since bug 786 is listed as fixed in 1.02. But 786 is for mipsel/ultrix.] Owner: Lal Status: fixed in 109.25.x [Lal] ---------------------------------------------------------------------- Number: 865 Title: inference for flex record patterns Keywords: Submitter: John Reppy (jhr@research.att.com) Date: 3/28/94 System(s) and Version: Compiler SML/NJ Version: 1.04 Machine: any Severity: minor Problem: inference for flex record patterns is not aggressive enough Code: Transcript: - fun f (x : {a : int}) = let fun g x = #a x in g x end; stdIn:27.24-27.38 Error: unresolved flex record (can't tell what fields there are besides #a) - Comments: When a polymorphic function is used monomorphically, as in the above example, it would be nice if the type checker would figure it out. I suspect that this applies to overloading, as well. Owner: dbm Test: bug865.sml Status: not a bug ---------------------------------------------------------------------- Number: 866 Title: illegal withtypes accepted Keywords: Submitter: Appel Date: 4/7/94 Version: 0.93 System: any Severity: minor Problem: types within a withtype are erroneously allowed to refer to each other Code: datatype x=T withtype a=int and b=a; Transcript: datatype x con T : x type a = int type b = a Comments: This is not legal, according to the Definition; the definition of a should not be visible when b is defined. The "and" combinator should not sequence the environments, but should allow independent simultaneous definitions. Fix: Status: not a bug, a feature ---------------------------------------------------------------------- Number: 867 Title: compilation hangs in the pickler Keywords: Submitter: Gene Rollins Date: 3/28/94 Version: 1.02, also 107.7 with CM System: DECstation Severity: major Problem: SML/NJ 1.02 gets hung in the pickler for the following code: Code: signature SIG = sig type t end functor F (functor ID (S : SIG) : sig include SIG sharing type t = S.t end structure S : SIG) : SIG = struct structure S' = ID (S) open S' end or this simpler version (Andrew, 3/7/95) functor F (functor ID () : sig end) = struct end Transcript: To illustrate the problem place the above code in a file called "pickle-bug.sml". Then put the CompileFile structure, given below, into a file called "compile-file.sml". Then in an SML/NJ 1.02 image with SC, do this: use "compile-file.sml"; c.c(); Compilation should get hung after "compiler 5" is printed in the call to Pickle.pickleEnv. We only tried this on DecStations. A more complicated example appears in the SML distribution in "doc/examples/powerset.sml". The call c.compile "doc/examples/powerset.sml" should exhibit the same behavior as the call to c.c(). structure CompileFile :sig val compile :string -> unit val c :unit -> unit end = struct open SC structure CompiledUnit = Compiling.CompiledUnit structure StaticTable = CompiledUnit.StaticTable structure Env = Compiler.Environment structure Compile = Compiler.Compile structure Pid = Compiler.PersStamps structure ErrorMsg = Compiler.ErrorMsg structure Source = Compiler.Source structure Pickle = Compiler.PickleEnv structure Recorder = Compiler.Recorder structure Watcher = Compiler.Watcher structure Interrupt = Utilities.Interrupt structure IO_Stream = Utilities.IO_Stream structure Print = Compiler.Control.Print type environment = Env.environment type staticEnv = Env.staticEnv type dynenv = Env.dynenv type pid = Pid.persstamp type source = Source.inputSource type time = System.Timer.time type compiledUnit = CompiledUnit.compiledUnit type staticTable = StaticTable.staticTable val C = CompiledUnit.C val ST = StaticTable.ST val mkPid = Pid.stringToStamp val pid2string = Pid.stampToString exception Compile = Compile.Compile val staticPart = Env.staticPart val dynamicPart = Env.dynamicPart fun reading file = print ("[reading " ^ file ^ "]\n") fun writing file = print ("[writing " ^ file ^ "]\n") fun closing file = print ("[closing " ^ file ^ "]\n") fun check errs phase = if ErrorMsg.anyErrors errs then raise Compile (phase^ " failed") else () fun withSource (sourceName:string) (action :source -> 'a -> 'b) (argument:'a) : 'b = let val sourceStream = open_in sourceName val source = Source.newSource (sourceName, 1, sourceStream, false, {consumer = Print.say, flush = Print.flush, linewidth = !Print.linewidth}, NONE) val errors = ErrorMsg.errors source fun cleanup () = (Source.closeSource source; closing sourceName) val result = action source argument handle exn => (cleanup(); raise exn) in Source.closeSource source; cleanup(); result end val coreEnvRef = ref(!Env.coreEnvRef) fun compiler (source, StaticTable.ST{senv,ids}) :compiledUnit = let val _ = print "enter compiler\n" val errors = ErrorMsg.errors source val {ast,...} = Compile.parse {source=source,compenv=senv} val _ = print " compiler 1\n" val (recorder, tableRef) = Recorder.makeRecorder() val env' = Watcher.watch(senv,[],recorder) val _ = print " compiler 2\n" val {absyn,newenv,exports,exportLvars,staticPid} = Compile.elaborate{errors=errors, compenv=env', corenv= !coreEnvRef, transform = (fn x=>x), ast=ast} before check errors "elaboration" val _ = print " compiler 3\n" val {lambda,imports} = Compile.translate {errors=errors, absyn=absyn, corenv= !coreEnvRef, exportLvars = exportLvars, statenv = Env.layerStatic(newenv,env')} before check errors "translation" val _ = print " compiler 4\n" val code = Compile.codegen{errors=errors,lambda=lambda} before check errors "codegen" val _ = print " compiler 5\n" val pickledEnv = Pickle.pickleEnv{env=newenv,extern_table= !tableRef} val _ = print " compiler 6\n" in C {imports=imports, exports=exports, code=code, staticEnv=newenv, staticPid=staticPid, references=ids, pickled_env=pickledEnv} end val initialSE = Env.staticPart (!Env.pervasiveEnvRef) val initialST = ST {senv=initialSE, ids=[]} fun compile (sourceName:string) :unit = let val _ = reading sourceName fun comp source st = compiler (source, st) val compUnit = withSource sourceName comp initialST in print "compile Done\n" end fun c () = compile "pickle-bug.sml" end structure c = CompileFile Owner: Status: obsolete ---------------------------------------------------------------------- Number: 868 Title: "Compiler bug: distributeT: dist_abv" caused by type abbrev in sign Keywords: Submitter: Matthias Blume Date: 3/29/94 Version: 1.03f? System: ? Severity: major Problem: Compiler bug: distributeT: dist_abv Code: signature COMPILER = sig structure PersStamps : sig type persstamp = Compiler.PersStamps.persstamp end end; Code: (from Zhong Shao) functor F(S : sig type t = int end) = struct end; Transcript: - functor F(S : sig type t = int end) = struct end; Error: Compiler bug: distributeT: dist_abv Comments: The above code works fine if the signature definition is pulled out from the functor declaration, that is, if we define signature SIG = sig type t = int end then say functor F(S : SIG) = struct end everything works fine. Transcript: (from Kwang Yi, 10/18/94) - signature foo = = sig = structure A: sig type elmt = int end = end; Error: Compiler bug: distributeT: dist_abv Status: fixed in 107 (dbm, 11/30/94) ---------------------------------------------------------------------- Number: 869 Title: uncaught exception: Subscript -- compiling signature with type def Keywords: Submitter: Matthias Blume Date: 3/31/94 Version: 1.03f? System: ? Severity: major Problem: Code: signature S1 = sig structure A: sig type s end (* necessary, & must come before B *) structure B: sig type t end end; signature S2 = sig structure C: S1 type v = C.B.t end; Comments: It's a bit odd, because when I delete structure A from signature S1 or even when I just exchange it with structure B then I don't get this error. I wasn't able to locate the module where the exception is raised. Same as bug 906 [dbm]. Status: fixed in 107 (dbm) ---------------------------------------------------------------------- Number: 870 Title: error in documentation of revfold Keywords: Submitter: G. Ramalingam (rama@watson.ibm.com) Date: 4/20/94 System(s) and Version: Documentation SML/NJ Version: 0.93 Problem: The order of arguments in the example of revfold in page BASE-19 is wrong. The parameters for the innermost use of "f" appear in the correct order, but the parameters appear in the wrong order for all other uses of "f". Fix: Should read: f( l subscript |l|-1, f ( l subscript |l|-2, ... f( l subscript 0, z)...)) Owner: Status: obsolete ---------------------------------------------------------------------- Number: 871 Title: inaccurate error message Keywords: Submitter: John Reppy Date: 4/24/94 Version: 1.03f System: ? Severity: minor Problem: The following error message gets generated even when no functors are being used, so it shouldn't talk about the "functor formal parameter". interp.sml:6.11-431.5 Error: The constructor CONT of datatype next_state has different representations in the signature and the structure. Change the definition of the types carried by the constructors in the functor formal parameter and the functor actual parameter so that they are both abstract, or so that neither is abstract. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 872 Title: need more info in error message Keywords: error message Submitter: John Reppy Date: 5/2/94 Version: 1.03f Severity: minor Problem: The error message below should include the name of the constructor being rebound! Transcript: % sml Standard ML of New Jersey, Version 1.03f, April 11, 1994 - val rec nil = fn x => x; std_in:2.9-2.23 Error: rebinding data constructor as variable - fun nil(x) = x; std_in:0.0-0.0 Error: rebinding data constructor as variable - (Please ignore the bogus line numbers! That bug need not concern us here.) Comment: This is in response to Andrew's message about fixing bug 862. Status: fixed in 107.4 (plus) ---------------------------------------------------------------------- Number: 873 Title: faster nthtail suggested Keywords: Submitter: La Monte H. Yarroll Date: 4/26/94 System(s) and Version: SML/NJ 0.93 compiler SML/NJ Version: 0.93 Machine: SparcStation, SunOS 4.1.3 Severity: minor Problem: List.nthtail could be faster Code: val biglist = Iterate.iterate (fn l => 1::l) 10000 [1]; fun wrap cnt f arg = Iterate.iterate (fn n => (f arg;n)) cnt (); (* See below for faster nthtail. *) Transcript: - use "foo.sml"; [opening foo.sml] structure MyNth : sig val nthtail : 'a list * int -> 'a list end val it = () : unit - (timeit (wrap 100000 MyNth.nthtail) (biglist, 100),timeit (wrap 100000 List.nthtail) (biglist, 100)); val it = (" user: 1.660000 sys: 0.0 gc: 0.010000 wall: 2.002815 ", " user: 2.330000 sys: 0.0 gc: 0.0 wall: 4.323915 ") : string * string - Comments: I noticed that in the environment I run in pattern matching is much faster than recursion for dismantling lists. I assume that this is true in general for SML/NJ. This code is 20-30% faster than List.nthtail on getting a distant tail (e.g. 100) of a long list. There appears to be no degredation in performance for short lists. It may be even better than that. When I separately compile the code for nthtail it is about 80% slower than List.nthtail. I don't fully understand where this speed difference comes from, but it does not surprise me. I added levels of lookahead until the pattern matching appeared to cost more than it bought. This seems to happen at about n=13. However, above n=8 I noticed a bimodal behaviour in which sequential tests of nthtail could be 3-4 times slower. This appears particularly likely to happen if I recompile the same code again. This is really hard to reproduce, so I'm not making a formal bug report for it. I've been using user times as reported by timeit from TIMER(SYS). Fix: fun nthtail (e,0) = e | nthtail(_::r,1) = r | nthtail(_::_::r,2) = r | nthtail(_::_::_::r,3) = r | nthtail(_::_::_::_::r,4) = r | nthtail(_::_::_::_::_::r,5) = r | nthtail(_::_::_::_::_::_::r,6) = r | nthtail(_::_::_::_::_::_::_::r,7) = r | nthtail(_::_::_::_::_::_::_::_::r,8) = r | nthtail(_::_::_::_::_::_::_::_::r,n) = nthtail(r,n-8) | nthtail(_::_::_::_::_::_::_::r,n) = nthtail(r,n-7) | nthtail(_::_::_::_::_::_::r,n) = nthtail(r,n-6) | nthtail(_::_::_::_::_::r,n) = nthtail(r,n-5) | nthtail(_::_::_::_::r,n) = nthtail(r,n-4) | nthtail(_::_::_::r,n) = nthtail(r,n-3) | nthtail(_::_::r,n) = nthtail(r,n-2) | nthtail(e::r,n) = nthtail(r,n-1) | nthtail _ = raise List.NthTail Owner: John Status: not a bug (a suggestion) ---------------------------------------------------------------------- Number: 874 Title: scheduler improperly reording instructions Keywords: Submitter: John Reppy (jhr@research.att.com) Date: 4/26/94 System(s) and Version: Compiler SML/NJ Version: 0.93 - 1.04 Machine: SPARC Severity: major Problem: The scheduler seems to be reordering instructions on the SPARC in a way that violates sml exception semantics (which can cause an infinite loop). Code: (* this is an example of memoizing *) val f = let exception notFound fun lookup(a,[]) = raise notFound | lookup (a, (b,ans)::rest) = if a=b then ans else lookup(a,rest) val prev = ref [] fun g 0 = 1 | g ~1 = 0 | g ~2 = 0 | g n = (lookup(n,!prev) handle notFound => let val soln = g(n-3)+g(n-2)+g(n-1) in prev := (n,soln) :: !prev; soln end) in (g, prev) end Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "bug.sml"; [opening bug.sml] val f = fn : int -> int val prev = ref [] : (int * int) list ref val it = () : unit - (f 35); uncaught exception Overflow - length (!prev); Here it is in an infinite loop !! If you turn scheduling off, however, things work okay: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - System.Control.CG.scheduling := false; val it = () : unit - use "bug.sml"; [opening bug.sml] val f = fn : int -> int val prev = ref [] : (int * int) list ref val it = () : unit - (f 35); uncaught exception Overflow - length (!prev); val it = 34 : int - Comments: This bug was reported by Charlie Fischer. I'd guess that the problem is a missing dependency in the SPARC instruction description. I also tried it on a MIPS machine, and there was no problem, so I think that it is SPARC specific. Owner: Lal ? Test: bug874.sml Status: fixed in 109.31 [Lal, 8/18/97] ---------------------------------------------------------------------- Number: 875 Title: exception Nth while calling List.nth in interpreter Keywords: Submitter: Lorenz Huelsbergen (lorenz@research.att.com) Date: 5/6/94 Version: 1.03 (above 0.93) System: SGI Challenge, mipsb, irix 5.2 Severity: major Problem: calling supplied List.nth function with valid args while interpreting raises exception Nth. Code: Compiler.Control.interp := true; nth ([1,2,3],1); Transcript: Standard ML of New Jersey, Version 1.03, February 14, 1994 [new runtime] - Compiler.Control.interp := true; val it = () : unit - nth ([1,2,3],1); uncaught exception Nth - Comments: Works correctly on sparc, i386. Others untested. This is also a problem under 1.02, but it works under 0.93. This bug does not appear in a compiler built with representation analysis turned off (Compiler.Control.CG.representations := false). Owner: Status: obsolete [interpreter not currently supported] ---------------------------------------------------------------------- Number: 876 Title: uninformative type error message Keywords: error message Submitter: Charles Fischer Date: 5/12/94 Version: 1.03f? Severity: major Problem: The [type] error messages are often useless. Transcript: mr:4.1-7.8 Error: pattern and expression in val rec dec don't agree (tycon mismatch) pattern: ('Z * 'Z * 'Z -> 'Y) -> 'Z list -> 'Z expression: ('Z * 'Z * 'Z -> 'Y) * 'Z list -> 'Y in declaration: mR = (fn (f, :: ) => f (,,) | (f, :: ) => let val in () end) Comment: [jhr] I think that "mysterious" is more accurate; after all, this does tell you that you have a type mismatch. But I agree that we need to improve the messages. I'd also like to provide a summary of the error messages with examples of how they arise. Owner: dbm Status: open ---------------------------------------------------------------------- Number: 877 Title: System.Unsafe.blast_read raises the exception uncaught exception Ord Keywords: Submitter: Franz.Korf@arbi.informatik.uni-oldenburg.de Date: 5/17/94 System(s) and Version: SML/NJ Version: 0.93 Machine: SPARC 10 SunOS 4.1.3 Severity: major Problem: System.Unsafe.blast_read raises the exception uncaught exception Ord Code: The following example will show the problem to you: Step 1: Start sml (version 0.93) and execute the following code: ======= fun write2stream(filename, l : int list) = let val outstream = open_out(filename); in System.Unsafe.blast_write(outstream,l); close_out(outstream) end; val l = ref [1]; fun gen_list(i) = let val ri = ref i; in while (!ri > 0) do (l := !ri :: !l; ri := !ri -1) end; val _ = gen_list(3000000); write2stream("weg", !l); Step 2: Start sml (version 0.93) again and execute the following code: ======= fun read_from_stream(filename) = let val size = System.Unsafe.SysIO.fsize( System.Unsafe.SysIO.PATH(filename)); val instream = open_in(filename); val file_contents = System.Unsafe.blast_read(instream,size) : int list in close_in(instream); file_contents end; read_from_stream("weg"); The system will raise the exception : uncaught exception Ord Owner: John Status: obsolete [new runtime] ---------------------------------------------------------------------- Number: 878 Title: "Error: Compiler bug: getSymbols" compiling h.o. functor Keywords: Submitter: Alan Smaill, smaill@lfcs.ed.ac.uk Date: 5/21/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Sparc, Solaris Severity: minor Problem: Use of functor argument to functors needs more signature info than expected. Code: Extending the example from the documentation: signature MONOID = sig type t val plus: t * t -> t val e:t end; funsig PROD (structure M:MONOID and N:MONOID) = MONOID; functor Square (structure X:MONOID functor Prod:PROD) = Prod(structure M=X and N=X); structure IntMonoid : MONOID = struct type t = int fun plus (x,y) = x+y : int val e = 0 end; functor Prod (structure M:MONOID and N:MONOID) : MONOID = struct type t = M.t * N.t fun plus ((m1,n1), (m2,n2) ) = (M.plus (m1,m2), N.plus(n1,n2)) val e = (M.e,N.e) end; structure IntPairMonoid = Square (structure X = IntMonoid functor Prod = Prod); (* No problem if signature added to the above: structure IntPairMonoid: MONOID = Square (structure X = IntMonoid functor Prod = Prod); *) Transcript: - open IntPairMonoid; Error: Compiler bug: getSymbols Comments: It works if the output structure sig is given, as in the comments. Status: fixed in 106 ---------------------------------------------------------------------- Number: 879 Title: error code for uncaught exceptions of exportFn images Keywords: exportFn, exceptions Submitter: Andrew Appel Date: 5/25/94 Version: 1.03f Severity: minor Problem: exportFn handles an uncaught exception by printing a message and then calling exit(0). It should exit with an error code of 1, so that exceptional exits will give the right error code to Unix. Non-exceptional exits should do exit(0), of course. Comments: I could hack this in quite easily, but I imagine things will change with the new runtime system. Owner: John Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 880 Title: #n is not understood for n >= 10 Keywords: Submitter: jont@uk.co.harlqn (Jon Thackray) Date: 5/31/94 Version: SML/NJ 0.75, 0.93 System: Sun 4/330 SunOS 4.1 Severity: minor Problem: #n is not understood for n >= 10 Code: val y = (0,0,0,0,0,0,0,0,0,0) val x = #10 y Transcript: - use"script2.sml"; [opening /usr/users/jont/ml/ml_test/MLW/src/images/script2.sml] /usr/users/jont/ml/ml_test/MLW/src/images/script2.sml:2.1-2.13 Error: operator and operand don't agree (record labels) operator domain: {10:'Z,...} operand: int * int * int * int * int * int * int * int * int * int in expression: (fn {10=10,...} => 10) y [closing /usr/users/jont/ml/ml_test/MLW/src/images/script2.sml] Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 881 Title: Higher order functors without origin's don't work. Keywords: Submitter: Pierre Cregut Date: 6/2/94 Version: 1.02 Severity: major Problem: Higher order functors without origin's don't work. Code: Transcript: - functor f(functor g():sig type t end) : sig type t end = = struct = structure a = g() = type t = a.t = end; functor f : - structure A = f(functor g()=struct type t = int end); structure A : sig eqtype t end - 3:A.t;; (* on .93 *) val it = 3 : A.t (* on 1.02 *) - 3:A.t;; std_in:8.1-8.5 Error: expression and constraint don't agree (tycon mismatch) expression: int constraint: A.t in expression: 3 Fix: Yesterday I show you the problem with origin. In fact I found it while thinking at my own implementation where I would like to have no origin too. I think I have a solution, you will be pleased because it is just an adaptation from the formal semantics and it is easy (just a guess !) to implement. While you build the body as a regular structure, store all the application in a list that you will be able to retrieve when you will do the abstraction. First abstract those applications: - stamps from the arg => operation to get the component from the arg - external stamp => just a constant component - stamp from the body => - already seen in a previous application => refer to this item - not seen => just a regular generative stamp: recreate the component As the functor applications are all stored and in the right order you don't have to worry in the last case, naturally you have to rewalk the result of functor applications to record all the new stamps they have created, in fact at that point you need a way to know that a stamp has been done by the appli cation and not before, this is easy: store the stamp level just before the application is performed with the application. Other gain: you can get rid of the APPLY constructor in structures, well almost because you will probably still use it in recipes. But the point is that you don't have to worry about it any more in regular representations. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 882 Title: "`" and "^" can not appear inside a quotation Keywords: Submitter: La Monte H. Yarroll Date: 6/6/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: SparcStation, SunOS 4.1.3 Severity: minor Problem: "`" and "^" can not appear inside a quotation. Transcript: - `There should be a backquote here: \` in this quotation.`; std_in:100.39 Error: syntax error found at IN - Comments: There is no character escape mechanism in ml.lex for quotations. It is trivial to add one. Fix: Here is the corrected code for state in ml.lex. "\\\\" => (addString(charlist, "\\"); continue()); "\\`" => (addString(charlist, "`"); continue()); "\\^" => (addString(charlist, "^"); continue()); "^" => (YYBEGIN AQ; let val x = makeString charlist in Tokens.OBJL(x,yypos,yypos+(size x)) end); "`" => ((* a closing quote *) YYBEGIN INITIAL; let val x = makeString charlist in Tokens.ENDQ(x,yypos,yypos+(size x)) end); \n => (inc lineNum; addString(charlist,"\n"); continue()); . => (addString(charlist,yytext); continue()); Conclusion [Appel]: The character escape should not be backslash because HOL and other users of quotation use backslash as an important syntax character. However, using ^^ to mean a literal ^ , and ^` to mean a literal ` seems reasonable. History: 107.8 through 108 have Yarroll's version, 108.1 has ^^ meaning ^ and ^` meaning `. Status: fixed in 108.1 ---------------------------------------------------------------------- Number: 883 Title: ML-Yacc can lose on multiline comments Keywords: Submitter: La Monte H. Yarroll Date: 3/15/93 System(s) and Version: ML-Yacc Version 2.1 SML/NJ Version: 0.93 Machine: SparcStation, SunOS 4.1.3 Severity: minor Problem: ML-Yacc can lose on multiline comments Code: bug.grm: ---cut------cut------cut--- (* Multi-line comments break ml-yacc! See? *) %% %name comment_bug %term FULL_STOP %pos int %nonterm anfang %% anfang: FULL_STOP () ---cut------cut------cut--- nobug.grm: ---cut------cut------cut--- (* Multi-line comments break ml-yacc! *) %% %name comment_bug %term FULL_STOP %pos int %nonterm anfang %% anfang: FULL_STOP () ---cut------cut------cut--- Transcript: Script started on Mon Mar 15 16:30:57 1993 $ sml-yacc nobug.grm 1 rule not reduced $ sml-yacc bug.grm bug.grm, line 4: Error: syntax error: deleting BOGUS_VALUE ? smlyacc: uncaught exception Semantic $ exit script done on Mon Mar 15 16:32:12 1993 Comments: There are several points besides the first section in an ML-Yacc specification where multi-line comments produce this form of error. Fix: Current workaround is: (* Make all comments *) (* single lines. blech! :-( *) Owner: Andrew ? Status: open ---------------------------------------------------------------------- Number: 884 Title: (LIB) HashTable.filter does not update the table. Keywords: Submitter: La Monte H. Yarroll Date: 5/18/93 System(s) and Version: Library (0.1) SML/NJ Version: 0.93 Machine: SparcStation, SunOS 4.1.3 Severity: major Problem: HashTable.filter does not update the table. Transcript: (* filter_bug.sml *) (* Demonstrate that filter does not work as advertised. *) val Tbl : int Name.name_tbl = Name.mkNameTbl (10, myexn); Name.insert Tbl (Name.mkName "foo", 1); Name.insert Tbl (Name.mkName "bar", 2); (print "originial table: "; map #2 (Name.listItems Tbl)); (print "filtering through false...\n"; Name.filter (fn _ => false) Tbl); (print "final table: "; map #2 (Name.listItems Tbl)); - use "filter_bug.sml"; [opening filter_bug.sml] val Tbl = HT {n_items=ref 0,not_found=myexn(-), table=ref [|NIL,NIL,NIL,NIL,NIL,NIL,NIL,NIL,NIL,NIL,NIL,NIL,...|]} : int Name.name_tbl val it = () : unit val it = () : unit originial table: val it = [2,1] : int list filtering through false... val it = () : unit final table: val it = [2,1] : int list val it = () : unit Comments: Notice that the elements of Table are completely unaltered even for the false filter. Fix: The fix is very simple; I just added the update. Note that I tightened the handle statement too. The original form could have masked bugs elsewhere in the system, e.g. in the predicate. (* remove any hash table items that do not satisfy the given * predicate. *) fun filter pred (HT{table, n_items, not_found}) = let fun filterP NIL = NIL | filterP (B(hash, key, item, rest)) = if (pred(key, item)) then B(hash, key, item, filterP rest) else filterP rest val arr = !table fun filterTbl i = (Array.update (arr, i, filterP (Array.sub (arr, i))); filterTbl(i+1)) in (filterTbl 0) handle Array.Subscript => () end (* filter *) Status: not a bug --- fixed in smlnj-lib-0.2 ---------------------------------------------------------------------- Number: 885 Title: exportML problem Keywords: exportML Submitter: Satish R. Thatte, satish@sun.mcs.clarkson.edu Date: 6/12/94 System(s) and Version: NJ/SML library 0.2, CML 0.9.8, eXene 0.4 loaded SML/NJ Version: 0.93 Machine: RS/6000 AIX Severity: minor (?) Problem: cannot use exportML to save executable after loading the full Edinburgh ML library that came with the distribution. Transcript: - exportML "sml"; [Major collection... 99% used (4514924/4544644), 760 msec] [Major collection... 99% used (4531684/4531684), 770 msec] ./sml: Invalid argument export: Unexec failed uncaught exception Io "exportML "sml": Invalid argument" Comment: [dbm] Probably caused by trying to overwrite the currently executing image? Owner: John Status: obsolete ---------------------------------------------------------------------- Number: 886 Title: unclear error msg regarding flex records Keywords: type error message Submitter: Lorenz Huelsbergen (lorenz@research.att.com) Date: 6/15/94 Version: 1.04f System: all Severity: very minor Problem: unclear error msg regarding flex records Code: fun f x = #1 x; Transcript: - fun f x = #1 x; std_in:0.0-0.0 Error: unresolved flex record (can't tell what fields there are besides #1) - Comments: Error msg states there's an error but implies that it has enough information for there not to be an error. Comment: [dbm] Seems clear enough to me. Owner: dbm Status: not a bug [dbm] ---------------------------------------------------------------------- Number: 887 Title: System.Directory.cd malfunctions; hands non-C string to runtime Keywords: Submitter: Lorenz Huelsbergen (lorenz@research.att.com) Date: 6/15/94 Version: >= 1.00 System: all Severity: major Problem: System.Directory.cd malfunctions; hands non-C string to runtime Code: System.Directory.cd "."; (* or, in general *) System.Directory.cd s; (* where (|s|=1) or (|s| mod 4 = 0) *) Transcript: : radish 121; /usr/local/sml/103/bin/sml loading /usr/local/sml/103/bin/.heap/sml.mipseb ......................... done Standard ML of New Jersey, Version 1.03, February 14, 1994 [new runtime] - System.Directory.cd "."; uncaught exception NotDirectory - Comments: 'cd' does not wrap 'c_string' around its arg. Strings of length one fault as do strings with multiple-of-four lengths. Fix: In boot/directory.sml, change fun cd s = (chdir s) handle (SysError _) => raise NotDirectory to: fun cd s = (chdir (c_string s)) handle (SysError _) => raise NotDirectory Status: fixed in 1.04g ---------------------------------------------------------------------- Number: 888 Title: unix command line arguments Keywords: Submitter: Elsa Gunter, Dave MacQueen Date: 6/17/94 Version: 1.04f, lexgen System: SGI Challenge, IRIX 5.2 Severity: major Problem: The sml-lex executable does not work because the Unix command line arguments are shifted, i.e. the heap image becomes the second argument and the lex file name becomes the third argument. Fix: The function ExportLexGen.lexGen does the command-line argument analysis. It expects argv to have length two. Either this has to be changed to account for the heap image argument, or, preferably, we should make it possible to make simple stand-alone executables again. Comment: [jhr] This has already been taken care of. When I start hacking the pervasives, there will be two ways to get command line arguments: the standard way will not include any runtime args (those beginning with @SML), but there will also be a way to get the "raw" arguments. The 1.04g version of the runtime already supports both argument lists, but only the stripped version is available. As far as applications go, we plan to provide support for command-line argument processing in the SML/NJ Library. Even "simple" applications should use that. Owner: John Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 889 Title: very slow elaboration and translation of functor applications Keywords: performance, elaboration, modules, instantiation Submitter: Tim Griffin Date: 7/8/94 Version: 1.04f, May 1, 1994 [new runtime] System: /usr/local/sml/104f/bin/.heap/sml.mipseb Severity: Problem: Functor application, which used to be almost intantaneous, is now very slow. Here is a typical example: - structure Tools = Prl5ToolsFUN(structure PrlSys = PrlSys); End Compiler 010 Parse 0.0 sec GC #13.249.340.504.2475.129019: (180 ms.) GC #13.250.341.505.2476.129026: (147 ms.) GC #13.250.341.505.2477.129038: (39 ms.) GC #13.251.342.506.2478.129061: (163 ms.) GC #13.251.342.506.2479.129087: (102 ms.) GC #13.252.343.507.2480.129110: (207 ms.) GC #13.252.343.507.2481.129116: (61 ms.) GC #13.253.344.508.2482.129138: (243 ms.) GC #13.253.344.508.2483.129159: (87 ms.) End Compiler 030 Elaborate 0.0 sec GC #13.253.344.508.2484.129161: (47 ms.) GC #13.254.345.509.2485.129325: (341 ms.) GC #13.254.345.509.2486.129330: (31 ms.) GC #13.254.345.509.2487.129353: (59 ms.) GC #13.254.345.509.2488.129376: (95 ms.) GC #13.254.345.509.2489.129403: (103 ms.) GC #13.254.345.509.2490.129426: (102 ms.) GC #13.254.345.509.2491.129453: (103 ms.) End Compiler 040 Translate 0.0 sec End Compiler 050 CodeOpt 0.0 sec GC #13.255.346.510.2492.129458: (554 ms.) End Compiler 060 Convert 0.0 sec End Compiler 065 CPStrans 0.0 sec End Compiler 070 cpsopt 0.0 sec End Compiler 079 freemapClose 0.0 sec End Compiler 080 closure 0.0 sec End Compiler 090 globalfix 0.0 sec End Compiler 100 spill 0.0 sec End Compiler 110 limit 0.0 sec End Compiler 120 cpsgen 0.0 sec End Compiler 130 Schedule 0.0 sec End Compiler 140 CodeGen 0.0 sec End Execute 0.0 sec structure Tools : PRL5TOOLS - Comment: [dbm] As you can see from the stats printout, almost all the time was spent in the elaborate and translate phases. Owner: Zhong, Dave Status: fixed in 109.26 (actually 109.25.?) ---------------------------------------------------------------------- Number: 890 Title: Erroneous answer for function involving logical operations. Keywords: Submitter: Lal George Date: 7/10/94 Version: 0.93 and onwards. System: MIPS Severity: major/critical Problem: Erroneous answer for function involving logical operations. Code: fun f n = Bits.andb(n+7,Bits.notb 7) Transcript: - f 32761; val it = 0 : int Comments: The function yields correct answers for 0 <= n < 32760 Fix: In 1.05. Status: fixed in 1.05 ---------------------------------------------------------------------- Number: 891 Title: mllex state names not as general as advertized Keywords: Submitter: Richard.Boulton@cl.cam.ac.uk Date: 7/20/94 Version: 0.93 Severity: minor Problem: In the version of ML-Lex distributed with SML/NJ 0.93, state names have to be made up of letters only, whereas the documentation indicates that they may also contain digits, underscores, or primes (except that the first character must be a letter). Fix: Here is the output from diff for a corrected version of lexgen.sml: 501c501,503 < | x => if isletter(x) then get_state(prev,matched^x) --- > | x => if isletter(x) orelse > (isidentchr(x) andalso matched <> "") > then get_state(prev,matched^x) Owner: Andrew Status: fixed in 110 (probably in 109.2x) ---------------------------------------------------------------------- Number: 892 Title: RealArrays not garbage collected Keywords: Submitter: Lorenz Huelsbergen (lorenz@research.att.com) Date: 7/24/94 Version: new-runtime versions (>= 1.03) System: all Severity: major Problem: RealArrays are allocated in the gen-1 (alloc. arena), but not collected from there. Code: val a = RealArray.array(1,3.14); System.Runtime.gc 1; Transcript: : radish 295; /usr/local/sml/104f/bin/sml started .kshrc finished .kshrc loading /usr/local/sml/104f/bin/.heap/sml.mipseb ......................... done Standard ML of New Jersey, Version 1.04f, May 1, 1994 [new runtime] - val a = RealArray.array(1,3.14); val a = - : Assembly.A.realarray - System.Runtime.gc 1; /usr/local/sml/104f/bin/.run/run.mipseb-irix5: Fatal error -- bad object tag 13, obj_start = 0x4dd804, obj = 0x4dd804, desc = 0x76 Fix: minor-gc.c: In 'MinorGC_ForwardObj', replace case DTAG_realdarray: /* only allocated in gen-1 */ default: with: case DTAG_realdarray: len = GET_REALDARR_LEN(desc); arena = gen1->arena[STRING_INDX]; #ifdef ALIGN_REALDS arena->nextw = (ml_val_t *)(((Addr_t)arena->nextw) | WORD_SZB); #endif break; default: Status: fixed in 106 ---------------------------------------------------------------------- Number: 893 Title: Bind exception while recompiling compiler with representation off Keywords: Submitter: Lal George Date: 7/27/94 Version: 1.04m, and 1.05a System: all Severity: major/critical Problem: Turning representation off causes a Bind exception to be raised when recompiling the compiler. Transcript: - lutece:$ ../bin/sml-scb loading /usr/local/sml/104m/bin/.heap/sml-scb.sparc ......................... done Standard ML of New Jersey, Version 1.04m, June 21, 1994 [Batch SC 69a3] val it = () : unit - Compiler.Control.CG.representations:=false; val it = () : unit - Batch.make(); Making directory bin.sparc Recompiling boot directory. assembly.sig: WARNING: no Core access WARNING: no Core access GC #0.0.0.0.1.5: (30 ms.) Repairing blast GC (maxGen = 5 of 5) dummy.sml: WARNING: no Core access WARNING: no Core access Repairing blast GC (maxGen = 5 of 5) core.sml: WARNING: no Core access WARNING: no Core access Repairing blast GC (maxGen = 5 of 5) perv.sig: GC #0.0.0.1.2.28: (50 ms.) Repairing blast GC (maxGen = 5 of 5) perv.sml: uncaught Bind exception translate/translate.sml:362.12-362.36 - Comments: This flags needs to be turned off when creating bin files for the x86. Fix: [Lorenz] Here's an inefficient fix for bug #893 (can't compile compiler with Compiler.Control.CG.representations = false in 104m, 105a). In translate/transtypes.sml, change the line val transTyLty = fn x => if (!rep_flag) then transTyLty x else BOGUSty to: (* val transTyLty = fn x => if (!rep_flag) then transTyLty x else BOGUSty *) val transTyLty = fn x => (if (!rep_flag) then fn x => x else fn (ARROWty _) => ARROWty(BOGUSty,BOGUSty) | _ => BOGUSty) (transTyLty x) [Zhong, do you have a more efficient way to do this?] Comment: [dbm,Lal, 3/23/97] representation analysis code has changed and representation analysis is permanently on. Owner: Zhong Status: obsolete ---------------------------------------------------------------------- Number: 894 Title: obscure error message using infix symbol as variable Keywords: Submitter: Simon Hooker, S.Hooker@teesside.ac.uk Date: 8/1/94 Version: 0.93 Severity: minor Problem: Inadvertent use of an infix identifier like "o" from the Basis in a pattern give rise to the error message "nonfix identifier required". The message should at least name the offending identifier. Transcript: - fun f(o::l) = 3; std_in:5.7 Error: nonfix identifier required - Status: fixed in 107.4 (plus) ---------------------------------------------------------------------- Number: 895 Title: printing type unit when hidden Keywords: printing, types Submitter: Tomasz Wierzbicki Date: 8/1/94 System(s) and Version: any SML/NJ Version: 0.93, 1.03f, etc. Machine: any Severity: minor Problem: Unit type never displayed as hidden. Code: datatype unit = C Transcript: - datatype unit = C; datatype unit con C : unit - (); val it = () : unit - C=(); std_in:4.1-4.4 Error: operator and operand don't agree (tycon mismatch) operator domain: unit * unit operand: unit * unit in expression: = (C,()) - Comments: The response to the second line of input should be val it = () : ?.unit Owner: Dave Test: bug895.sml Status: open ---------------------------------------------------------------------- Number: 896 Title: Compiler bug: Unexpected RELtyc in transtypes Keywords: Submitter: Andrew Appel Date: 6/3/94 Version: 1.05a Severity: major Problem: Elaborating an equality expression using datacons from a functor parameter whose signature was pickled fails with "Compiler bug: Unexpected RELtyc in transtypes". Code: **** a.sig **** signature S = sig datatype d = A | B (* have to have two constructors *) end **** a.sml **** functor F (X : S) : sig end = struct val _ = (X.A = X.B) (* can't simplify - need equality fn *) end Transcript: glove$ ./sml-sc Standard ML of New Jersey, Version 1.03f, April 11, 1994 [SC 69a2] val it = () : unit - sc.make(); Defining the group... [scanning sources.sc] Compiling... [Parsing a.sig] [compiling a.sig] [writing .mipseb/a.sig.bin] [compiling a.sml] [writing .mipseb/a.sml.bin] Introducing the new bindings... val it = () : unit - ^D glove$ rm .mipseb/a.sml.bin glove$ ./sml-sc Standard ML of New Jersey, Version 1.03f, April 11, 1994 [SC 69a2] val it = () : unit - sc.make(); Defining the group... [scanning sources.sc] Compiling... [reading .mipseb/a.sig.bin] [compiling a.sml] Error: Compiler bug: Unexpected RELtyc in transtypes Fix: After instantiating the functor parameter, we apply a fixup function that goes through it and replaces the datacons in the kind field of datatypes with their "instantiated" versions. Status: fixed in dbm-1.05b ---------------------------------------------------------------------- Number: 897 Title: core dump caused by representation optimization Keywords: Submitter: Elsa L. Gunter Date: 9/26/94 Version: 1.01 - 1.05 System: SGI / Irix5.2, Sparc / SunOS 4.1.1 Severity: critical Problem: Dumps core and gives wrong answers Code: signature P_sig = sig type env end; structure P = struct type env = {free : int list} -> int (* * {free : int list} *) (* The free is necessary, and the record can have additional fields. *) (* If the range is made a pair by adding the record type in comments, it dumps core. If not it gives the wrong answer, printing "AAAA" and returning 10. *) end; functor Fun (structure P : P_sig) = (* The functor is necessary *) struct datatype svalue = A of (P.env) | B of (P.env list) (* The list as the argument of B is necessary *) val actions = fn (A aexp) => B([aexp]) end structure Table = Fun(structure P = P); val Table.B [aexp] = Table.actions (Table.A (fn E:{free: int list} => ((fn (_::_) => (print "AAAA\n";10) (* The pattern for cons is necessary *) | [] => (print "BBB\n";0)) (#free E)(*, E*)))); (* uncomment if env changed to return pair and core dump will happen *) val x = aexp {free = []}; Transcript: use "bad1.sml"; [opening bad1.sml] signature P_sig = sig type env end structure P : sig type env end bad1.sml:13.19-13.42 Warning: match nonexhaustive A aexp => ... functor Fun : structure Table : sig datatype svalue con A : P.env -> svalue con B : P.env list -> svalue val actions : svalue -> svalue end bad1.sml:18.1-24.22 Warning: binding not exhaustive B (aexp :: nil) = ... val aexp = fn : P.env AAAA val x = 10 : int val it = () : unit Comments: This breaks HOL90 and was a real bear to isolate. [dbm] The incorrect behavior disappears when Compiler.Control.CG.representations is set to false, indicating that is has to do with representation optimization. Status: fixed in 107.3 [Appel] ---------------------------------------------------------------------- Number: 898 Title: mllex - start state identifiers containing underscores Keywords: Submitter: Raoul Bhoedjang, raoul@cs.vu.nl Date: 7/15/94 System(s) and Version: Tools, lexgen, 0.93 distribution SML/NJ Version: 0.93 Machine: sun4, sunos Severity: minor Problem: ml-lex complains about start state identifiers that contain underscores; the documentation allows such identifiers. Code: Put this in a file and feed the file name to lexGen: datatype lexresult = int val eof = fn() => EOF %% %S IN_COMMENT; %% "(*" => (YYBEGIN IN_COMMENT; lex()); "*)" => (YYBEGIN INITIAL; lex()); [\n] => (inc lineno; lex()); . => (lex()); Transcript: - val _ = lexGen "/home/raoul/proj/avc/tst.lex"; sml-lex: syntax error, line 8: bad start state list Comments: Error msg. disappears when the underscores are removed. Fix: disallow underscores or modify the bit in lexgen.sml that recognises start states. Status: fixed in lexgen 1.6.0 ---------------------------------------------------------------------- Number: 899 Title: makeml isn't up to date for Solaris Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 8/8/94 System(s) and Version: SML/NJ Version: 1.03f Machine: SPARC, Solaris 2.3 Severity: major Problem: makeml isn't up to date for Solaris Comments: src/makeml doesn't have an entry for "-sun4 solaris" src/runtime/Makefile needs to #define _ASM when assembling SPARC.prim.s Status: fixed in 106 (makeml has gone away) ---------------------------------------------------------------------- Number: 900 Title: sml-noshare won't build on Solaris (and maybe other OS) Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 8/8/94 System(s) and Version: SML/NJ Version: 1.03f Machine: SPARC, Solaris 2.3 Severity: major Problem: sml-noshare won't build on Solaris (and maybe other OSs) Comments: The way the noshare runtime/allmo.o is built is inherently wrong. run.c wants "binend" to be a global symbol located just after the end of the "binst" array, as is the case when linkbin has built an allmo.s for a shared runtime. But when a noshared runtime is built, the dummy allmo.c (containing: char binst[1]; char binend[1]) is compiled using the C compiler, in the hope that binend will be located just after binst. Guess what? This is not true for Solaris 2.3. This results in loadBinFile() (in run.c) happily using addresses in nowhere-land as code pointers (the test "if (internal_bin + 8 < binend)" is true!) with disastrous results. One fix might be to let binend be a "char*" pointing just after binst[], but this would require changes to all of linkbin.c, allmo.c, and run.c . Since linkbin.c already knows the format of allmo.s, I decided instead to generalize linkbin.c and let it build an appropriate allmo.s for the noshare runtime. This required minor changes to makeml, runtime/Makefile, and runtime/linkbin.c . runtime/allmo.c is no longer used. Status: fixed in 106 (noshare has gone away) ---------------------------------------------------------------------- Number: 901 Title: runtime/cfuns.c in 103f Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 8/8/94 System(s) and Version: SML/NJ Version: 1.03f Machine: SPARC, Solaris 2.3 Severity: major runtime/cfuns.c (function raise_syserror()) uses sprintf() without having #included getdev() (for SOLARIS) has a typo: (c == "\n") should be: (c == '\n') Fix: *** makeml.~1~ Sun Dec 19 20:56:18 1993 --- makeml Mon Aug 8 17:00:15 1994 *************** *** 103,108 **** --- 103,117 ---- case $1 in mach) OPSYS=MACH; DEFS="$DEFS -DBSD" ;; sunos) OPSYS=SUNOS ;; + solaris|sunos5) + MAKE=/usr/ccs/bin/make + AS=/usr/ccs/bin/as + CPP=/usr/ccs/lib/cpp + CPPP="\"$CPP -P\"" + DEFS="$DEFS -DSUNOS" + OPSYS=SOLARIS + CFL="$CFL -lsocket -lnsl" + ;; *) echo "$CMD must specify opsys arg for SUN (sunos or mach)" exit 1 *************** *** 529,545 **** CCARG="" fi if test -n "$SHARE" then ! ARG="MACHINE=$MACHINE $CCARG 'CFL=$CFL' 'LDFLAGS=$LDFLAGS' 'LIBS=$LIBS' 'DEFS=$DEFS -DAS=\\\"$AS\\\"' linkbin" ! echo "$CMD (cd $RUNTIME; $MAKE $ARG)" ! (cd $RUNTIME; eval $MAKE $ARG) if test "$?" -ne "0"; then exit 1 fi ! ! echo "$CMD $RUNTIME/linkbin $BIN $RUNTIME" ! $RUNTIME/linkbin $BIN $RUNTIME if test "$?" -ne "0"; then exit 1 fi --- 538,561 ---- CCARG="" fi + ARG="MACHINE=$MACHINE $CCARG 'CFL=$CFL' 'LDFLAGS=$LDFLAGS' 'LIBS=$LIBS' 'DEFS=$DEFS -DAS=\\\"$AS\\\"' linkbin" + echo "$CMD (cd $RUNTIME; $MAKE $ARG)" + (cd $RUNTIME; eval $MAKE $ARG) + if test "$?" -ne "0"; then + exit 1 + fi + if test -n "$SHARE" then ! echo "$CMD $RUNTIME/linkbin $BIN $RUNTIME" ! $RUNTIME/linkbin $BIN $RUNTIME if test "$?" -ne "0"; then exit 1 fi ! else ! # create "noshare" allmo.o ! echo "$CMD $RUNTIME/linkbin $RUNTIME" ! $RUNTIME/linkbin $RUNTIME if test "$?" -ne "0"; then exit 1 fi *** runtime/Makefile.~1~ Wed Aug 25 16:11:14 1993 --- runtime/Makefile Mon Aug 8 16:54:25 1994 *************** *** 56,65 **** export.o : tags.h prim.o : $(MACHINE).prim.s tags.h ! $(CPP) -DASM $(DEFINES) $(MACHINE).prim.s >prim.s $(AS) -o prim.o prim.s - - allmo.o : allmo.c tags.h ml_types.h ml_state.h mask.h linkbin: linkbin.c tags.h $(CC) $(CFLAGS) -o linkbin linkbin.c --- 56,63 ---- export.o : tags.h prim.o : $(MACHINE).prim.s tags.h ! $(CPP) -DASM -D_ASM $(DEFINES) $(MACHINE).prim.s >prim.s $(AS) -o prim.o prim.s linkbin: linkbin.c tags.h $(CC) $(CFLAGS) -o linkbin linkbin.c *** runtime/cfuns.c.~1~ Wed Sep 1 19:47:43 1993 --- runtime/cfuns.c Mon Aug 8 16:12:51 1994 *************** *** 46,51 **** --- 46,52 ---- #ifdef HPUX #include #endif + #include /* declare sprintf() for raise_syserror() */ #include "ml_state.h" #include "ml_types.h" *************** *** 2350,2356 **** #ifdef SOLARIS #include - #include #include #include #include --- 2351,2356 ---- *************** *** 2462,2468 **** fil.data = fbuf; fil.eptr = fil.ptr = 0; while((sts = getline(buf, &fil)) > 0) { ! if (((c = buf[0]) == '#') || (c == "\n") || (c == '\0')) continue; rest = buf; p = getfield(&rest); /* get and test netid */ if (p == NULL) continue; --- 2462,2468 ---- fil.data = fbuf; fil.eptr = fil.ptr = 0; while((sts = getline(buf, &fil)) > 0) { ! if (((c = buf[0]) == '#') || (c == '\n') || (c == '\0')) continue; rest = buf; p = getfield(&rest); /* get and test netid */ if (p == NULL) continue; *** runtime/linkbin.c.~1~ Wed Sep 1 19:21:31 1993 --- runtime/linkbin.c Mon Aug 8 17:07:41 1994 *************** *** 17,22 **** --- 17,24 ---- * into a "runtime"/allmo.o file that defines two symbols: "binst," which * occurs at the beginning, and "binend" at the end. * + * linkbin runtime + * creates a dummy allmo.o to be used when building the "noshare" runtime. */ #include *************** *** 121,134 **** TEXT(asfile); GLOBAL(asfile, "binst"); LABEL(asfile, "binst"); ! WORD(asfile, MAGICNUM); ! SPACE(asfile, size-4); GLOBAL(asfile, "binend"); LABEL(asfile, "binend"); - } - struct {char magic[16]; int import_cnt; int export_cnt; --- 123,136 ---- TEXT(asfile); GLOBAL(asfile, "binst"); LABEL(asfile, "binst"); ! if( size ) { ! WORD(asfile, MAGICNUM); ! SPACE(asfile, size-4); ! } GLOBAL(asfile, "binend"); LABEL(asfile, "binend"); } struct {char magic[16]; int import_cnt; int export_cnt; *************** *** 185,194 **** char as_buf[200], o_buf[200], cmd_buf[200]; FILE *asfile, *ofile; int ofd; int size, i, pos, sts; ! if (argc!=3) ! die("usage: linkbin bindir runtime"); ! dir=argv[1]; runtime=argv[2]; ! size=process_all("BOOTLIST",dir)+process_all("BINLIST",dir); sprintf(as_buf, "%s/allmo.s", runtime); sprintf(o_buf, "%s/allmo.o", runtime); --- 187,199 ---- char as_buf[200], o_buf[200], cmd_buf[200]; FILE *asfile, *ofile; int ofd; int size, i, pos, sts; ! if( argc == 2 ) { ! runtime = argv[1]; size = 0; ! } else if( argc == 3 ) { ! dir = argv[1]; runtime = argv[2]; ! size = process_all("BOOTLIST",dir) + process_all("BINLIST",dir); ! } else ! die("usage:\tlinkbin bindir runtime\nor\tlinkbin runtime\n"); sprintf(as_buf, "%s/allmo.s", runtime); sprintf(o_buf, "%s/allmo.o", runtime); *************** *** 205,210 **** --- 210,217 ---- fprintf (stderr, "cannot assemble %s, status = %d\n", as_buf, sts); exit (1); } + + if( size == 0 ) exit(0); out = fopen(o_buf,"r+"); if (!out) Status: fixed in 106 (cfuns.c has gone away) ---------------------------------------------------------------------- Number: 902 Title: tab character in string in lexgen/lexgen.sml Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 8/8/94 System(s) and Version: lexgen 1.5.0 (a.k.a. lexgen94) SML/NJ Version: 1.03f Machine: all Severity: minor Problem: There's a "tab" character in a string literal in lexgen/lexgen.sml . This provokes an error message from the sml/nj 1.03f lexer. Code: Transcript: Comments: Fix: Change the "tab" character to "\t". *** lexgen.sml.~1~ Thu Jun 2 21:22:15 1994 --- lexgen.sml Mon Aug 8 18:28:46 1994 *************** *** 1090,1096 **** val skel_mid2 = "\t\t | Internal.D k => action (i,(acts::l),k::rs)\n\ \\t\t | Internal.T k =>\n\ ! \\t\t let fun f (a::b,r) =\n\ \\t\t\t if a=k\n\ \\t\t\t then action(i,(((Internal.N a)::acts)::l),(b@r))\n\ \\t\t\t else f (b,a::r)\n\ --- 1090,1096 ---- val skel_mid2 = "\t\t | Internal.D k => action (i,(acts::l),k::rs)\n\ \\t\t | Internal.T k =>\n\ ! \\t\t\t let fun f (a::b,r) =\n\ \\t\t\t if a=k\n\ \\t\t\t then action(i,(((Internal.N a)::acts)::l),(b@r))\n\ \\t\t\t else f (b,a::r)\n\ Status: fixed in 106 (lexgen 1.6.0) ---------------------------------------------------------------------- Number: 903 Title: floating point broke on DECstation Keywords: Submitter: Daniel R. Ehrlich Date: 08/29/94 System(s) and Version: Compiler (?) SML/NJ Version: 0.93 Machine: DECstation 5000/33 Severity: critical Problem: Can not use floating point numbers Code: 4.2; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - 4.2; uncaught exception Overflow - Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 904 Title: equal but distinguishable strings Keywords: Submitter: Alain.Deutsch@inria.fr Date: 9/8/94 Version: 103f System: ? Severity: major Problem: Two strings test equal, but a function applied to both strings yields different results, therefore distinguishing them. Transcript: Standard ML of New Jersey, Version 1.03f, April 11, 1994 - - fun Bug(s: string) = let val file = "/tmp/G00099" val stream = open_out(file) val _ = output(stream, s) val _ = close_out(stream) val stream = open_in(file) val s' = input(stream, size(s)) val _ = close_in(stream) fun f(s: string) = case s of "OK\n" => 0 | _ => 1 in (f s, f s', s=s') end; val Bug = fn : string -> int * int * bool - - val bug = Bug("OK\n"); val bug = (0,1,true) : int * int * bool - - Bug("FOObar"); val it = (1,1,true) : int * int * bool Then the first run Bug("OK\n") gives the following inconsistent result: s and s' are equal but distinguishable. This looks very much like a bug. Status: fixed in 1.07 ---------------------------------------------------------------------- Number: 905 Title: type insecurity with local around functor declaration Keywords: type checking, core dump, value restriction Submitter: Claudio Russo,cvr@dcs.ed.ac.uk Date: 9/12/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Solaris but I guess all others too Severity: critical Problem: There is a type insecurity arising from the (non-standard according to the Definition) use of local declarations in functor bindings, ie. some well typed programs go "wrong" in the sense of Milner. Consider the following: Code: local val lr = ref [] in functor F (type t) = struct exception Empty; local datatype s = S of t in fun put x = lr:= [(S x)] fun get () = case !lr of [S x] => x | _ => raise Empty end end end; (* local *) structure A = F(type t = unit -> unit); structure B = F(type t = bool); B.put true; (A.get ()) (); (* an attempt to apply a boolean to an argument *) Transcript: nj-sml.93 Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - val it = () : unit - use "njmlbug.sml"; [opening njmlbug.sml] functor F : structure A : sig exception Empty val get : unit -> ?..t val put : ?..t -> unit end structure B : sig exception Empty val get : unit -> ?..t val put : ?..t -> unit end val it = () : unit Process NJ-SML bus error (core dumped) Comments: The bug occurs for two reasons. 1) The type name assigned to s does not become one of the type names that need to be regenerated on each application of the functor F because it does not appear in the signature of the body. This is a problem with the Definition. 2) The type name assigned to s is allowed to escape its scope and instantiate the imperative type variable introduced by the declaration of the reference lr. This can't happen in the Definition because there is no construct for binding values local to a functor declaration (or lambda abstraction over functors). With the above in mind we see why the problem arises. At the declaration val lr = [], lr is given type '_a list. In the functor body, s is given generative name n, say, causing '_a to unify with n. But n is really dependent on the imported type t so it is unsound to unify it with '_a, since n varies with each different choice of t. Fix: Don't allow type names to escape their scope! I.e.the name generated for s shouldn't be unifiable with any type variable (imperative or not) appearing free in the context at the point of the declaration of s. The reason I used an imperative type variable is that, in the absence of functional abstraction over functors, it seems impossible to introduce non-generic type variables that are free in the context and allow s's name to escape its scope. However, in the presence of higher-order functors it may be possible to construct similar examples of programs that go wrong. I'd be very interested in your comments on the above bug, and on what the implications for your implementation of higher order functors are. Fix: A "local" form for functor declarations is not part of SML 90 or SML 96. Eliminating this syntactic form should fix the bug. Owner: dbm Test: bug905.sml Status: fixed in 109.26 ---------------------------------------------------------------------- Number: 906 Title: subscript exception compiling sigs with type abbreviations Keywords: Submitter: Emden R. Gansner, erg@research.att.com Date: 9/13/94 Version: > 1.03 System: all Severity: major Problem: Subscript exception raised when compiling signatures with type abbreviations. Code: signature WIDGET = sig datatype valign = VCenter type widget end signature WIDGET_SET = sig structure W : WIDGET type set_item = W.widget end Transcript: Comments: This is variation on bug 869. If the datatype declaration is commented out, it compiles okay. Status: fixed in 107 (dbm) ---------------------------------------------------------------------- Number: 907 Title: polymorphic exceptions allowed Keywords: Submitter: Bernard Berthomieu (bernard@laas.laas.fr) Date: 9/13/94 Version: 0.93 System: SparcStation IPC, SunOS 4.1.3 Severity: Problem: Polymorphic exceptions allowed. Code: Transcript: - let exception A of 'a in (A: 'a -> exn) end; val it = fn : 'a -> exn (* but elaboration is correct if the type constraint is removed: *) - let exception A of 'a in A end; Error: non-weak type variable in exception declaration Owner: dbm Test: bug907.sml, bug907.1.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 908 Title: divide by 0.0 on Sparc (see bug 716 -- claimed to be fixed in 1.02) Keywords: Submitter: ryan@cs.unt.edu (Ryan Stansifer) Date: 9/16/94 SML/NJ Version: 0.93 Machine: SPARC under SunOS Release 4.1.3_U1 Problem: segmentation fault Code: #1 (2, 1.0 / 0.0); Transcript: krum> sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - (2, 1 div 0); uncaught exception Div - #1 (2, 1 div 0); uncaught exception Div - (2, 1.0 / 0.0); uncaught exception Div - #1 (2, 1.0 / 0.0); Segmentation fault (core dumped) Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 909 Title: divide by 0.0 on DECstation Keywords: Submitter: John Hannan Date: 9/16/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: DECstation 5000/33 (Ultrix 4.4) Severity: major Problem: Divide by zero exception does not work Code: 3.0/0.0; or 3.0/0.0 handle Div => 0.0; Transcript: - 3.0/0.0; strange floating point error, 3616 Process cmusml exited abnormally with code 3 Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - 3.0/0.0 handle DIV => 4.0; strange floating point error, 3616 Process cmusml exited abnormally with code 3 Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 910 Title: real overflow on DECstation Keywords: Submitter: John Hannan Date: 9/16/94 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: DECstation 5000/33 (Ultrix 4.4) Severity: major Problem: Overflow exception for reals does not work Code: 1E300 * 1E300; Transcript: - 1E300 * 1E300; strange floating point error, 7700 Comments: I assume this is related to the bug report I sent earlier about the Div exception not working. Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 911 Title: ^C hangs sml on Sparc Keywords: Submitter: Dave MacQueen Date: 9/30/94 Version: 1.05a System: Sparc, SunOS 4.1.x Severity: major Problem: Typing ^C (interrupt) at to level does not interrupt SML, but causes it to go catatonic so that it doesn't notice further input. This is with sml run in an xterm window. Status: fixed in 107 (JHR; 11/14/94) ---------------------------------------------------------------------- Number: 912 Title: Compiler bug: PPVal.switch: none of the datacons matched Keywords: Submitter: Gene Rollins Date: 10/4/94 Version: 1.05b/fox System: ? Severity: major Problem: Code: structure pp = struct open Compiler.PrettyPrint fun p () = mk_ppstream {linewidth = 79, flush = fn () => flush_out std_out, consumer = outputc std_out} end Transcript: loading /afs/cs/project/fox-7/member/cline/port/105a/bin/.heap/sml.alpha32 ......................... done Standard ML of New Jersey, Version 1.05b/fox, October 3,1994 [new runtime] - use "pp.sml"; ... - pp.p(); val it = PPS {++=fn,consumer=fn,flush=fn,left_index=ref 0,left_sum=ref 0,linewidth=79, right_index=ref 0,right_sum=ref 0,space_left=ref 79,the_delim_stack=-, Error: Compiler bug: PPVal.switch: none of the datacons matched - Status: fixed in 107.4+ ---------------------------------------------------------------------- Number: 913 Title: Makestring.intToStr from smlnj-lib causes core dump Keywords: Submitter: Gene Rollins Date: 10/4/94 Version: 1.05b/fox System: ? Severity: critical Problem: Library function Makestring.intToStr cases core dump. Transcript: loading /afs/cs/project/fox-7/member/cline/port/105a/bin/.heap/sml.alpha32 ......................... done Standard ML of New Jersey, Version 1.05b/fox, October 3,1994 [new runtime] - Makestring.int 3; val it = "3" : string - makestring 4; val it = "4" : string - use "smlnj-lib/makestring-sig.sml"; [opening smlnj-lib/makestring-sig.sml] GC #0.0.0.0.1.11: (14 ms.) signature MAKESTRING = sig val padLeft : string * int -> string val padRight : string * int -> string val boolToStr : bool -> string val intToBin : int -> string val intToOct : int -> string val intToStr : int -> string val intToHex : int -> string exception BadPrecision val realToFloStr : real * int -> string val realToSciStr : real * int -> string val realFFormat : real * int -> {mantissa:string, sign:bool} val realEFormat : real * int -> {exp:int, mantissa:string, sign:bool} val realGFormat : real * int -> {exp:int option, frac:string, sign:bool, whole:string} end val it = () : unit - use "smlnj-lib/makestring.sml"; [opening smlnj-lib/makestring.sml] GC #0.0.0.1.2.22: (25 ms.) GC #0.0.0.1.3.43: (44 ms.) GC #0.0.0.1.4.57: (67 ms.) GC #0.0.1.2.5.79: (71 ms.) GC #0.0.1.2.6.87: (35 ms.) GC #0.0.1.2.7.122: (25 ms.) GC #0.0.1.2.8.153: (15 ms.) GC #0.0.1.2.9.191: (36 ms.) GC #0.0.1.2.10.243: (20 ms.) GC #0.0.1.2.11.309: (20 ms.) structure Makestring : MAKESTRING val it = () : unit - Makestring.intToStr; val it = fn : int -> string - Makestring.intToStr 3; /afs/cs.cmu.edu/project/fox-7/member/cline/port/105a/bin/sml[137]: 8308 Segmentation fault Process cmusml exited abnormally with code 139 Status: fixed in 106 ---------------------------------------------------------------------- Number: 914 Title: "foo1" style names in productions in mlyacc Keywords: Submitter: Andrew Appel Date: 10/12/94 Version: ? (Need mlyacc version numbers?) Severity: minor Problem: There appears to be a minor bug in ML-Yacc. The manual claims that if you have a production whose right-hand-side uses symbol "foo" just once, you can refer to its value (in the semantic action) as either "foo" or "foo1". But "foo1" seems to lead to problems, so just use "foo". Example: Doesn't work: exp : MINUS exp (f(exp1)) Does work: exp : MINUS exp (f(exp)) (Problem is that ML-Yacc needs to insert extra parentheses around an "as" clause in the pattern-match code that it prints out for the semantic action function. Should be trivial to fix. Owner: Status: open ---------------------------------------------------------------------- Number: 915 Title: bogus nonexhaustive match warning for bytearray Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 10/13/94 Version: 0.93, 1.05 (all?) Severity: minor Problem: bogus nonexhaustive match warning for bytearray Code: case ByteArray.sub(a,i) of 0 => ... | ... | 255 => ... Comments: it is annoying to get a bogus >250 line warning Owner: John Status: not a bug ---------------------------------------------------------------------- Number: 916 Title: Compiler bug: Misc.checkbound from type abbrev in sig Keywords: Submitter: Kwangkeun Yi kwang@research.att.com Date: 10/18/94 Version: 1.05 System: SGI Challenger, Irix 5.2 Severity: major Problem: binding non-nullary type constructor inside signature does not elaborate Transcript: - signature foo = = sig = type 'a t = 'a list = end; Error: Compiler bug: Misc.checkbound - Comments: SML/NJ allows type binding inside signature specification, while the Definition does not. Status: fixed in 107 (dbm) ---------------------------------------------------------------------- Number: 917 Title: CRC's computed inaccurately Keywords: Submitter: appel Date: October 21, 1994 System(s) and Version: Compiler SML/NJ Version: 1.05 Machine: all Severity: minor Problem: CRC's computed inaccurately Comments: Here is the "init" function in util/crc.sml: fun init 256 = () | init n = let fun f(0,_,r) = r | f(i,p,r) = if Bits.andb(i,1)<>0 then f(Bits.rshift(i,1),p+p,p+r) else f(Bits.rshift(i,1),p+p,r) in update(table,n,f(n,poly,0)); init(n+1) end The problem is that "p+r" should really be Bits.xorb(p,r). (p+p is ok, however, that's just a left shift). Correcting this code should lead to "better" CRC computations (fewer collisions). Thanks to Peter Sestoft for bringing this to my attention. Fix: shown above Status: fixed in 1.06 --------------------------------------------------------------------- Number: 918 Title: incomplete sharing propagation after functor application Keywords: Submitter: Kwangkeun Yi kwang@research.att.com Date: 10/21/94 Version: 1.05 System: SGI Challenger Severity: major Problem: incomplete sharing propagation after functor application Code: (* file test.sml *) signature SIG = sig end functor ID (X: SIG) = X functor H() = struct structure A = struct end structure B = ID(A) end structure S = H() functor F(structure X: SIG structure Y: SIG sharing X = Y) = struct end structure foo = F(structure X = S.A structure Y = S.B) Transcript: - use "test.sml"; test2.sml:10.17-10.54 Error: structure sharing violation ?.S.B. # .X - Comments: After the functor application structure S = H() S.A and S.B become unsharable, causing the F application F(structure X = S.A structure Y = S.B) to fail. If we apply F like F(structure X = struct type t = int end structure Y = ID(X)) then it is OK, as expected. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 919 Title: bus error Keywords: Submitter: Lal George Date: 25 Oct. 1994 Version: 105 and 105g System: Alpha and Mips Severity: critical Problem: bus error. Comments: This bug was brought to my attention by Ken Cline. I have not tested it in versions before 105. The system will core dump faster if representations is turned off. Code: Approx. 20000 lines, available from ftp.cs.cmu.edu:/afs/cs/project/fox/ftp/working/elfbug.tar.gz Transcript: sequent/natded.elf --- 1 --- static sequent/sequents.elf --- 2 --- static sequent/cut-sequents.elf --- 3 --- static sequent/cut-admit.elf --- 4 --- dynamic sequent/cut-elim.elf --- 5 --- dynamic val it = () : unit Reading pragmas [mode, order, lex]: ...... /usr/local/sml/105/bin/sml[137]: 5274 Bus error Status: fixed in 106 (George) ---------------------------------------------------------------------- Number: 920 Title: tuple selector syntax not handled by debugger Keywords: Submitter: Stephen Weeks, sweeks@cs.cmu.edu Date: October 25, 1994 System(s) and Version: Compiler, Debugger SML/NJ Version: 0.93 Machine: CPU=PMAX-2100 OS=UNIX (mach) Severity: minor Problem: tuple selector syntax not handled by debugger Code: UserDebugCommands.run "#1(13,17)" Transcript: bin% smld Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - UserDebugCommands.run "#1(13,17)"; Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking Owner: Status: obsolete [debugger not supported] ---------------------------------------------------------------------- Number: 921 Title: nonexhaustive binding failure while elaborating functor decl Keywords: Submitter: mahler@socs.uts.edu.au (Daniel Mahler) Date: 27/10/93 System(s) and Version: Runtime System SML/NJ Version: 0.93 Machine: sparc IPC Severity: minor Problem: A basic problem with higher order functors Code: signature X = sig end functor Apply (functor F (A : X) : X) (B : X) : X = F(B) functor FUN (functor G (C : X) : X) (D : X) : X = Apply(G)(D); Transcript: std_in:24.8 Error: unbound structure: G Error: Compiler bug: ModuleUtil: getStrStamp wrong origin Comments: Although the example above is not stricltly the correct syntax, it nonetheless causes a Compiler error The proper syntax is: (bug921.1.sml) signature X = sig end functor Apply (functor F (A : X) : X) (B : X) : X = F(B) functor FUN (functor G (C : X) : X) (D : X) : X = Apply(functor F = G)(D) Comment: [dbm] In 109.21, no longer causes Compiler Bug, but instead fails with nonexhaustive binding failure: - use "bug921.sml"; [opening bug921.sml] signature X = sig end functor Apply : GC #0.0.0.1.7.500: (11 ms) bug921.sml:10.8 Error: unbound structure: G uncaught exception nonexhaustive binding failure raised at: elaborate/elabmod.sml:246.6-255.9 elaborate/elabmod.sml:513.33 util/stats.sml:168.40 build/evalloop.sml:145.36 build/evalloop.sml:232.54 build/evalloop.sml:316.38-316.41 Comment: [dbm,11/14/96] Now fails on bug921.1.sml (which is legal syntax) with uncaught exception Unbound. Owner: dbm Test: bug921.sml, bug921.1.sml, bug921.2.sml Status: open ---------------------------------------------------------------------- Number: 922 Title: failure of functor currying Keywords: Submitter: mahler@socs.uts.edu.au (Daniel Mahler Date: 28/10/94 System(s) and Version: sml SML/NJ Version: 0.93 Machine: sparc IPC Severity: critical (for my current project) Problem: FAILURE OF FUNCTOR CURRYING Code: signature Index = sig type A type I val index : A -> I end signature Square = sig structure Source : Index structure Target : Index val top : Source.A -> Target.A val bottom : Source.I -> Target.I end signature FunctorSig = sig type 'a C val map : ('a -> 'b) -> 'a C -> 'b C end functor MapIndex (structure F:FunctorSig) (structure In:Index) : Index = struct type A = In.A F.C type I = In.I F.C val index = F.map In.index end functor MapSquare (structure G:FunctorSig) (structure Sq:Square) : Square = struct structure Source = MapIndex (structure F = G) (structure In = Sq.Source) structure Target = MapIndex (structure F = G) (structure In = Sq.Target) val top = G.map Sq.top val bottom = G.map Sq.bottom end Transcript: - use "p7.sml" uncaught exception Subscript Comments: Subscript is an array exception; I am not using arrays, only the above code. Uncurried version of the code compiles ok: signature Index = sig type A type I val index : A -> I end signature Square = sig structure Source : Index structure Target : Index val top : Source.A -> Target.A val bottom : Source.I -> Target.I end signature FunctorSig = sig type 'a C val map : ('a -> 'b) -> 'a C -> 'b C end functor MapIndex (structure F:FunctorSig and In:Index) : Index = struct type A = In.A F.C type I = In.I F.C val index = F.map In.index end functor MapSquare (structure G:FunctorSig) (structure Sq:Square) : Square = struct structure Source = MapIndex (structure F = G and In = Sq.Source) structure Target = MapIndex (structure F = G and In = Sq.Target) val top = G.map Sq.top val bottom = G.map Sq.bottom end Comment: [Lal] This fails in 105 as well as 93. [dbm] This is a other variant of bugs 796, 803, 860. Status: fixed in 107 (dbm) ---------------------------------------------------------------------- Number: 923 Title: getWD() generates a bus error Keywords: Submitter: Lal George, Elsa Gunter Date: 10/27/94 Version: 105f, 106 System: SGI, IRIX 5.2 Severity: major Problem: getWD() generates a bus error Transcript: radish:$ $s/105f/bin/sml loading /nfs/297/people/sml/105f/bin/.heap/sml.mipseb .............. done Standard ML of New Jersey, Version 105.6, October 18, 1994 [new runtime] - System.Directory.getWD(); /usr/local/sml/105f/bin/sml[98]: 18662 Bus error Comment: [John Reppy] This bug will be fixed as soon as I get rid of the old getWD implementation and replace it by a call to the C library function. Should happen in 107. Status: fixed in 107 (jhr) ---------------------------------------------------------------------- Number: 924 Title: misspelling of function names throws me out of SML Keywords: Submitter: Leonid, libkin@research.att.com Date: november 4 Version: 106 System: Linux Severity: critical Problem: misspelling of function names throws me out of SML Transcript: Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime] - f 1; std_in:7.1 Error: unbound variable or constructor: f Uncaught exception SystemCall with "fionread failed, Invalid argument" % (same happens if I apply a function to unbound variable or if an expression does not typecheck (e.g. 1 + "a"; has the same effect). Status: fixed in 106.1 ---------------------------------------------------------------------- Number: 925 Title: irix installation bug Keywords: Submitter: Marshall Abrams, ab2r@midway.uchicago.edu Date: 10/25/94 System(s) and Version: cc version 2.10 (?) SML/NJ Version: 0.93 Machine: Silicon Graphics 4D/280 IRIX:4.0.5 Severity: minor Problem: 'makeml -mips irix' puts '-cckr' in DEFS, which thereby gets put in DEFINES in the Makefile in src/runtime. This is fine for cc, but cpp chokes on '-cckr'. Transcript: /lib/cpp -P -DASM -DMIPS -D_BSD_SIGNALS -cckr -Dsgi -DSGI MIPS.prim.s >prim.s cpp: error 0: unknown flag -cckr Fix: I didn't do a general fix, as it's a simple problem and my style of fixing it may not what you'd prefer for your distribution. (Though I will if you want.) Owner: Status: obsolete ---------------------------------------------------------------------- Number: 926 Title: Array.extract of zero length is broken Keywords: Submitter: Elsa L. Gunter, elsa@research.att.com Date: 23 November 1994 Version: 106 System: SGI IRIX Release 5.2 IP19, sparcstation 2 SunOS Release 4.1.1 Severity: major Problem: Array.extract of zero length is broken Code: Array.extract (Array.arrayoflist ["a","b"],1,0); Transcript: radish% /usr/local/sml/106/bin/sml loading /usr/local/sml/106/bin/.heap/sml.mipseb ......................... done Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime] - Array.extract (Array.arrayoflist ["a","b"],1,0); /usr/local/sml/106/bin/sml[98]: 6133 Bus error Status: fixed in 107 ---------------------------------------------------------------------- Number: 927 Title: Compiler bug: getSigTSlots caused by include Keywords: Submitter: Kenneth Cline Date: 12/29/94 Version: 107 Severity: critical (for Fox code) Problem: There is a bug in 107 which causes the compiler to choke on included signatures that contain a type of the same name as a datatype declared earlier in the including signature. The transcript below should clearly demonstrate the bug. Transcript: cline@silver.fox% ../../bin/sml loading /afs/cs.cmu.edu/project/fox-7/member/cline/port/107/bin/.heap /sml.alpha32 ......................... done Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime] - signature sig0 = sig type t end; signature sig0 = sig type t end - signature sig1 = sig = datatype t = T = include sig0 (*sharing type t = t*) = end; Error: Compiler bug: getSigTSlots Comments: Please let me know when you fix the bug - I would like to patch my version with the fix. Fix: Changed the default case in the function f inside getSigTSlots to do nothing instead of calling impossible. The same slot is being initialized more than once because the !symbols list has duplicate names. These duplicate names are caused by a bug in the treatment of include specs in elabsig.sml. Status: fixed in 107.1(dbm) ---------------------------------------------------------------------- Number: 928 Title: double printing of datatype spec Keywords: Submitter: Dave MacQueen Date: 1/18/95 Version: 106 Severity: minor Problem: Datatype spec is printed twice. Code: (same as bug927.sml) signature sig0 = sig type t end; signature sig1 = sig datatype t = T include sig0 (*sharing type t = t*) end; Transcript: - use "bug927.sml"; [opening bug927.sml] signature sig0 = sig type t end signature sig1 = sig datatype t con T : t datatype t con T : t end val it = () : unit - Fix: [dbm] fix make_includespec in elabsig.sml so that duplicate names are not added to the symbols list when a type is (successfully) respecified by an included signature. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 929 Title: failure of respecifying type after include Keywords: Submitter: Ken Cline (Kenneth_Cline@cs.cmu.edu) Date: 1/19/95 Version: 0.93 through 107.1 Severity: major Problem: Included signatures are allowed to respecify a type, but only if the included type specification is a simple spec (not a datatype, or type definition(?)). Code: Transcript: - signature s = sig type t end; signature s = sig type t end - signature ss = sig datatype t = T; include s end; signature ss = sig datatype t con T : t datatype t (*duplicate printing is bug 928*) con T : t end - but - signature s = sig type t end; signature s = sig type t end - signature ss = sig include s; datatype t = T end; std_in:7.20-7.45 Error: duplicate specifications for type constructor t in signature - Comments: Fix: rewrite include treatment in elabsig.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 930 Title: "Fundef unused in freeClose" warning Keywords: Submitter: Lorenz Huelsbergen (lorenz@research.att.com) Date: 1/19/95 Version: 103 and above System: all Severity: seems minor Problem: internal compiler message "WARNING: Fundef unused in freeClose" generated when compiling (albeit unreachable) code Code: signature S_SIG = sig end structure S : S_SIG = struct fun f x = x fun g ([],[]) = f (g ([],[])) | g (x,[]) = f (g ([],[])) end Transcript: : radish 190; /usr/local/sml/103/bin/sml loading /usr/local/sml/103/bin/.heap/sml.mipseb ......................... done Standard ML of New Jersey, Version 1.03, February 14, 1994 [new runtime] - use "bug.sml"; [opening bug.sml] bug.sml:9.2-10.29 Warning: match nonexhaustive (nil,nil) => ... (x,nil) => ... GC #0.0.0.0.1.1: (51 ms.) WARNING: Fundef 207 unused in freeClose signature S_SIG = sig end structure S : S_SIG val it = () : unit - Comments: The above code is the smallest fragment I found that produces this warning; the signature, function f, and the tuples of list patterns all seem necessary to generate this. Code executes OK. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 931 Title: sharing constraints incorrectly resolved Keywords: Submitter: Elsa L. Gunter elsa@research.att.com Date: 22 December 1994 Version: 0.93 and 1.06.5 (at least) System: Sparcstation 2, SunOS 4.1.1, SGI (radish), IRIX Release 5.2 IP19 Severity: major Problem: The structure in a strdesc is being added to the basis before its sigexp body has been evaluated, causing sharing constrints to be incorrectly resolved. Code: structure A = struct datatype A = A end; signature S1 = sig structure B : sig type t sharing type t = A.A end end; signature S2 = sig structure A : sig type t sharing type t = A.A end end; signature S3 = sig structure B : sig type t sharing type t = B.t end end; Transcript: radish% ./sml loading /usr/local/sml/106.5/bin/.heap/sml.mipseb ......................... done Standard ML of New Jersey, Version 106.5, December 18, 1994 [new runtime] - structure A = struct datatype A = A end; structure A : sig datatype A con A : A end - signature S1 = sig structure B : sig type t sharing type t = A.A end end; signature S1 = sig structure B : ... sharing type B.t = A.A end - signature S2 = sig structure A : sig type t sharing type t = A.A end end; std_in:9.58-9.64 Error: unbound type constructor: A in path A.A - signature S3 = sig structure B : sig type t sharing type t = B.t end end; signature S3 = sig structure B : ... sharing type B.t = B.t end - Comments: * S1 works fine. * S2 should work the same as S1, but fails instead. This is because the real structure A has been hidden by the local structure A being specified, when it should not be. * S3 should fail since there is no structure B, and hence no type B.t. However it does succeed. [dbm] This is related to bugs 816, 817. Owner: dbm Test: bug931.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 932 Title: Compiler bug: applyTyfun: not enough arguments Keywords: Submitter: Andrew Appel Date: 2/10/95 Version: 107.2 Severity: critical Problem: Compiler bug caused by parameterized type abbrev in a signature Code: signature A = sig type 'a f = 'a end; structure B: A = struct type 'a f = 'a end; Code: (reported By Thomas Yan, 3/28/95) signature S = sig type 'a t = 'a list end structure T : S = struct type 'a t = 'a list end Transcript: - use "bug932.sml"; [opening bug932.sml] Error: Compiler bug: applyTyfun: not enough arguments - Owner: dbm Test: bug932.sml, bug932.1.sml Status: open ---------------------------------------------------------------------- Number: 933 Title: bogus message after explicit "raise Match" Keywords: Submitter: Andrew Appel Date: 2/10/95 Version: 107, etc Severity: minor Problem: If the user code says explicity "raise Match" then the global line number ref is not reset, so the message written is whatever it was set to in the compiler. Fix: the compiler, before running user code, should clear the ref. Owner: Andrew Status: open ---------------------------------------------------------------------- Number: 934 Title: Control.CG.misc4 when retargeting Keywords: Submitter: Lal George Date: 10/7/94 Version: 105 System: SGI/IRIX 5.2 (mipseb) Severity: ? Problem: Confusion of two versions of Control.CG.misc4 during retargeting compilation. Code: Transcript: script from sml-scb - Compiler.Control.CG.misc4; val it = ref 0 : int ref - - Retarget.retarget("/usr/local/sml/105/bin.mipseb",".mipseb"); .... structure SC_Cross : SEPARATE_COMPILATION structure Batch : BATCH val it = () : unit - - MipsBigVisComp.Control.CG.misc4:=128; val it = () : unit - - MipsBigVisComp.Control.CG.misc4; val it = ref 128 : int ref - - Compiler.Control.CG.misc4; val it = ref 128 : int ref Owner: Status: open ---------------------------------------------------------------------- Number: 935 Title: NaN from 0.0/0.0 is not caught Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 10/27/94 Version: 1.05 System: sparc Severity: major Problem: NaN from 0.0/0.0 is not caught Code: 0.0/0.0 Transcript: on SunOS 5.3 Generic_101318-59 sun4m: loading /amd/dusk/b/sml/src/105/bin/.heap/sml.sparc-solaris ......................... done Standard ML of New Jersey, Version 1.05, July 21, 1994 [new runtime] - 0.0/0.0; /amd/dusk/b/sml/src/105/bin/.run/run.sparc-solaris: Fatal error -- unexpected fault, signal = 8, code = 0x7 on SunOS 4.1.2 1 sun4m: loading /amd/dusk/b/sml/src/105/bin/.heap/sml.sparc-sunos ......................... done Standard ML of New Jersey, Version 1.05, July 21, 1994 [new runtime] - 0.0/0.0; /amd/dusk/b/sml/src/105/bin/.run/run.sparc-sunos: Fatal error -- unexpected fault, signal = 8, code = 0xd0 Process Inferior sml105 exited abnormally with code 1 Comments: not a problem in 0.93; other cases appear to be ok, e.g. NaN's from sqrt & ln, Overflow from x/0.0 Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 936 Title: failure translating abstype declarations Keywords: Submitter: Philip Santas (santas@inf.ethz.ch) Date: 11/7/94 Version: 0.93 Severity: major Problem: There is a compiler bug which involves abstypes defined in the body of a function f. If the function 'f' is called recursively in the body of the abstype (which is local) then a compiler bug is revealed. Code: fun foo x = let abstype t1 = T | F with fun goo y = foo T end in x end; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - fun foo x = = let abstype t1 = T | F = with = fun goo y = foo T = end = in x end; Error: Compiler bug: CoreInfo.coreLty3 - - fun foo x = = let abstype t1 = T | F = with = val goo = foo = end = in goo x end; Error: Compiler bug: CoreInfo.coreLty3 I do not know how the definition handles the above cases. The behaviour is normal in the following (different) case: - fun foo x = = let abstype t1 = T | F = with = fun goo y = T = end = in goo() end; In 109.19m, these now produce the following output - tuse "test/bugs/bug936.sml"; [opening test/bugs/bug936.sml] ** Lvar ** v1 is unbound *** Error: Compiler bug: CheckLty: unexpected lambda code in checkLty uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 test/evalloop.sml:202.20-202.23 - tuse "test/bugs/bug936.1.sml"; [opening test/bugs/bug936.1.sml] ** Lvar ** v1 is unbound *** Error: Compiler bug: CheckLty: unexpected lambda code in checkLty uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 test/evalloop.sml:202.20-202.23 In 109.25.2, the error has become uncaught exception in compiler: exception ltUnbound raised at: basics/ltyenv.sml:246.64-246.73 util/stats.sml:164.40 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:191.58 Comment: reopened dbm 11/15/96 Test: bug936.sml, bug936.1.sml Owner: Zhong Status: fixed in 109.27 [Zhong] ---------------------------------------------------------------------- Number: 937 Title: installing HOL90 on Alpha Keywords: Submitter: Kim Dam Petersen (kimdam@tdr.dk) Date: 11/14/94 Version: 106 System: DEC Alpha, OSF/1 Severity: major Problem: I have changed the system call code (as suggested by you for NJ/SML version 102 - it also works for 106). I have also changed string to char where needed. My first problem is that "System.Directory.listDir" is not implemented. This function is only used by "Lib.clean_directory", so I have solved this problem by manually cleaning the directory. My real problem is that the export file "hol90.01" generated by sys01.sml seems to be missing some links. It is not an executable file (as in 0.93 NJ/SML) so I use the command: sml @SMLload=hol90.01 to load it. This command does start something that looks like hol90: I get the hol90 prompt, and it recognizes the hol90 functions. But when I ask hol90.01 to install the first theory "restr_binder" it crashes! The call ``new_theory(..)'' works just fine, the next call ``new_definition(...)'' makes the system crash. By manually single-stepping the code I've located the crash to a call of ``strip_forall'' inside Const_def. Executing this application yields the execption "Boxity", which I assume is some internal NJ/SML exception. Owner: Status: open ---------------------------------------------------------------------- Number: 938 Title: Compiler bug: MipsCM.three: bad args, followed by core dump Keywords: Submitter: Henrik Reif Andersen, hra@id.dtu.dk Date: Wed Nov 16 09:02:33 MET 1994 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: DEC mips running ultrix Severity: major Problem: "Error: Compiler bug" Code: ~385049931 - 385049931; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - ~385049931 - 385049931; Error: Compiler bug: MipsCM.three: bad args - (); Illegal instruction (core dumped) Status: fixed in 106 (John Reppy) ---------------------------------------------------------------------- Number: 939 Title: confusing type error message Keywords: type checking, error message Submitter: John Reppy Date: 11/16/94 Version: 106 Severity: cosmetic Problem: Confusing type error message. Code: ... line 52 : val (i, _) = wrapIn (ins, BitmapIO.readBitmap) ... Transcript: widgets/util/tile-server.sml:52.17-52.62 Error: case object and rules don't agree (tycon mismatch) rule domain: 'Z * 'Y object: {hot_spot:?.Geometry.point option, image:?.Image.image} in expression: (case wrapIn (ins,readBitmap) of (i,_) => {1=i}) Owner: dbm Status: open ---------------------------------------------------------------------- Number: 940 Title: memory blowup caused by unmatched close comment Keywords: Submitter: Ravi Sethi Date: 11/20/94 Version: 0.83 Severity: major Problem: Runaway computation growing heap indefinitely caused by unmatched close comment. Transcript: - fun reduce f [] v = v = | reduce f (a::y) v = f(a, reduce f y v); val reduce = fn : ('a * 'b -> 'b) -> 'a list -> 'b -> 'b - reduce (op +) [1,2,3,4,5] 0; val it = 15 : int - reduce (op *) [1,2,3,4,5] 1; std_in:21.12 Error: unmatched close comment std_in:21.15 Error: syntax error found at LBRACKET - reduce; val it = fn : ('a * 'b -> 'b) -> 'a list -> 'b -> 'b - reduce (op *); std_in:22.12 Error: unmatched close comment [Major collection... [Increasing heap to 2858k] [Increasing heap to 3178k] [Increasing heap to 4778k] 90% used (2078900/2307716), 1120 msec] [Increasing heap to 8194k] [Major collection... [Increasing heap to 12582k] 94% used (4094228/4323420), 2470 msec] ... [Major collection... [Increasing heap to 176406k] 94% used (58298012/61484672), 35527 msec] [Increasing heap to 180138k] Interrupt - Comments: (Reppy, 11/20/94) This doesn't seem to be a problem in 106; maybe Andrew's changes to the parser fixed the problem. Status: fixed in 107.7 ---------------------------------------------------------------------- Number: 941 Title: x86 configuration problems Keywords: Submitter: Carsten Mueller Date: 11/21/94 Version: 106 System: x86, linux 1.0 (40MHz 386 with 8 MB RAM.) Severity: minor Problem: (1) The source dist (106-sml-nj.tar.Z) contains the heapfile sml.x86 which is > 2 MB compressed. So everybody not interested in x86 has to get it. (I needed it anyway, see (2).) (2) The little-endian x86 runtime cannot read big-endian binfiles written on big-endian machines (is this why you distribute sml.x86?). In order to avoid ftp-ing the bin.x86 dist, is there a way to (a) build binfiles without having old binfiles, or (b) build other-endian binfiles (e.g. sparc -> x86), or [preferrably] (c) get a patch to heap-??-util.c that is capable of byte swapping? The heap management and blasting are not very much documented, so I probably can't do it myself. BTW: Is there already a paper (or at least a draft or some plain textfile) on the new runtime (or the heap management), and if yes, how to obtain it? (3) You might think that bin/.arch-n-opsys doesn't need an i386 entry, but I still have such a box. It mentions only i[45]86. (If this is intentional: I think that SML *should* run on the i386. For details see the note below.) (4) config/install.sh calls SC's buildsc script without a path prefix. Please don't rely on people having `.' in their search path. Many omit it intentionally, and have to edit it into the scripts. Maybe this also applies to other scripts or Makefiles. Note for i386: About the only difference between an i486 and an i386 with 387 or math emulation should be speed. I am not aware of additional 486 or 586 instructions usable (or profitable to a significant degree) in a code generator for SML. Different alignment of jump targets or instruction scheduling won't affect backwards compatibility. Comments: [John Reppy] (1) That shouldn't have been there, but I think that there were a number of similar oversights. We will try to do better next time. (2) Unfortunately, byte-swapping doesn't work on heap images (and the blasted part of bin files), because there isn't enough information to get the swapping done right (consider reals vs. strings). The code part of a bin file has the right byte order, and it is possible to boot without using the environment part of the bin files (using the "-elab" option to xmakeml). The bin.x86 tar file should be little-endian. There is a paper (somewhat out of date) on the new GC part of the run-time; look in ftp.research.att.com:/dist/ml/papers. (3) I'll add the 386 to the script. (4) This is fixed in 107 [jhr]. Owner: John Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 942 Title: bad syntax error correction Keywords: Submitter: Kevin Skadron, Andrew Appel Date: 11/30/94 System(s) and Version: Compiler SML/NJ Version: 1.05a Machine: all Severity: minor Problem: bad syntax error correction Code: [Skadron] Why does ML-YACC say: semant.sml:130.11 Error: syntax error: inserting END ID IN semant.sml:437.7 Error: syntax error: inserting LET when I have let fun foo() = let in a (* note missing ; *) if/then/else end in end Comments: [Appel] Well, at the point of the missing semicolon, inserting END ID IN works as well as inserting a semicolon. The fact that this leads to another syntax error isn't discovered for another 300 lines. However, this isn't ideal. Shorter insertions (in this case, SEMICOLON) should be considered before longer ones. Fix: [Appel] Add "-> SEMICOLON |" to the beginning of the %change list in parse/ml.grm Perhaps other common insertions should also be added at that point, to give them higher priority. The "%prefer" list specifies high-priority insertions; but to make sure they have higher priority, it might be better to delete the %prefer list and just make all these into %change commands. Finally, it's necessary to check that the order that changes are listed in the %change list is really the order that Yacc prioritizes them. Status: fixed in 107.7 + ---------------------------------------------------------------------- Number: 943 Title: imploding a list containing a string containing a tab Keywords: Submitter: Andreas Sesterhenn (andreas@measoft.com) Date: 8/12/94 Version: 103 Severity: ? Problem: Try to evaluate the following code: implode["a b"]; where the character between a and b is a tab. The compiler returns: Error: Illegal non-printing character in string Comments: This worked under 0.93 and we have some code which is generated as strings _with_ tabs and then evaluated. This fails under 1.03. (Is that really necessary?) [Andrew Appel] This bug report is unrelated to "implode", just the string literal alone would do it. But this is not a bug, this is a change we made deliberately in order to conform with the Definition of Standard ML. This would work fine if you write "a\tb". Status: not a bug ---------------------------------------------------------------------- Number: 944 Title: sml .arch-n-opsys script Keywords: Submitter: Lorenz Huelsbergen Date: 11/7/94 Version: 105? Severity: major Problem: The 'sml' script calls a program '.arch-n-opsys' to determine the arch and opsys. '.arch-n-opsys' creates new shell commands to set ARCH and OPSYS appropriately and echos them. 'sml' then executes whatever '.arch-n-opsys' echoed. There's a potential problem however because executing '.arch-n-opsys' invokes the shell (and runs the user's .kshrc file or whatever) which may echo its own stuff before and after '.arch-n-opsys' executes. 'sml' may therefore not be able to execute the result of executing '.arch-n-opsys'. How about having '.arch-n-opsys' set the environment vars ARCH and OPSYS directly? Owner: John Status: not a bug [Lorenz may disagree] ---------------------------------------------------------------------- Number: 945 Title: opening a structure at top level reveals infix binding Keywords: Submitter: Manuel Fahndrich manuel@cs.berkeley.edu Date: December 1, 1994 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: HP-UX A.09.05 A 9000/715 Severity: minor Problem: Opening of structures w/o signatures containing infix declarations, preserves the infix at top-level (which it shouldn't according to NEWS). Opening the same structure inside another structure does not preserve the infix status, but "op" still works. Code: structure T = struct infix 3 || fun op || (x,y) = y fun foo n = n || 5 end; structure S = struct local open T in fun bar n = n || 7 val baz = op || end end; open T; val z = op ||; val y = ||; Transcript: structure T : sig val foo : 'a -> int val || : 'a * 'b -> 'b infix 3 || end structure S : sig val bar : (('a * 'b -> 'b) -> int -> 'c) -> 'c val baz : 'a * 'b -> 'b end open T val || = fn : 'a * 'b -> 'b val foo = fn : 'a -> int /tmp/ml001010:25.9-25.10 Error: nonfix identifier required Comments: The type of bar inside S is correct, i.e. || is not treated as infix. However baz, refers to op ||, which should be a syntax error. Then on toplevel, || is recognized as infix, but not as nonfix. When testing this example, make sure that || has no infix status at top level. This test works only once. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 946 Title: runtime assertion failure on x86-linux Keywords: Submitter: Carsten Mueller Date: 12/2/94 Version: 106 System: x86-linux version, compiled with gcc 2.4.5 (?) and -O2 -finline-functions. Severity: major Problem: It happened to me when trying to build the ML kit interpreter. GC #0.0.0.1.n.m: run.x86-linux: Assertion failure (cm->map[card] <= mark) at "major-gc.c:464" Looks like that was the first major collection to promote stuff from the first generation to the second. As SML/NJ 106 is not quite *Standard* ML, I had to redefine some stuff in the initial basis -- implode/explode and such. Source code for this follows. THe problem occurs whether using SML/NJ's arrays or not, so it is not related to these. The sparc version does not show this behavior. Code: (* Stuff to be loaded by 106 to make it *Standard ML* again. *) (* Does not take account of arrays and vectors. *) (* implode works correctly only for single-character strings (I need it just for this purpose). *) val sml_dump_file_name = "sml" (* Choose whatever you like. *) exception Ord exception Chr = Char.Chr val chr = str o Char.chr val ord = fn s => if (s = "") then raise Ord else (Char.ord o sub) (s,0) val explode = (map str) o explode (* CAUTION: this implode takes only the leading characters. *) and implode = implode o map (fn s => sub (s,0)) (* fun implode l = let fun imp [] s = s | imp (e::r) s = imp r (s ^ e) in imp l "" end; *) ; (exportML sml_dump_file_name; print Compiler.banner; print " [new runtime]\n[Standard ML stuff loaded]\n"); Comment: [jhr, 4/3/97] I'm not able to reproduce this one (and it will become obsolete with the new runtime). Owner: jhr Status: can't reproduce ---------------------------------------------------------------------- Number: 947 Title: Compiler bug: not found in spill Keywords: Submitter: Kenneth Cline Date: 12/7/94 Version: 106 System: DECstation 5000, Mach Severity: major Problem: My port 106 on MACH decstations fails to compile a program that compiles fine on the alpha/OSF1. The symptom is a compiler error: Error: Compiler bug: not found in spill Unfortunately, I have not been able to narrow this down to a small example which fails. A somewhat sizeable example (600kbytes tarred and gzipped) can be obtained by anonymous ftp from ftp.cs.cmu.edu:/afs/cs/project/fox/ftp/working/bug.tar.gz. Owner: Status: open ---------------------------------------------------------------------- Number: 948 Title: heap images too large Keywords: Submitter: Peter Sestoft (sestoft@research.att.com) Date: 12/9/94 Version: 105, 106 System: sparc Severity: major Problem: Making some comparisons of the size of executables, I have come across a possible `space leak' in the exportFn function of sml/nj 105 and 106. I compiled the humongous nucleic.sml benchmark program (3215 lines) and got these sizes for the exported executable: sml/nj 0.93: 3682336 bytes (exportFn, share, Sparc) sml/nj 0.93: 565280 bytes (exportFn, noshare, Sparc) sml/nj 1.05: 2349852 bytes (exportFn, Sparc) sml/nj 1.06: 2613012 bytes (exportFn, Sparc) The file is ~sestoft/sml/benchmarks/nucleic/x.sml [Zhong Shao, 1/8/95] In 107: the binary size for ml-yacc.rs6000 for RS6000 is only 0.58Mbytes for ml-yacc.sparc for sparc is nearly 2.8Mbytes on the other hand, ml-lex.rs6000 is 2.55Mbytes, ml-lex.sparc is 2.56Mbytes, which is consistent. Comments: I think 0.58Mbytes is the correct size for ml-yacc. All the rest potentially contain space leaks (due to exportML or exportFn) Owner: Status: open ---------------------------------------------------------------------- Number: 949 Title: bad type error caused by integer literal overloading Keywords: type checking, overloaded literals, error message Submitter: John Reppy Date: 12/11/94 Version: 106? Problem: The error messages for overloading conflicts are really bad in 106. For example: Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime] - 1.0+1; std_in:7.5 Error: expected numeric type found type: real - Compare this with 0.93: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - 1.0+1; std_in:2.1-2.5 Error: operator and operand don't agree (tycon mismatch) operator domain: real * real operand: real * int in expression: + : overloaded (1.0,1) - Another report by Peter Sestoft (3/29/95). The expected and the actual type seem to be swapped in the following error message: - fun g s i = size s + i; val g = fn : string -> int -> int - g 12; std_in:46.1-46.4 Error: expected numeric type found type: string This also looks puzzling; note the explicit type ascription at the literal 12: - g 12 ""; std_in:0.0-0.0 Error: operator and operand don't agree (tycon mismatch) operator domain: int operand: string in expression: g (12 : string) "" std_in:0.0-0.0 Error: expected numeric type found type: string Another report by Robert Findler : > - datatype num = zero | one_more_than of num; > datatype num = one_more_than of num | zero > - one_more_than(0); > stdIn:33.15 Error: expected integer type, > found type: num This error message seems to have the wrong sense. Comments: Most people consider real to be a numeric type! Fix: introduced LITERAL variant of tvinfo (in Types). Overloaded literals now initially get a type which is a LITERAL tyvar, with an appropriate kind (litKind = INT | WORD | REAL | CHAR | STRING). Tests: bug949.1.sml, bug949.2.sml, bug949.3.sml Owner: dbm Status: fixed in 109.26 [dbm] ---------------------------------------------------------------------- Number: 950 Title: signature matching clobbers inline status Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 12/12/94 Version: (?) all through 1.06.3 Severity: minor Problem: signature matching clobbers inline status Code: littered throughout the compiler Comments: this was never entered as a bug; consequently, every release i wonder if this has been dealt with. since there are comments all over the compiler about this bug, i assume it still exists. Owner: Zhong Status: fixed in 109.23 [109.19m] ---------------------------------------------------------------------- Number: 951 Title: configuration problems, suggestions Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: Dec 14 1994 System(s) and Version: Compiler, Runtime, Installation SML/NJ Version: 106.3 Machine: SPARC, Solaris2 Severity: minor Problem: 1. The treatment of EXTRA_LIBS in the runtime/objs/ makefiles is incorrect. `makefile' adds $(EXTRA_LIBS) (via $(LIBS)) as a dependency for the $(RUNTIME) target. This is wrong for such libraries that are specified using `-l' syntax, as found in mk.sparc-solaris and a few other makefiles. I suggest splitting EXTRA_LIBS into SYS_LIBS and EXTRA_LIBS, such that `-l' specifications go into SYS_LIBS, and `.o' and `.a' specs go into EXTRA_LIBS. `makefile' should then only add $(EXTRA_LIBS) (not $(SYS_LIBS)) to the dependencies for $(RUNTIME). Both sets of libraries are used for linking though. 2. config/install.sh wrongly assumes that $PATH includes `.'. A simple fix is to rewrite the various calls to the `build' scripts to use the unambiguous notation `./build' instead. 3. I prefer to use Gnu ZIP instead of compress, since it tends to do a much better job than old compress. The following patch allows config/unpack.sh to recognize gzipped archives (a similar patch is needed for install.sh as well): *** config/unpack.sh.~1~ Mon Nov 14 19:45:10 1994 --- config/unpack.sh Mon Nov 28 19:46:23 1994 *************** *** 13,18 **** --- 13,22 ---- cd $SRCDIR echo "unpacking $OBJECT source files" zcat $TARFILE.Z | tar -xf - + elif [ -r $TARFILE.gz ]; then + cd $SRCDIR + echo "unpacking $OBJECT source files" + gunzip < $TARFILE.gz | tar -xf - elif [ -r $TARFILE ]; then cd $SRCDIR echo "unpacking $OBJECT source files" 4. The heap images produced using `exportFn' tend, for my applications, to be 3-4 times larger than in SML/NJ 1.03f or 0.93 . What used to be a 950K image is now over 3M, and ml-lex has grown from 400K to 2.5M! This also makes application start-up markedly slower. It appears that `exportFn' considers far too many objects to be live. (It is also a real pain having to deal with separate heap image files, runtimes, and scripts, but I suppose there are technical reasons for not producing a.out-ish executables any more.) Comment: [John Reppy] Point 1: This has been fixed in 107. EXTRA_LIBS are user libraries, while the "-l" libraries are specified by LD_LIBS. Point 2: Same as point 4 of bug 941. It has been fixed in 107. Point 3: I think that we will continue to use compress to distribute our files, since it is more accessable (there are sites that don't have Gnu stuff installed). Point 4: this is probably the same as bug 948 [dbm]. Status: fixed in 107 (except for Point 4) ---------------------------------------------------------------------- Number: 952 Title: unsound imperative types Keywords: type checking, value restriction, core dump Submitter: Philip Santas (santas@inf.ethz.ch) Date: 12/16/94 Version: 93, 106 System: SPARC (it shouldn't matter) Severity: major Problem: Unsound imperative types Imperative type variables with integer strengths do not work well with type parameters in functors A workaround in the end. Code: local val ll = ref [] in functor F(type t val x:t) = struct val l = (ll := x :: (!ll); !ll) (* here ll gets the type ll : t list ref *) end end; structure S1 = F(type t = int val x = 4); structure S2 = F(type t = int->int val x = fn x => x); hd(tl(S2.l)) 3 (* Applies an integer to an integer ... *) Result: Bus error Comments: The scope of 't is from its right to the first "end". but it manages to participate in the type of ll. Probably constraing scopes like this for type variables is too much. There is a workaround though: Since 't is not an abbreviation, try to do typing with t = 'a when t escapes (ie. it should be viewed as a type variable out of the functor definition in case of no abbreviations) and then imperative type variables are at work. For instance, the following is not accepted: local val ll = ref [] in functor F(type 'a t val x:'a t) = struct val l = (ll := x :: (!ll); !ll) end end; reporting Error: nongeneric weak type variable l : '0Y t list (actually, the error should occur at "ll"). Instead of increasing the arity of t, it could be directly replaced by 'a *out* of its scope --otherwise we would get errors in the safe code functor F(type t val x: t) = struct val ll = ref [] val l = (ll := x :: (!ll); !ll) end Comment: [dbm] Same as bug 905. Fix: A "local" form for functor declarations is not part of SML 90 or SML 96. Eliminating this syntactic form should fix the bug. Owner: dbm Test: bug952.sml Status: fixed in 109.26 ---------------------------------------------------------------------- Number: 953 Title: Compiler bug: Extern: extern_sharing_tyc (sharing on functor type args) Keywords: Submitter: Philip Santas (santas@inf.ethz.ch) Date: 12/16/94 Version: 93, 106 System: SPARC Severity: minor Problem: Compiler Bug when specifying sharings on functor type arguments Transcript: - functor F(type t1) (type t2 sharing type t1=t2 sharing type t1 = int) = struct end; Error: Compiler bug: Extern: extern_sharing_tyc Comments: These sharings should not be allowed anyway. The reason is that the sharing t1=int should occur when t1 was declared, ie. in: functor F(type t1 sharing type t1=int) (type t2 sharing type t1=t2) = struct end; Owner: dbm Test: bug953.sml Status: fixed in 109.20 ---------------------------------------------------------------------- Number: 954 Title: unsound signatures with type abbreviations Keywords: Submitter: Philip Santas (santas@inf.ethz.ch) Date: 12/16/94 Version: 106 System: SPARC Severity: major Problem: Unsound Signatures with Type Abbreviations Code: signature S1 = sig type t = int val x:t end signature S2 = sig type t = string end signature S3 = sig include S2 include S1 end; abstraction M3:S3 = struct type t=real val x=3.4 end; (* ACCEPTED! *) M3.x ^ "Memory fault"; Comments: I do not understand what signature S3 includes. It seems to me that (a) it should be rejected due to incompatible abbreviations (b) if it is to be accepted, then what is 't? int or string or any? Owner: dbm Test: bug954.sml Status: fixed in 109.20 (causes duplicate spec error) ---------------------------------------------------------------------- Number: 955 Title: Compiler bug: PPVal.switch: none of the datacons matched (Compiler) Keywords: Submitter: Bob Harper Date: 12/30/94 Version: 0.93 Severity: major Problem: I'm trying to hack up a string parser for SML expressions parse : string -> System.Ast.exp using the primitives in System.Compile, System.Env, and System.Ast. So far no luck. Here's what I do for testing purposes: val ppc = { linewidth=80, flush = fn () => flush_out std_out, consumer = outputc std_out }; (* the first two arguments to makeSource are a total guess because the documentation doesn't explain what the hell they are! instead it goes on about whether the fourth argument is necessary or not and whether the first ought to be an option.*) fun mk_source s = System.Compile.makeSource ("exp", 100, open_string s, false, ppc); val pervEnv = System.Env.staticPart (!System.Env.pervasiveEnvRef); fun parse s = System.Compile.parse (mk_source s, pervEnv); But parse "43" bombs with the message above. Comment: probably obsolete. Owner: dbm Status: open ---------------------------------------------------------------------- Number: 956 Title: Compiler bug: empty data types in equal.sml Keywords: Submitter: Roderick Moten Date: 1/5/95 Version: sml-sc 106.3 System: sparc Severity: major Problem: When testing for equality of two values of non-equal type the following message appears: Error: Compiler bug: empty data types in equal.sml Code: See /usr/local/sml/bugs/moten/bug. The file transcript contains the transcript, the rest of the directory contains the code. Owner: dbm Status: unreproducible [dbm, 4/16/97] ---------------------------------------------------------------------- Number: 957 Title: scoping of explicit type variables Keywords: Submitter: Peter Sestoft (sestoft@research.att.com) Date: 1995-01-06 Version: 0.93 and 106 System: presumably all (since it is a static semantics pbm.) Severity: major deviance from the Definition, few users will encounter the problem Problem: Explicit type variables are not handled (scoped?) correctly. Code: val f = fn x => let val b = fn (y:'_a) => y in x b end; Transcript: The following should elaborate, but does not: - val f = fn x => let val b = fn (y:'_a) => y in x b end; std_in:0.0-0.0 Error: nongeneric weak type variable b : '1aU -> '1aU Comments: It looks like a problem in the scoping of explicit type variables in nested valbinds, since b and f can be defined at top-level without complaints: - val b = fn (y:'_a) => y; val b = fn : '1a -> '1a - val f = fn x => x b; val f = fn : (('1a -> '1a) -> 'b) -> 'b and also, the program is accepted if the explicit type variable is deleted: - val f = fn x => let val b = fn y => ref y in x b end; val f = fn : (('1a -> '1a ref) -> 'b) -> 'b In the original code fragment, the type '_a -> '_a of b *can* be generalized because the rhs of `val b =' is non-expansive, and '_a does not occur in the context. Moreover, '_a *must* be generalized, or else the second side condition in rule 17 fails, since '_a is scoped at `val b' (Definition section 4.6). (BTW, I have compiled ML Kit 1.0 for SGI MIPS in /usr/local/sml/mlkit/bin/mips.irix5/kit Although it isn't the final authority on the matter, it is a handy tool in finding out whether one's interpretation of a piece of SML code is right). Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 958 Title: Ctrl-Z under AIX 4.1 Keywords: Submitter: Zhong Shao (shao-zhong@cs.yale.edu) Date: January 8, 1995 Version: 107 System: RS6000 with AIX 4.1 Severity: severe Problem: Ctrl-Z under AIX 4.1 Code: > sml ctrl-Z > fg ...... Transcript: - uncaught exception Io "Input "": read failed, I/O error" - uncaught exception Io "Input "": read failed, I/O error" - uncaught exception Io "Input "": read failed, I/O error" - uncaught exception Io "Input "": read failed, I/O error" - ................. Comments: Sometimes it works. Sometimes the above infinite loop occurs. [John Reppy, 1/8/95] This is interesting. I have seen a similar problem under Irix 4.0.5, but it disappeared in Irix 5, so I didn't track it down. It is most likely a new-runtime bug. I'll try to fix the Irix 4 problem, which I hope will also fix the AIX 4 problem (I think that we are still running AIX 3.2). Owner: Status: obsolete ---------------------------------------------------------------------- Number: 959 Title: core dump on unboxed float record Keywords: Submitter: Zhong Shao (shao-zhong@cs.yale.edu) Date: January 17, 1995 Version: 106.4, 107 System: RS6000, MIPS and SPARC Severity: severe Problem: core dump on unboxed float record Code: Transcript: sml - (4.0,4.0); core dump .... Comments: The pretty printing (in ppval.sml) on unboxed float record value is wrong. It assumes that the unboxedfloat record uses "realdArray" tag, but it actually uses "tag_string". Fix: This bug is now fixed. The fix has to cast a string into a realdArray, which is ugly. In the future when the new runtime system can fully support tag_realdArray or a new tag for unboxedfloat, the above can be cleaned up. The new "ppaval.sml" will be sent to you in my next message. Status: fixed in 107.7 ---------------------------------------------------------------------- Number: 960 Title: infinite loop on floating Div exception Keywords: Submitter: Zhong Shao (shao-zhong@cs.yale.edu) Date: January 17, 1995 Version: 107 System: on SPARC (solaris) and RS6000 Severity: severe Problem: infinite loop on floating Div exception Code: - 4.0 / 0.0; Transcript: sml - 4.0 / 0.0; GC #0.0.0.0.1.1: (40 ms.) GC #0.0.0.1.2.9: (2010 ms.) GC #0.0.1.2.3.10: (490 ms.) GC #0.1.2.3.4.17: ^C (4010 ms.) ... starting infinite loop ... Comments: This bug only occurs in version 107 (it raises the exception correctly in both version 106 and 106.4). Even on 107, it seems to work on Alpha. What changes have been done from 106.4 to 107? integer division works fine; 3 div 0 would still raise the Div exception. [John Reppy] I reorganized the signal code in 107, so maybe I introduced the bug. Owner: John Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 961 Title: include type overlaying [same as 929] Keywords: Submitter: Kenneth Cline Date: 1/19/95 Version: 107 Severity: major Problem: Respecification of a simple type spec introduced by include is not allowed. Code: Transcript: Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime] - signature s = sig type t end; signature s = sig type t end - signature ss = sig include s; datatype t = T end; std_in:7.20-7.45 Error: duplicate specifications for type constructor t in signature - Comments: According to the _Definition of Standard ML_ this should be legal (with the latest spec remaining visible). I'm trying a simple fix for this bug (removing the error test from fun bind in elavorate/elabsig.sml). If this is seen as an important feature, maybe it should be made an optional warning. Comment: [dbm] Same as bug 929. Owner: dbm Test: bug961.sml Status: open ---------------------------------------------------------------------- Number: 962 Title: debugging warning message left in [duplicate of 930] Keywords: Submitter: Lorenz Huelsbergen (lorenz@research.att.com) Date: 1/19/95 Version: 103 and above System: all Severity: seems minor Problem: internal compiler message "WARNING: Fundef unused in freeClose" generated when compiling (albeit unreachable) code |> Code: signature S_SIG = sig end structure S : S_SIG = struct fun f x = x fun g ([],[]) = f (g ([],[])) | g (x,[]) = f (g ([],[])) end Transcript: radish 190; /usr/local/sml/103/bin/sml loading /usr/local/sml/103/bin/.heap/sml.mipseb ......................... done Standard ML of New Jersey, Version 1.03, February 14, 1994 [new runtime] - use "bug.sml"; [opening bug.sml] bug.sml:9.2-10.29 Warning: match nonexhaustive (nil,nil) => ... (x,nil) => ... GC #0.0.0.0.1.1: (51 ms.) WARNING: Fundef 207 unused in freeClose signature S_SIG = sig end structure S : S_SIG val it = () : unit - Comments: The above code is the smallest fragment I found that produces this warning; the signature, function f, and the tuples of list patterns all seem necessary to generate this. Code executes OK. [Zhong Shao] John pointed this out to me a while ago, but I forgot turning the warning message off (it is printed during the closure analysis, in "cps/nfreeclose.sml"). It has no effect on correct execution of the program. I'll send Lal the modified "/cps/nclosure.sml" file (which fixes the above) to be included in 108. Thanks, Comment: duplicate of bug 930. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 963 Title: including signatures produces Compiler bug: getSigTSlots Keywords: Submitter: Roderick Moten Date: 1-30-95 Version: 107 System: Sun Sparc IPC / Sun OS Severity: major Problem: including signatures Code: signature l = sig type i val k : unit -> i val j : i * i -> i end; signature k = sig type i val k : unit -> int * i val j : i * i -> i end; Transcript: - signature p = sig include l include k end; std_in:35.19-35.38 Error: duplicate specifications for variable or constructor k in signature std_in:35.19-35.38 Error: duplicate specifications for variable or constructor j in signature Error: Compiler bug: getSigTSlots Owner: dbm Test: bug963.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 964 Title: Compiler bug: applyTyfun: not enough arguments (compiling functor) Keywords: Submitter: Edo Biagioni (esb@KITSUNE.FOX.CS.CMU.EDU) Date: 1/30/95 Version: 106? 107? Severity: major Problem: The bug appears to be related to having parametrized type abbreviations being used in contexts where the parameter is not defined, i.e. polymorphic; see the signature S below. The compiler error message is: Error: Compiler bug: applyTyfun: not enough arguments Code: (bug964.sml) signature S = sig type 'a T = 'a val f: 'a T -> unit end (* sig *) (* either the functor or the structure (or both) will exercise the error. *) functor F (structure L: S): S = struct open L end structure ST: S = struct type 'a T = 'a fun f x = () end (* another example from Ken Cline *) (bug964.1.sml) signature DECL = sig type 'a snark = 'a list datatype x = Y of int snark end; functor Test (structure Decl: DECL) = struct fun test (Decl.Y _) = () end; Comment: possibly related to bug 932. Here is a short example from Robert Findler (3/13/95) that doesn't involve functors and produces the same error message (in 107 and 107.7): (bug964.2.sml) - structure S : sig type 'a t = 'a end = struct type 'a t = 'a end; Error: Compiler bug: applyTyfun: not enough arguments Owner: dbm Test: bug964.sml, bug964.1.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 965 Title: redundant datatype error message Keywords: Submitter: appel Date: Feb 1, 1995 System(s) and Version: SML/NJ SML/NJ Version: 107.2 Machine: all Severity: minor Problem: Redundant datatype error message Code: functor F (datatype a = A of int * int) = struct end structure S = F(datatype a = A of int) Transcript: - use "foo.sml"; [opening foo.sml] foo.sml:3.15-3.38 Error: The constructor A of datatype a has different representations in the signature and the structure. Change the definition of the types carried by the constructors in the functor formal parameter and the functor actual parameter so that they are both abstract, or so that neither is abstract. foo.sml:3.15-3.38 Error: value type in structure doesn't match signature spec name: A spec: int * int -> _ actual: int -> a Comments: The first error message (about representations) should not appear if there is a genuine semantic error. Owner: dbm Status: obsolete ---------------------------------------------------------------------- Number: 966 Title: parsing large comments blows compiler away Keywords: Submitter: Ken Zadeck zadeck@watson.ibm.com Date: 2/2/95 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: RS6000, AIX Severity: minor though embarrassing Problem: parsing large comments blows compiler away Code: any 800k comment (* nested comments not required *) Comments: we had commented out a large piece of computer generated code. Transcript: - use "comment2.sml"; [opening comment2.sml] [Major collection... 38% used (2552312/6692292), 490 msec] [Major collection... 86% used (5492516/6366364), 1230 msec] [Increasing heap to 18652k] [Major collection... [Increasing heap to 28728k] 88% used (9290916/10497588), 2240 msec] ... [Increasing heap to 127548k] [Increasing heap to 127576k] [Increasing heap to 127604k] Warning: can't increase heap Ran out of memory Status: fixed ("in recent versions" - Appel) ---------------------------------------------------------------------- Number: 967 Title: Compiler bug: translate.transpath on unexpected access Keywords: Submitter: John Reppy (jhr@research.att.com) Date: Feb 3, 1995 System(s) and Version: Compiler SML/NJ Version: 107.2 Machine: any Severity: minor Problem: When compiling stuff in the sml-nj/boot directory I got Error: Compiler bug: translate.transpath on unexpected access Transcript: Repairing blast GC (maxGen = 5 of 5) [wrote bin.mipseb/NEWbuilt-in.sml.bin] Error: Compiler bug: translate.transpath on unexpected access !* CM error: (sorry, can't be more specific) Comments: The problem was a reference to PrimTypes; changing that to PrimTypes1 fixed the problem, but a better error message would be nice. Owner: Status: open ---------------------------------------------------------------------- Number: 968 Title: overflow is not detected for integer subtraction Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 2/10/95 Version: 0.93 System: Sparc IPC, both SunOS 4.1.1 and Solaris 5.3 Severity: major Problem: Overflow is not detected for integer subtraction Code: fun t (a:int) c = a-c; Transcript: - op - (1072807032,~2496144); uncaught exception Overflow (* however: *) - fun t (a:int) c = a-c; val t = fn : int -> int -> int - t 1072807032 ~2496144; val it = ~1072180472 : int (* NOTE: exception is raised in 1.07 under SunOS *) Comments: This might be a duplicate of 780. I detected this by a simultaneous execution of bigint code from the sml-nj-lib; to my surprise, instead of finding no bugs or a bug in the bigint code, i found this problem with the small int code! Owner: John Status: fixed in 109.21 [new basis] ---------------------------------------------------------------------- Number: 969 Title: error in function recordDesc in cpscompile/ctreeify.sml Keywords: Submitter: Kenneth Cline Date: 2/13/95 Version: 107.7 Severity: major Problem: The function recordDesc in cpscompile/ctreeify.sml had the clause for pairs "(_, 2)" listed before the clause for blocks of int32's "(Access.RK_I32BLOCK, _)". In practice, this meant that the closure phase created pairs of int32's using desc_pair for the descriptor instead of tag_string. This resulted in warnings of the form: /afs/cs.cmu.edu/project/fox-7/member/cline/port/107/bin/.run/run.alpha32-osf1: Error -- external address 0x8000 not registered during exportML, and is suspected to have caused segmentation violations. Fix: A corrected version of recordDesc appears below. ctreeify.sml: fun recordDesc (kind, content) = let val l = List.length content in case (kind, l) of (Access.RK_VECTOR, _) => T.make_desc (l, T.tag_record) | (Access.RK_FCONT, _) => T.make_desc (l*4, T.tag_string) | (Access.RK_FBLOCK, _) => T.make_desc (l*4, T.tag_string) | (Access.RK_I32BLOCK, _) => T.make_desc (l*4, T.tag_string) | (_, 2) => T.desc_pair | _ => T.make_desc (l, T.tag_record) end Owner: Lal Status: fixed in 109.25.x [Lal] ---------------------------------------------------------------------- Number: 970 Title: Warning: binding contains no variables Keywords: Submitter: Lal George Date: 2/14/95 Version: 107.4 System: all Severity: minor Problem: Warning: binding contains no variables Code: datatype 'a tbl = H of {t: 'a Array.array, s:int}; fun new(n,a) = H{t=Array.array(n,a), s=n}; val c : int tbl = if false then new(32,0) else new(32,100); Andrew suggests this even simpler version val a: int = if false then 1 else 2; Transcript: - datatype 'a tbl = H of {t: 'a Array.array, s:int}; datatype 'a tbl con H : {s:int, t:'a array} -> 'a tbl - fun new(n,a) = H{t=Array.array(n,a), s=n}; val new = fn : int * 'a -> 'a tbl - val c : int tbl = if false then new(32,0) else new(32,100); std_in:36.1-36.58 Warning: binding contains no variables <<<<<<------ true = ... val c = H {s=32,t=[|100,100,100,100,100,100,100,100,100,100,100,100,...|]} : int tbl - Comments: I have no idea what the warning message is complaining about. This does not occur in 0.93. Fix: [Andrew] Try this fix (though I'm not quite sure about it): In elaborate/elabcore.sml, replace the "bindpat" function with this: fun bindpat pp = case pp of VARpat(VALvar{access=INLINE(_),...}) => false | VARpat(VALvar{access=LVAR v,...}) => false | CONSTRAINTpat(p,_) => bindpat p | MARKpat(p,_) = bindpat p | _ => true Status: fixed in 107.7 + ---------------------------------------------------------------------- Number: 971 Title: -p is not a legal option for uname Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 2/15/95 Version: 1.07, .arch-n-opsys script System: sparc, solaris Severity: Problem: -p is not a legal option for uname Comments: I don't know if this is just our local setup, but uname -p also does not work on our sunos sparcs. Fix: (Workaround?) assume sunos means sparc, and delete the uname -p check. Owner: John Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 972 Title: memory fault caused by errors in cpscompile/mltreeGen.sml Keywords: Submitter: Kenneth Cline Date: 2/17/95 Version: 107, 107.4 Severity: major Problem: The semantic actions reg_MKSPECIAL_ureg_reg and reg_SETSPECIAL_reg_ureg in cpscompile/mltreeGen.sml were implemented incorrectly. Diffs for a corrected version (from SML/NJ 107, _not_ 107.4) appear below. Here is an example of what happens without the fix: Transcript: Standard ML of New Jersey, Version 107, December 25, 1994 [Batch SC 69(jhr)] val it = () : unit - datatype U = Empty | Delay of int; datatype U con Delay : int -> U con Empty : U - System.Unsafe.Susp.force (System.Unsafe.Susp.delay (fn _ => Empty)); /afs/cs/project/fox/member/cline/port/107/bin/sml-scb[99]: 20275 Memory fault Fix: *** 1.1 1995/02/16 16:00:29 - --- mltreeGen.sml 1995/02/16 18:42:41 *************** *** 658,664 **** in GPR (M.SEQ (first, M.SEQ (second, ! M.SEQ (M.MV (tmp, C.allocptr), M.SEQ (M.MV (C.allocptr, M.ADD (C.allocptr, M.LI 8)), tmp))))) end - --- 658,664 ---- in GPR (M.SEQ (first, M.SEQ (second, ! M.SEQ (M.MV (tmp, M.ADD (C.allocptr, M.LI 4)), M.SEQ (M.MV (C.allocptr, M.ADD (C.allocptr, M.LI 8)), tmp))))) end *************** *** 923,931 **** | (Burm.reg_SETSPECIAL_reg_ureg kids, EX(_,_,order)) => let val (GPR r1, GPR r2, ord) = walk2 (kids, order) - - val sw = if ord=M.LR then (fn x => x) else (fn (a,b,c)=>(b,a,c)) in ! NOTHING (M.STORE32 (r1, (* XXX incorrect *) M.ORB (M.SLL (r2, M.LI T.width_tags, M.LR), - --- 923,930 ---- | (Burm.reg_SETSPECIAL_reg_ureg kids, EX(_,_,order)) => let val (GPR r1, GPR r2, ord) = walk2 (kids, order) in ! NOTHING (M.STORE32 (M.SUB (r1, M.LI 4, M.LR), M.ORB (M.SLL (r2, M.LI T.width_tags, M.LR), Owner: Status: open ---------------------------------------------------------------------- Number: 973 Title: datatypes aren't generative Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 2/18/95 Version: 1.07 System: sparc Severity: minor (? major -- unlikely to cause errors?) Problem: datatypes aren't generative Code: datatype a=A; val a=A; fun f A = 7; datatype a=A; f a Transcript: (* note: different behavior if batch-compile this instead of typing it in line by line *) - datatype a = A; datatype a con A : a - val a = A; val a = A : a GC #0.0.0.0.1.1: (10 ms.) - fun f A = 7; val f = fn : a -> int - datatype a = A; datatype a con A : a (* should have a = A:?.a, f a = 7, f A undefined *) - a; val it = A : a - f a; val it = 7 : int - f A; val it = 7 : int (* note that pretty-printing is messed up *) - datatype b = A; datatype b con A : b - a; val it = A : a (* however, compiler correctly rejects f A *) - f A; std_in:18.1-18.3 Error: operator and operand don't agree (tycon mismatch) operator domain: a operand: b in expression: f A Comments: declaring new constructors, e.g. datatype a = A | B, seems to unconfuse the compiler. this is almost a feature: reloading the same datatype declaration does not invalidate code already compiled. i haven't tested it, but maybe this means that functor application doesn't create new types, either. Owner: dbm Status: not a bug [it's a feature] ---------------------------------------------------------------------- Number: 974 Title: running sc.make multiple times produces different sized heap images Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 2/18/95 Version: 1.07 System: sparc, solaris 5.3 Severity: minor Problem: running sc.make () multiples times with different files loaded produces different size heap images and or fails to compile. Code: omitted; i dont' know how to isolate the problem. i can send tar file... Transcript: here's a more complete description. we have installed sml with sc (sml-sc) and compiled .bin files for smlnj-lib/107-sources.sc, cml, and exene. i have exported a heap file with all of the latter three included (exene-sc). i then compiled AML with modifications for 1.07 with sc.make() under exene-sc. successive runs first produce a heap image of size 4721088; subsequent runs have size 3271276. however, under sml-sc, compilation does not get very far (note that i've tried sc.make() twice): loading /usr/u/sml/src/107/bin/.heap/sml-sc.sparc ......................... done Standard ML of New Jersey, Version 107, December 25, 1994 [SC 69(jhr)] val it = () : unit - sc.make(); GC #0.0.0.0.1.1: (0 ms.) Defining the group... [scanning sources.sc] [scanning /usr/u/sml/src/107/src/smlnj-lib/107-sources.sc] Compiling... GC #0.0.0.0.2.35: (0 ms.) GC #0.0.0.0.3.72: (10 ms.) GC #0.0.0.0.4.133: (10 ms.) GC #0.0.0.0.5.194: (10 ms.) GC #0.0.0.0.6.286: (10 ms.) GC #0.0.0.1.7.404: (30 ms.) GC #0.0.0.1.8.499: (10 ms.) GC #0.0.0.1.9.614: (20 ms.) [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/finalize-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/100-finalizer.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/100-time-limit.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/lib-base-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/106-lib-base.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array-qsort.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array-sort-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array2-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array2.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/ord-key-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/dict-sig.sml.bin] GC #0.0.0.1.10.630: (50 ms.) [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/binary-dict.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/ord-set-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/binary-set.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/106-ctype-sig.sml.bin] [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/106-ctype.sml.bin] lookup cHC+ dTrkUa3 lookupyNi1;l Aotr lookup ,y5Z?D)m6f Date: 2/18/95 Version: 107.4? System: x86 Severity: major Problem: All versions of the x86 codegen generate incorrect code in some (seemingly rare) cases of storeindexb. This bug may have to do with the recent problems in compiling the compiler with cm in 107.4. I do not have a small example that generates this bug -- it occurred when stack-frame based virtual registers were added to the x86 CG and then only when loading the compiler's bin files. Fix: in x86/x86.sml, in function storeindexb, add a tick: | (Direct y', Displace _) => (V.movl (z,tempreg); storeb' (x,Index (y',0,tempreg',Byte))) (* was: storeb (x,Index (y',0,tempreg',Byte))) *) Owner: Lorenz Status: fixed ---------------------------------------------------------------------- Number: 976 Title: x / 0.0 causes infinite(?) consing loop Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: Feb 21, 1995 System(s) and Version: SML/NJ Version: 107 Machine: SPARC Solaris 2.4 Severity: major Problem: x / 0.0 causes infinite(?) consing loop Code: 1.0 / 0.0; Transcript: Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime] - 1.0 / 0.0; GC #0.0.0.0.1.1: (60 ms.) GC #0.0.0.1.2.9: (3030 ms.) GC #0.0.1.2.3.10: (640 ms.) GC #0.1.2.3.4.17: (6130 ms.) GC #1.2.3.4.5.18: (6630 ms.) ^C Interrupt - ^D GC #2.3.4.5.6.24: (180 ms.) Comment: [John Reppy] This may be related to problems with imprecise interrupts on the SPARC. There are already some bug reports about this in the masterbugs file. Owner: John Status: obsolete [new basis] ---------------------------------------------------------------------- Number: 977 Title: sml > "a non-tty device" can cause GC failures Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: Feb 21, 1995 System(s) and Version: runtime SML/NJ Version: 107 Machine: SPARC, Solaris 2.4 Severity: minor Problem: sml > "a non-tty device" can cause GC failures Code: (many KLOC; too large to send) Transcript: A colleague of mine has a medium-size SML program (> 5 KLOC). He "use"d the sources and exported an image. When executing this image with stdout referring to a tty device, everything goes well. Executing with stdout redirected to /dev/null or some other non-tty device causes the message below: GC #0.0.0.0.1.1: (0 ms.) GC #0.0.0.1.2.16: /u/pelab/sml/bin/.run/run.sparc-solaris: Fatal error -- unknown tag 0xa @ 0xeeba00b4 in array arena Owner: Status: open ---------------------------------------------------------------------- Number: 978 Title: Compiler bug: getSigTSlots from duplicate type specs Keywords: Submitter: Roderick Moten Date: 2/22/95 Version: 107 System: Sparc 10, SunOS Severity: minor Problem: Error: Compiler bug: getSigTSlots Code: signature k = sig type k type k = int end; Transcript: - signature k = sig type k type k = int end; std_in:0.0-14.9 Error: duplicate specifications for type constructor k in signature Error: Compiler bug: getSigTSlots Owner: dbm Test: bug978.sml Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 979 Title: creating `real'-only tuple causes SIGSEGV Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: Feb 26, 1995 System(s) and Version: SML/NJ Version: 107 Machine: SPARC - Solaris 2.4 and SunOS 4.1.3; SGI - IRIX 5.2 Severity: major Problem: creating `real'-only tuple causes SIGSEGV Code: {1=15.0} Transcript: Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime] - {1=15.0, 2=3}; val it = (15.0,3) : real * int - {1=15.0}; /files/pelab1/local/bin/sml[99]: 4578 Segmentation Fault(coredump) Status: fixed in 107.7 ---------------------------------------------------------------------- Number: 980 Title: correct code can trigger a fatal error in the GC Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: Feb 27, 1995 System(s) and Version: runtime SML/NJ Version: 107 Machine: SPARC; both Solaris 2.4 and SunOS 4.1.3 Severity: major Problem: correct code can trigger a fatal error in the GC Code: ===start of "ipc91-5.sml"=== (* Internet Programming Contest 1991, Problem 5 *) (* utilities *) fun flatten [] = [] | flatten (xs::ys) = xs @ (flatten ys); (* ex *) flatten [[1,2],[4,3]]; fun ind 0 = "\n" | ind n = ind (n-1)^" "; fun wvars [x] = x | wvars (x::xs) = x^","^wvars xs; fun impl [] = "" | impl (xs::ys) = xs^impl ys; fun unparse plist = impl (flatten (map (fn (str, vl) => [str, "writeln("^wvars vl^")"]) (rev plist))); (* special-cons f|r listorna som representerar programmet *) fun cons2 ((s1,l1),[(s2,l2)]) = [(s1^s2,l1@l2)] | cons2 ((s1,l1),(s2,l2)::xs) = (s2,l1@l2)::(cons2 ((s1,l1),xs)); (* ex *) cons2 (("else", ["b","a"]),[ ("else", ["d","c"]), ("if c cons2 ((str,[]), merge (l1,l2))) (crossprod (a,b))); (* ex *) mergelists ([ ("else", ["b","a"]), ("if a 'a list val it = [1,2,4,3] : int list val ind = fn : int -> string ipc91-5.sml:13.1-14.34 Warning: match nonexhaustive x :: nil => ... x :: xs => ... GC #0.0.0.0.1.9: (10 ms.) val wvars = fn : string list -> string val impl = fn : string list -> string val unparse = fn : (string * string list) list -> string ipc91-5.sml:22.1-23.66 Warning: match nonexhaustive ((s1,l1),(s2,l2) :: nil) => ... ((s1,l1),(s2,l2) :: xs) => ... val cons2 = fn : (string * 'a list) * (string * 'a list) list -> (string * 'a list) list val it = [("else",["b","a","d","c"]),("elseif c ... ((s1,l1),(s2,l2) :: xs) => ... val cons3 = fn : (string * 'a) * (string * 'b) list -> (string * ('a * 'b)) list val crossprod = fn : (string * 'a) list * (string * 'b) list -> (string * ('a * 'b)) list val merge = fn : string list * string list -> (string * string list) list val it = [("\n else ",["b","a"]),("if a (string * string list) list val it = [("\n else ",["d","c","b","a"]),("\n else ",["d","b","c","a"]), ("\n else if b 'a list * 'a list val split1 = fn : 'a list -> 'a list * 'a list val mergesort = fn : (string list -> string list * string list) -> string list -> (string * string list) list val it = [("\n else ",["c","b","a"]),("\n else if a string list val pascalsort = fn : (string list -> string list * string list) -> int -> unit program sort(input,output); var a,b,c,d : integer; begin readln(a,b,c,d); if ay end Transcript: radish$ /usr/local/sml/107.3/bin/sml-cm loading /usr/local/sml/107.3/bin/.heap/sml-cm.mipseb ......................... done Standard ML of New Jersey, Version 107.3, February 7, 1995 [CM&CMB 1] val it = () : unit - CM.make(); [starting dependency analysis] [scanning sources.cm] [dependency analysis completed] [recovering .mipseb/a.sig.bin... done] [compiling a.sml -> .mipseb/a.sml.bin] Repairing blast GC (maxGen = 5 of 5) [wrote .mipseb/a.sml.bin] val it = () : unit - CM.make(); [starting dependency analysis] [parsing a.sig] [parsing a.sml] [dependency analysis completed] [compiling a.sig -> .mipseb/a.sig.bin] GC #0.0.0.0.1.18: (5 ms.) Repairing blast GC (maxGen = 5 of 5) [wrote .mipseb/a.sig.bin] [compiling a.sml -> .mipseb/a.sml.bin] Repairing blast GC (maxGen = 5 of 5) [wrote .mipseb/a.sml.bin] val it = () : unit - - ^Dradish$ rm .mipseb/a.sml.bin radish$ /usr/local/sml/107.3/bin/sml-cm loading /usr/local/sml/107.3/bin/.heap/sml-cm.mipseb ......................... done Standard ML of New Jersey, Version 107.3, February 7, 1995 [CM&CMB 1] val it = () : unit - CM.make(); [starting dependency analysis] [scanning sources.cm] [dependency analysis completed] [recovering .mipseb/a.sig.bin... done] [compiling a.sml -> .mipseb/a.sml.bin] Error: Compiler bug: Unexpected RELtyc in transtypes !* CM error: (sorry, can't be more specific) Fix: move call of Fixup.fixupStr into functions exported by Instantiate so that it will be called for abstraction declarations as well as after functor formal parameter instantiation. [dbm: the exact form of the fix might be improved a bit. fixupStr doesn't need to be called everywhere that instantiate_argument is called.] Status: fixed in 107.7 ---------------------------------------------------------------------- Number: 982 Title: there are no ways to query the implementation of math Keywords: Submitter: Ken Zadeck Date: 3/3/95 System(s) and Version: all SML/NJ Version: 0.93 Machine: Severity: frustrating Problem: there are no ways to query the implementation of math It would be very useful to be able to ask about the precision of integers, i.e., how many bits, largest number, smallest number. I know that these things are written down, but given that there will be 64 bit machines in the future, (and the possibility of using all 32 bits for some types) it would be nice to be able to write code that always works. The same is true for reals but I do not use them so I do not know what the correct specific complaints should be. Comment: [John Reppy] The new standard basis that we are designing (in collaboration with Harlequin and Moscow ML) includes: val precision : int option val minInt : int option val maxInt : int option in the INTEGER signature (options because an implementation of integers may support arbitrary precision). Owner: John Status: fixed in 109.20 [by new basis] ---------------------------------------------------------------------- Number: 983 Title: memory fault in sml-sc v107 on a sparc Keywords: Submitter: dimock@das.harvard.edu Date: 3/5/95 Version: 107 System: ? Severity: major Problem: memory fault in sml-sc v107 on a sparc Code: source code: sources.sc regexp.sml fsa.sml smlnj-lib.sc where smlnj-lib.sc contains: /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/107-sources.sc file regexp.sml: datatype regexp = EMPTY | CHAR of char | CONC of regexp * regexp | ALT of regexp * regexp | STAR of regexp; datatype extended_regexp = BASIC of regexp | STRING of string | PLUS of extended_regexp; (* val simplify_regexp = fn : extended_regexp -> regexp *) fun simplify_regexp (BASIC r) = r | simplify_regexp (STRING s) = let fun make_chars (x, EMPTY) = CHAR x | make_chars (x, y) = CONC (CHAR x, y) in fold make_chars (explode s) EMPTY end | simplify_regexp (PLUS p) = let val r = simplify_regexp p in CONC (r, ALT (EMPTY, r)) end file fsa.sml (* use "fsa.sml"; *) (* sc.make(); *) exception Fsa of string (* Exception for errors *) datatype ('a) trans = EPS | CHAR of 'a (* transition on character or e *) type state = string (* type of states, parameterize *) type alphabet = char (* type of alphabets, parameterize *) type delta = state * alphabet trans * StateSet.set (* type of transition relations *) local open LibBase (* make some sets of the right sort *) in structure StateKey : ORD_KEY = struct type ord_key = state fun cmpKey (s1 : state, s2) = if s1 >= s2 then if s1 > s2 then Greater else Equal else Less end structure SigmaKey : ORD_KEY = struct type ord_key = alphabet fun cmpKey (s1 : alphabet, s2) = if s1 >= s2 then if s1 > s2 then Greater else Equal else Less end structure DeltaKey : ORD_KEY = struct type ord_key = delta fun cmpKey ((s1s,s1a,_), (s2s,s2a,_)) = let val cmp1 = StateKey.cmpKey(s1s, s2s) in case cmp1 of Equal => (case (s1a, s2a) of ((CHAR x), (CHAR y)) => SigmaKey.cmp_key(x,y) | (EPS, EPS) => Equal | (EPS, _) => Less | (_, EPS) => Greater ) | _ => cmp1 end end end structure StateSet = SplaySet(StateKey); structure SigmaSet = SplaySet(SigmaKey); structure DeltaSet = SplaySet(DeltaKey); type states = StateSet.set type alphabet = SigmaSet.set type deltafun = DeltaSet.set type start = state type final = StateSet.set type fsa = states * alphabet * deltafun * start * final (* Make an empty FSA *) fun fsa_make() = (StateSet.empty, SigmaSet.empty, DeltaSet.empty, "", StateSet.empty) (* Manipulate start state *) fun fsa_set_start((K,S,d,s,F), s1) = (K,S,d,s1,F) fun fsa_get_start((K,S,d,s,F)) = if s = "" then raise Fsa "No Start State" else s (* Manipulate final states *) fun fsa_clear_finals((K,S,d,s,F)) = (K,S,d,s,StateSet.empty) fun fsa_add_finals((K,S,d,s,F), fs) = (K,S,d,s, StateSet.addlist (F, fs)) fun fsa_get_finals(K,S,d,s,F) = listItems F Transcript: - sc.make(); Defining the group... [scanning sources.sc] [scanning smlnj-lib.sc] [scanning /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/107-sources.sc] Compiling... GC #0.0.0.1.9.692: (30 ms.) GC #0.0.0.1.10.782: (0 ms.) GC #0.0.1.2.11.906: (80 ms.) GC #0.0.1.2.12.1057: (20 ms.) GC #0.0.1.2.13.1202: (20 ms.) GC #0.0.1.2.14.1218: (10 ms.) [Parsing fsa.sml] GC #0.0.1.2.15.1224: (10 ms.) [compiling regexp.sml] [writing .sparc/regexp.sml.bin] Repairing blast GC (maxGen = 5 of 5) [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/finalize-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/100-finalizer.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/100-time-limit.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/lib-base-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-lib-base.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array-qsort.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array-sort-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array2-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array2.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/ord-key-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/dict-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/binary-dict.sml.bin] GC #0.0.1.2.16.1233: (10 ms.) [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/ord-set-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/binary-set.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-ctype-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-ctype.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/bit-array-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-bit-array.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/bsearch.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-map-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-map.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/dynamic-array-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-dynamic-array.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/string-cvt-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-string-cvt.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/makestring-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-makestring.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-string-util-sig.sml.bin] GC #0.0.1.2.17.1249: (60 ms.) [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-set-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-set.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-string-util.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/bigint-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-bigint.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-format-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-format.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intmap-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intmap.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intset-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intset.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-format-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-list-format.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/listsort-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-mergesort.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-util-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-util.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-xprod-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-xprod.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/name-sig.sml.bin] GC #0.0.1.3.18.1293: (130 ms.) [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/hash-key-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/hash-table-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/hash-table.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-hash-string.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/name.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-array-sort-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-array-qsort.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-hash-table-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-hash-table.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/queue-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/fifo-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/fifo.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/queue.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/rand-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/rand.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/random-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/iterate-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/iterate.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/random.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/splaytree-sig.sml.bin] GC #0.0.2.4.19.1356: (230 ms.) [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/splaytree.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/splay-dict.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/pathname-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-pathname.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/unix-path-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/unix-env-sig.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/unix-env.sml.bin] [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/107-unix-path.sml.bin] Introducing the new bindings... val it = () : unit - %1 7238 Memory fault ${RUN} ${HEAP} ${ARGS} Process sml-sc exited abnormally with code 139 Fix: Workaround 1: -smlnj-lib.sc in sources.sc doesn't work: - sc.make(); GC #0.0.0.0.1.1: (0 ms.) Defining the group... [scanning sources.sc] [scanning smlnj-lib.sc] [scanning /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/107-sources.sc] Compiling... GC #0.0.0.0.2.34: (20 ms.) GC #0.0.0.0.3.77: (10 ms.) GC #0.0.0.0.4.152: (0 ms.) GC #0.0.0.0.5.251: (10 ms.) GC #0.0.0.1.6.376: (30 ms.) GC #0.0.0.1.7.532: (20 ms.) GC #0.0.0.1.8.613: (20 ms.) % structure LibBase undefined in source /tmp_mnt/home/usr12/cheatham/dimock/courses/ta153/chapter2/fsa.sml % functor SplaySet undefined in source /tmp_mnt/home/usr12/cheatham/dimock/courses/ta153/chapter2/fsa.sml % signature ORD_KEY undefined in source /tmp_mnt/home/usr12/cheatham/dimock/courses/ta153/chapter2/fsa.sml [reading .sparc/regexp.sml.bin] Introducing the new bindings... val it = () : unit Workaround 2 (works) include exactly the modules needed in sources.sc: regexp.sml fsa.sml (* -smlnj-lib.sc *) /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/lib-base-sig.sml /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/106-lib-base.sml /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/ord-key-sig.sml /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/ord-set-sig.sml /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/splay-set.sml /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/splaytree-sig.sml /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/splaytree.sml Owner: John Status: obsolete ---------------------------------------------------------------------- Number: 984 Title: Word32.notb returns incorrect result Keywords: Submitter: Edo Biagioni (esb@KITSUNE.FOX.CS.CMU.EDU) Date: 3/6/95 Version: 107 System: MIPS (DECstation?) Severity: major Problem: Word32.notb returns incorrect result. Transcript: - Word32.notb (Word32.intToWord 0); val it = 0 : Word32.word - (* another example from Thomas Yan: *) - map (Word32.notb o Word32.intToWord) [0,1,2,3,4]; val it = [0,~1,~2,~3,~4] : Word32.word list Comments: Should be 0xffffffff -- Word32.notb is off-by-one throughout its range. Unless it's been fixed, this is probably still a bug under 107.7 (which I haven't installed yet) Status: fixed in 107.8+ ---------------------------------------------------------------------- Number: 985 Title: Word32 operations yield incorrect results (1) Keywords: Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU Date: 3/7/95 Version: 107 System: alpha Severity: major Problem: Word32 operations yield incorrect results Transcript: - val half = Word32.intToWord 0x8000; - val high = Word32.shift (half, 16); val high = 2147483648 : Word32.word - fun f (a, b) = Word32.div (a, b); val f = fn : Word32.word * Word32.word -> Word32.word - f (high, high); val it = 4294967295 : Word32.word - val divisor = Word32.orb (Word32.shift (Word32.intToWord 0xffff, 16), Word32.intToWord 0xffff); - Word32.div (Word32.intToWord 1, divisor); val it = 4294967295 : Word32.word Comments: f (high, high) should return 1. This happens for several different values, but in all either the dividend or the divisor seem to have the top bit set. Status: fixed in 108.9 (maybe earlier -- lal) ---------------------------------------------------------------------- Number: 986 Title: Word32 operations yield incorrect results (2) Keywords: Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU Date: 3/7/95 Version: 107 System: mips (DECstation 5000?) Severity: major Problem: Word32 operations yield incorrect results Transcript: - Word32.ashift (Word32.intToWord 1, ~32); val it = 1 : Word32.word - Word32.shift (Word32.intToWord 1, ~32); val it = 1 : Word32.word Status: fixed in 107.8+ ---------------------------------------------------------------------- Number: 987 Title: Word32 operations yield incorrect results (3) Keywords: Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU Date: 3/7/95 Version: 107 System: mips (DECstation 5000?) and alpha Severity: major Problem: Word32 operations yield incorrect results Transcript: - val x = Word32.intToWord 1; val x = 1 : Word32.word - val y = Word32.shift (x, 31); val y = 0 : Word32.word Status: fixed in 107.8+ ---------------------------------------------------------------------- Number: 988 Title: serious bogosity on Alpha Keywords: Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU Date: 3/7/95 Version: 107 System: alpha Severity: major Problem: serious bogosity on Alpha Code: val l = (Word32.shift (Word32.intToWord 0xffff, 16), Word32.intToWord 0) val r = (Word32.orb (Word32.shift (Word32.intToWord 0x7fff, 16), Word32.intToWord 0xffff), Word32.shift (Word32.intToWord 0xffff8, 12)) (* l = 0xffff,0000,0000,0000 r = 0x7fff,ffff,ffff,8000 *) val zero = Word32.intToWord 0 (* this is very fragile. Commenting out '"abcdef" ^ "ghi"' causes a loop. *) fun find_shift1 (n1 as (high1, low1), n2 as (high2, low2)) = ("abcdef" ^ "ghi"; if Word32.< (high1, high2) then 0 else Integer.+ (1, find_shift1 (n1, (Word32.shift (high2, 1), zero)))) (* this is very fragile. Commenting out 'val lowhigh = Word32.shift (low, ~31)' causes a loop. *) fun lshift (high, low) = let val lowhigh = Word32.shift (low, ~31) val highhigh = Word32.shift (high, 1) in (highhigh, zero) end fun find_shift2 (n1 as (high1, low1), n2 as (high2, low2)) = (if Word32.< (high1, high2) then 0 else Integer.+ (1, find_shift2 (n1, lshift n2))) (* although functionally equivalent, find_shift1 and find_shift2 compute different results. The result computed by find_shift1 is correct. *) val a = find_shift1 (l, r) val b = find_shift2 (l, r) Comment: This program appears to demonstrate a rather obscure bug. The bug only appears on the alpha. The first symptom I noticed was: adding a print statement to a function changes the value returned. The print statement then became a string catenation, and the same result was obtained. In trying to reduce the problem I came to points where commenting out a piece of code would cause a loop (infinite?), and there I would stop. As a result, this is the smallest piece of code I could isolate that would reproduce the bug. [This bug exposes a subtle point about 32 bit implementations on 64 bit architectures. When a word32 object gets read from memory, the high 32 bits may not have the proper sign extension. Two solutions exist: when reading an object from memory, type information can be used to provide the necessary sign extension, or each word32 operation that is sign extension sensitive should perform the necessary sign extension first on the operands.] Status: fixed in 108.10 ---------------------------------------------------------------------- Number: 989 Title: Compiler bug: Instantiate:explore_tclass.5 Keywords: modules, functors, signatures, instantiate Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 03/08/95 System(s) and Version: Compiler SML/NJ Version: 107.7 Machine: all Severity: critical Problem: Compiler bug: Instantiate:explore_tclass.5 Code: (* bug.sml *) functor ParseFun(type Arg type Result val parser: string -> Arg -> Result sharing type Arg = unit (*1*) ) = struct fun parse file = parser file () (*2*) end; Transcript: Standard ML of New Jersey, Version 107.7, March 2, 1995 [new runtime] - use "bug.sml"; [opening bug.sml] Error: Compiler bug: Instantiate:explore_tclass.5 A simpler version, from Ken Cline (3/10/95) - signature VOID_XDR = sig type T sharing type T = unit end; Error: Compiler bug: Instantiate:explore_tclass.5 - Comments: If I change the "unit" on line (*1*) to be "int", and the "()" on line (*2*) to be "99", the problem goes away. This bug was not present in SML/NJ 107. This code is abstracted from some code where I construct a nice interface to an ml-yacc generated `ARG_PARSER'. I imagine many parsers could be similarly affected. Is this a re-appearance of bug #737? Comment: [DBM] This is different from bug 737. Fix: In modules/instantiate.sml I added a case in the definition of finalize in explore_tclass to treat the case of external sharing with type unit. It looks like the top-level binding of "unit" changed between 107.1 and 107.3 so that the DEFtyc case no longer applies -- the binding of "unit" is a RECORDtyc in 107.3. Tests: bug989.1.sml, bug989.2.sml Status: fixed in 107.7+ ---------------------------------------------------------------------- Number: 990 Title: Error: Compiler bug: access_type. Keywords: modules, signatures, sharing Submitter: Robert Findler Date: 3/13/95 Version: 107, 107.7 Severity: major Problem: "Error: Compiler bug: access_type" while elaborating a signature. Code: signature U = sig structure A: sig type 'a t type s end structure B: sig type u = int end type v=B.u A.t sharing type A.s=v end Status: fixed in 109.20 ---------------------------------------------------------------------- Number: 991 Title: Error: Compiler bug: Instantiate:explore_class.3 Keywords: modules, signatures, instantiation Submitter: Robert Findler Date: 3/13/95 Version: 107, 107.7 Severity: major Problem: "Error: Compiler bug: Instantiate:explore_class.3" while elaborating signatures. Code: signature S= sig type 'a t type s end signature T= sig type u = int end signature U = sig structure A:S structure B:T type v=B.u A.t sharing type A.s=v end Status: fixed in 109.20 ---------------------------------------------------------------------- Number: 992 Title: Support of local type abbreviations in signatures Keywords: modules, signatures, types abbreviations Submitter: John Reppy, Zhong Shao Date: March 14, 1995 Version: 107, 107.7 (any version) System: all platforms Severity: medium Problem: Support of local type abbreviations in signatures Code: signature SIG = sig local type t = int * real in val f : t -> t end end structure S : SIG = struct fun f (x,y) = (x+1,y+1) end Transcript: - Compiler.Stats.sayEnd := true; End Execute 0.0 sec val it = () : unit - signature SIG = sig local type t = int * real in val f : t -> t end end structure S : SIG = struct fun f (x,y) = (x+1,y+1) end = = ; End Compiler 010 Parse 0.0 sec std_in:9.26-9.73 Warning: LOCAL specs are only partially implemented End Compiler 030 Elaborate 0.0 sec Error: Compiler bug: type conflicts happened in transtypes-unwrapOp2 End Compiler 040 Translate 0.0 sec Comments: The compiler bug is caused when the wrappers are built for S.f (for representation analysis). "f" in SIG is considered having type t->t instead of int*real->int*real. But the bug is mainly caused by lack of support of "local type abbreviations" in signatures. See the bug report below and my comments: The first bug is the warning message --- we need to support local type abbreviations in signatures. The compilation passes beyond the Elaboration phase while it should not, because S does not match the signature SIG (f 's type is int*int -> int*int while its spec is int*real -> int*real ). First we need resolve the "warning" message, then I'll fix the representation analysis wrapper function code accordingly. Owner: dbm Status: not a bug (DBM: a feature request) ---------------------------------------------------------------------- Number: 993 Title: the control character ^\ in a string dumps core Keywords: Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 3/14/95 Version: 1.07 System: sparc, solaris 5.3, under emacs 19.22.1 Severity: minor Problem: the control character ^\ in a string dumps core Code: "" Transcript: - ""; (* no problem *) std_in:131.2 Error: illegal non-printing character in string - ""; (* oops... *) Quit (no coredump) Process Inferior eXene exited abnormally with code 208 Comments: somehow it doesn't seem to be a problem at the console. [Reppy: It appears that emacs is mapping the CNTRL-\ character into the SIGQUIT signal as it is typed, and this signal aborts the process.] Status: not a bug ---------------------------------------------------------------------- Number: 994 Title: realround (in math.sml) rounds up, not to nearest Keywords: Submitter: appel Date: Thu Mar 16 10:12:46 EST 1995 System(s) and Version: compiler SML/NJ Version: 107.7 Machine: Alpha Severity: minor Problem: realround (in math.sml) rounds up, not to nearest Code: val maxint = 4503599627370496.0 (* This is the IEEE double-precision *) fun realround x = if x>=0.0 then x+maxint-maxint else x-maxint+maxint Transcript: val maxint = 4.50359962737051E15 : real val realround = fn : real -> real - (realround 0.1, realround 0.5, realround 0.7, realround 1.0, realround 1.1); val it = (1.0,1.0,1.0,1.0,2.0) : real * real * real * real * real - maxint - 4.503E15; val it = 599627370496.001 : real - Correct transcript (taken from SML/NJ 107.7 running on SGI): - (realround 0.1, realround 0.5, realround 0.7, realround 1.0, realround 1.1); val it = (0.0,0.0,1.0,1.0,1.0) : real * real * real * real * real - maxint - 4.503E15; val it = 599627370496.0 : real - Comments: This will make sin/cos very slightly inaccurate; most users wouldn't notice. However, it indicates an error in the rounding of floating-point operations on the Alpha. Perhaps we are using the wrong rounding modes? I believe the problem is that "Dynamic" rounding is used. We should probably use "normal" rounding instead. For example, in Alpha32MC.sml, we have | I.ADDT arg => FOperate 22 0xe0 arg | I.SUBT arg => FOperate 22 0xe1 arg But better would be: | I.ADDT arg => FOperate 22 0xa0 arg | I.SUBT arg => FOperate 22 0xa1 arg The same applies for other FOperate instructions. Owner: Lal Status: fixed in 109.25.x [Lal] ---------------------------------------------------------------------- Number: 995 Title: error in cosine Keywords: Submitter: Lal George Date: 3/20/95 Version: 0.93 and 107.7 System: Pentium, Linux Severity: Major Problem: error in cosine Code: val theta = arctan (19.75 / 24.0); cos theta Transcript: - val theta = arctan (19.75 / 24.0); val theta = 0.688559158136141 : real - cos theta; val it = ~0.00133576476614669 : real Comments: [Lal George:] Cosine theta is completely off. [Lorenz Huelsbergen:] This is the same bug that caused nucleic to fail under Linux 107.x; it is fixed in the runtime for 108. Linux 107.x runtime was not calling fpenable to properly initialize the FPU to IEEE double precision. Status: fixed in 108 ---------------------------------------------------------------------- Number: 996 Title: sharing constraints and datatypes Keywords: modules, functors, signatures, sharing, datatypes Submitter: Edo Biagioni, esb@cs.cmu.edu Date: Wed Mar 22 1995 System(s) and Version: Compiler v. 107 SML/NJ Version: 107.0 Machine: Alpha and Mips (presumed typechecker bug) Severity: minor Problem: sharing constraints are not enough to make a type into a datatype if the type is declared textually before a datatype in a signature Code (test.sml): signature DERIVED = sig (* this doesn't work. *) type new_name datatype dtype = Constructor of int (* this does datatype dtype = Constructor of int type new_name *) sharing type dtype = new_name end functor F1 (structure Derived: DERIVED): DERIVED = struct structure Subtyped = Derived open Subtyped end functor F2 (structure Derived: DERIVED): DERIVED = struct structure New = F1 (structure Derived = Derived) open New end Transcript: - use "test.sml"; [opening test.sml] test.sml:19.1-23.4 Error: type dtype must be a datatype Status: fixed in 109.20 ---------------------------------------------------------------------- Number: 997 Title: lexgen doesn't check for unmatched quotes Keywords: Submitter: John Reppy Date: 2/13/94 Version: ? Severity: minor Problem: lexgen should check for unmatched double quotes. Right now, it just keeps eating characters (including newlines) until it sees a ". This gives an error message that is hard to understand. Owner: Andrew Status: fixed in 110.1 ---------------------------------------------------------------------- Number: 998 Title: Compiler bug: Escapemap on 10976 Keywords: modules, functors Submitter: Alan Smaill, smaill@dcs.ed.ac.uk Date: 27/3/95 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: sparc and solaris, also sparc and sunOS Severity: awkward Problem: fails to compile, raising compiler error Code: (* compiler bug *) signature MESSAGE_LANG = sig (* need more than two contructors in next *) datatype agent_id = UK | Kenya | Japan | World datatype commodity = Steel | Cars eqtype state_attribute datatype amount = Amount of int | Query datatype statement = State_info of agent_id * state_attribute * amount type message end; signature AGENT = sig structure Message_Lang : MESSAGE_LANG open Message_Lang type agent val update_beliefs : agent -> statement list -> agent end; signature AGENT_DYNAMICS = sig structure Agent : AGENT val process_message : Agent.Message_Lang.message * Agent.agent -> Agent.agent val core_functions : Agent.agent -> Agent.agent end; functor Neutral_Agent_Dynamics ( structure Agent : AGENT ) = struct structure Agent = Agent fun add_belief bel agt = agt fun process_message (_,a) = a end; functor World_Agent_Dynamics (structure Agent : AGENT ) : AGENT_DYNAMICS = struct structure Neutral_Dynamics = Neutral_Agent_Dynamics( structure Agent = Agent ) structure Agent = Agent open Agent open Message_Lang (* "Expand" is raised without next line *) fun revise_beliefs agt bels = agt exception NoStock of agent_id * commodity exception NoMoney of agent_id fun process_message (msg ,agt) = agt fun show s = output( std_out, s ) (* this needs def by cases *) (* and no wildcard *) fun showtr World = "World" | showtr UK = "UK" | showtr Japan = "Japan" | showtr Kenya = "Kenya" (* wildcard here removes the bug *) fun show_neg_info ( NoStock ( agent_id, cdy ) ) = show ( "Trader "^(showtr agent_id)) | show_neg_info ( NoMoney agent_id ) = show ( "Trader "^(showtr agent_id) ) fun update_stock_level trader agt = let val newC = Amount 0 handle SubAmt => ( show_neg_info(NoStock ( trader, Cars)); Amount 0 ) (* two decls needed here *) val newS = Amount 0 handle SubAmt => ( show_neg_info(NoStock (trader, Steel)); Amount 0 ) in agt end (* this also needed *) (* -- identity function not enough *) fun core_functions a = update_stock_level Kenya a end; =========================================================================== Transcript: [opening bug.sml] signature MESSAGE_LANG = [ ... sigs deleted ...] signature AGENT_DYNAMICS = sig structure Agent : ... val process_message : Agent.Message_Lang.message * Agent.agent -> Agent.agent val core_functions : Agent.agent -> Agent.agent end functor Neutral_Agent_Dynamics : bug.sml:66.9-69.41 Warning: match nonexhaustive NoStock (agent_id,cdy) => ... NoMoney agent_id => ... Error: Compiler bug: Escapemap on 10976 Owner: Status: open ---------------------------------------------------------------------- Number: 999 Title: absolute path to CM.stabilize'd library doesn't work Keywords: Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 03/27/95 System(s) and Version: CM 107.8 SML/NJ Version: 107.8 Machine: probably all Severity: major Problem: absolute path to CM.stabilize'd library doesn't work Code: We have a library, in $LIBPATH, consisting of (* lib.sml *) structure Lib = struct val version = "Lib Version 1.0" end and (* sources.cm *) Library structure Lib is lib.sml The client application, in a completely unrelated directory, consists of (* main.sml *) structure Main = struct fun main() = (print Lib.version; print "\n") end and (* sources.cm *) Group is --> /u/mikpe/tmp/lib/sources.cm (* actually $LIBPATH/sources.cm *) ! main.sml ! This has to be an absolute path. Transcript: sen14_1_pwd /u/mikpe/tmp sen14_2_ls -RA app/ lib/ app: main.sml sources.cm lib: lib.sml sources.cm ### First make the library using CM.stabilize() sen14_3_cd lib sen14_4_echo 'CM.stabilize()' | sml-cm loading /files/pelab1/ml/sml-107.8/bin/.heap/sml-cm.sparc ......................... done Standard ML of New Jersey, Version 107.8, March 24, 1995 [CM&CMB 1] val it = () : unit - = [starting dependency analysis] [scanning sources.cm] [parsing lib.sml] [dependency analysis completed] [compiling lib.sml -> .sparc/lib.sml.bin] Repairing blast GC (maxGen = 5 of 5) [wrote .sparc/lib.sml.bin] val it = () : unit ### Ok. Let's make the application now. sen14_5_cd ../app sen14_6_echo 'CM.make()' | sml-cm loading /files/pelab1/ml/sml-107.8/bin/.heap/sml-cm.sparc ......................... done Standard ML of New Jersey, Version 107.8, March 24, 1995 [CM&CMB 1] val it = () : unit - = [starting dependency analysis] [scanning sources.cm] [scanning /u/mikpe/tmp/lib/sources.cm] [parsing main.sml] [dependency analysis completed] !* CM error: cannot find SML source file u/mikpe/tmp/lib/lib.sml (u/mikpe/tmp/lib/lib.sml (stable)) uncaught exception SourceFileDoesNotExist ### Notice the missing "/" at the start of the path. ### Now if I make a symlink `ln -s /u u', then CM.make() finds the library. sen14_7_ln -s /u u sen14_8_echo 'CM.make()' | sml-cm loading /files/pelab1/ml/sml-107.8/bin/.heap/sml-cm.sparc ......................... done Standard ML of New Jersey, Version 107.8, March 24, 1995 [CM&CMB 1] val it = () : unit - = [starting dependency analysis] [scanning sources.cm] [scanning /u/mikpe/tmp/lib/sources.cm] [dependency analysis completed] [recovering u/mikpe/tmp/lib/.sparc/lib.sml.bin... done] [compiling main.sml -> .sparc/main.sml.bin] Repairing blast GC (maxGen = 5 of 5) [wrote .sparc/main.sml.bin] val it = () : unit sen14_9_exit sen14_10_exit script done on Mon Mar 27 21:53:22 1995 Comments: This worked in 107.7. It also works in 107.8 if the library is built using CM.recompile() or CM.make() instead of CM.stabilize(). Owner: Matthias Status: fixed in 109.21 [according to jhr] ---------------------------------------------------------------------- Number: 1000 Title: top-level printing of multiple occurrences of the same name Keywords: top level, modules Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 3/28/95 Version: 1.07 System: sparc (all?) Severity: major Problem: top-level printing of multiple occurrences of the same name Code: (see examples below) Transcript: (* this doesn't crash, but is in some sense wrong *) - val x = 2 val x = 3; val x = 3 : int val x = 3 : int (* this is interesting... *) - val x = 3 val x = [7]; uncaught exception Boxity (* this is perhaps similar to appel's example in 863 *) - structure U = struct datatype u = U end = structure T = struct datatype t = T of U.u end = val l = U.U = val l = T.T U.U; structure U : sig datatype u con U : u end structure T : sig datatype t con T : U.u -> t end Error: Compiler bug: PPVal.switch: none of the datacons matched Comments: see also 863, and possibly 955, 912, 758, 695 for similar (past) problems. note that 863 blames the "open" statement in the example. Fix: a temporary work around is to sequentialize the declarations, e.g. val x=3; val x=[7] [Zhong, 3/24/97] Fixing the coredump bug caused by duplicate top-level declarations. For example, in almost any versions of SML/NJ, typing val x = "" val x = 3 would lead to core dump. This is avoided by changing the "exportLexp" field returned by the pickling function (pickle/picklemod.sml) into a list of lambdavars, and then during the pretty-printing (print/ppdec.sml), each variable declaration is checked to see if it is in the "exportLvars" list, if true, it will be printed as usual, otherwise, the pretty-printer will print the result as . Owner: Zhong Test: bug1000.sml, bug1000.1.sml, bug1000.2.sml Status: fixed in 109.26 [Zhong] ----------------------------------------------------------------------