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 <