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

SCM Repository

[smlnj] View of /bugs/branches/smlnj/bugs.0801-1000
ViewVC logotype

View of /bugs/branches/smlnj/bugs.0801-1000

Parent Directory Parent Directory | Revision Log Revision Log


Revision 945 - (download) (annotate)
Thu Oct 4 13:38:32 2001 UTC (17 years, 8 months ago)
File size: 280851 byte(s)
This commit was manufactured by cvs2svn to create branch 'smlnj'.
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 <richard@dcs.qmw.ac.uk>
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 <richard@dcs.qmw.ac.uk>
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 <squire@umbc.edu>
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 : <sig>
  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<nzeros;i++) zeros[i]=0;
--- 224,230 ----
  
      }
  #endif
! #if sony_news || MORE || defined(BSD386)
      {int i, nzeros = getpagesize()-bytcount;
       char zeros[4096];
       for(i=0;i<nzeros;i++) zeros[i]=0;
***************
*** 245,251 ****
      lseek(filid,N_DATADDR(E),0);
      bulletproofWrite(filid,CEIL(ETEXT,getpagesize()),E.a_data);
  #else
! #if defined(SPARC) && defined(MACH) || defined(BSD386)
      bulletproofWrite(filid,textstart+sizeof(E),E.a_text-sizeof(E));
  #else
  # if defined(DYNIX)
--- 237,243 ----
      lseek(filid,N_DATADDR(E),0);
      bulletproofWrite(filid,CEIL(ETEXT,getpagesize()),E.a_data);
  #else
! #if defined(SPARC) && defined(MACH) 
      bulletproofWrite(filid,textstart+sizeof(E),E.a_text-sizeof(E));
  #else
  # if defined(DYNIX)

Comment:
I forgot to mention: the bsd/386 signal handling patches (e.g. #ifdef
BSD386 in signal.c) should also be used for 386bsd.  Also, Ken Cline
(cline@cs.cmu.edu) independently discovered these fixes.

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 820
Title: execute binding in debugger
Keywords: 
Submitter:      Elsa L. Gunter, elsa@research.att.com
Date:		10/18/93
Version:        93-debugger (and probably any other version of the debugger)
System:         all
Problem:        execute is bound differently in the top-level than in sml
Code:
	val (I,O) = execute("/bin/date",[]);

Transcript:

tiree% /usr/local/sml/bin/sparc/smld
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- execute;
val it = fn : string -> 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 <hsu@soda.berkeley.edu>
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 = <primop> : string * int -> char
  val str = fn : char -> string
  val size = <primop> : 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 <andrzej@cs.cmu.edu>
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 : <sig>
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 : <sig>
val it = () : unit
-  functor br_curry_parser = Parser( functor t = Term );
functor br_curry_parser : <sig>
- functor br_lex_curry_parser = br_curry_parser( functor lex = Scanner );
functor br_lex_curry_parser : <sig>
- 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>) = sig functor <functor> : <sig> end
  - funsig S1 (T:sig end) (T:sig type t end) = sig val x:T.t end;
  funsig S1(T:<sig>) = sig functor <functor> : <sig> 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 <Argument>.<Parameter>.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 : <sig>
  - functor F1(T:sig  end) (T:sig type t end) = struct type t = T.t end;
  functor F1 : <sig>
  - 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 <terra@diku.dk>
			(Referencing Kristian Nielsen <bombadil@diku.dk>)
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 = <primop> : 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 <santas@inf.ethz.ch>
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(<Parameter>:<sig>) =
  sig
    type t
    sharing type <Argument>.<Parameter>.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 <santas@inf.ethz.ch>
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 <santas@inf.ethz.ch>
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 = <primop> : realarray -> int
exception Size = Size
val sub = <primop> : realarray * int -> real
val update = <primop> : 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 <santas@inf.ethz.ch>
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 <joshp@cmu.edu>
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 <santas@inf.ethz.ch>
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(<Parameter>:<sig>) =
  sig
    type R
    val foo : R -> R
    sharing <Argument>.<Parameter>.T2 = <Argument>.<Parameter>.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 : <sig>

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 : <sig>

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 : <sig>

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 <cokasaki@cs.cmu.edu>
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: 		<Andreas  
Hallmann<hallmann@ls5.informatik.uni-dortmund.de>>
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 <mach/i386/thread_status.h>
#             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 <mach/m68k/thread_status.h>
#             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 <blume@cs.Princeton.EDU>
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 <blume@cs.Princeton.EDU>
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 <piggy@baqaqi.chi.il.us>
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 <fischer@cs.wisc.edu>
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,<pat> :: <pat>) => f (<exp>,<exp>,<exp>)
         | (f,<pat> :: <pat>) => let val <binding>  in (<exp>) 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 <cregut@LANNION.cnet.fr>
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 : <sig>
  - 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 <piggy@baqaqi.chi.il.us>
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 <Q> in ml.lex.

<Q>"\\\\"	=> (addString(charlist, "\\"); continue());
<Q>"\\`"	=> (addString(charlist, "`"); continue());
<Q>"\\^"	=> (addString(charlist, "^"); continue());
<Q>"^"          => (YYBEGIN AQ;
                    let val x = makeString charlist
                    in
                    Tokens.OBJL(x,yypos,yypos+(size x))
                    end);
<Q>"`"          => ((* a closing quote *)
                    YYBEGIN INITIAL;
                    let val x = makeString charlist
                    in
                    Tokens.ENDQ(x,yypos,yypos+(size x))
                    end);
<Q>\n           => (inc lineNum; addString(charlist,"\n"); continue());
<Q>.            => (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 <piggy@baqaqi.chi.il.us>
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 <piggy@baqaqi.chi.il.us>
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 <twx@dcs.ed.ac.uk>
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 : <sig>
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());
<IN_COMMENT>"*)"         => (YYBEGIN INITIAL; lex());
<IN_COMMENT>[\n]         => (inc lineno; lex());
<IN_COMMENT>.            => (lex());


Transcript:

- val _ = lexGen "/home/raoul/proj/avc/tst.lex";
sml-lex: syntax error, line 8: bad start state list

Comments:               Error msg. disappears when the underscores are removed.
Fix:                    disallow underscores or modify the bit in
			lexgen.sml that recognises start states.
Status: fixed in lexgen 1.6.0
----------------------------------------------------------------------
Number: 899
Title: makeml isn't up to date for Solaris
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			8/8/94
System(s) and Version:	
SML/NJ Version: 	1.03f
Machine: 		SPARC, Solaris 2.3
Severity: 		major
Problem: makeml isn't up to date for Solaris
Comments:
  src/makeml doesn't have an entry for "-sun4 solaris"
  src/runtime/Makefile needs to #define _ASM when assembling SPARC.prim.s
Status: fixed in 106 (makeml has gone away)
----------------------------------------------------------------------
Number: 900
Title: sml-noshare won't build on Solaris (and maybe other OS)
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			8/8/94
System(s) and Version:	
SML/NJ Version: 	1.03f
Machine: 		SPARC, Solaris 2.3
Severity: 		major
Problem: sml-noshare won't build on Solaris (and maybe other OSs)
Comments:

  The way the noshare runtime/allmo.o is built is inherently wrong.
  run.c wants "binend" to be a global symbol located just after the
  end of the "binst" array, as is the case when linkbin has built an
  allmo.s for a shared runtime. But when a noshared runtime is built,
  the dummy allmo.c (containing: char binst[1]; char binend[1]) is
  compiled using the C compiler, in the hope that binend will be located
  just after binst. Guess what? This is not true for Solaris 2.3.
  This results in loadBinFile() (in run.c) happily using addresses in
  nowhere-land as code pointers (the test "if (internal_bin + 8 < binend)"
  is true!) with disastrous results.

  One fix might be to let binend be a "char*" pointing just after binst[],
  but this would require changes to all of linkbin.c, allmo.c, and run.c .
  Since linkbin.c already knows the format of allmo.s, I decided instead
  to generalize linkbin.c and let it build an appropriate allmo.s for
  the noshare runtime. This required minor changes to makeml, runtime/Makefile,
  and runtime/linkbin.c . runtime/allmo.c is no longer used.

Status: fixed in 106 (noshare has gone away)
----------------------------------------------------------------------
Number: 901
Title: runtime/cfuns.c in 103f
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			8/8/94
System(s) and Version:	
SML/NJ Version: 	1.03f
Machine: 		SPARC, Solaris 2.3
Severity: 		major
  runtime/cfuns.c (function raise_syserror()) uses sprintf() without
  having #included <stdio.h>
  getdev() (for SOLARIS) has a typo: (c == "\n") should be: (c == '\n')

Fix:

*** makeml.~1~	Sun Dec 19 20:56:18 1993
--- makeml	Mon Aug  8 17:00:15 1994
***************
*** 103,108 ****
--- 103,117 ----
  	    case $1 in
  		mach)  OPSYS=MACH; DEFS="$DEFS -DBSD" ;;
  		sunos) OPSYS=SUNOS ;;
+ 		solaris|sunos5)
+ 		  MAKE=/usr/ccs/bin/make
+ 		  AS=/usr/ccs/bin/as
+ 		  CPP=/usr/ccs/lib/cpp
+ 		  CPPP="\"$CPP -P\""
+ 		  DEFS="$DEFS -DSUNOS"
+ 		  OPSYS=SOLARIS
+ 		  CFL="$CFL -lsocket -lnsl"
+ 		  ;;
  		*)
  		    echo "$CMD must specify opsys arg for SUN (sunos or mach)"
  		    exit 1
***************
*** 529,545 ****
  	CCARG=""
      fi
  
      if test -n "$SHARE"
      then
! 	ARG="MACHINE=$MACHINE $CCARG 'CFL=$CFL' 'LDFLAGS=$LDFLAGS' 'LIBS=$LIBS' 'DEFS=$DEFS -DAS=\\\"$AS\\\"' linkbin"
! 	echo "$CMD (cd $RUNTIME; $MAKE $ARG)"
! 	(cd $RUNTIME; eval $MAKE $ARG)
  	if test "$?" -ne "0"; then
  	    exit 1
  	fi
! 
! 	echo "$CMD $RUNTIME/linkbin $BIN $RUNTIME"
! 	$RUNTIME/linkbin $BIN $RUNTIME
  	if test "$?" -ne "0"; then
  	    exit 1
  	fi
--- 538,561 ----
  	CCARG=""
      fi
  
+     ARG="MACHINE=$MACHINE $CCARG 'CFL=$CFL' 'LDFLAGS=$LDFLAGS' 'LIBS=$LIBS' 'DEFS=$DEFS -DAS=\\\"$AS\\\"' linkbin"
+     echo "$CMD (cd $RUNTIME; $MAKE $ARG)"
+     (cd $RUNTIME; eval $MAKE $ARG)
+     if test "$?" -ne "0"; then
+ 	exit 1
+     fi
+ 
      if test -n "$SHARE"
      then
! 	echo "$CMD $RUNTIME/linkbin $BIN $RUNTIME"
! 	$RUNTIME/linkbin $BIN $RUNTIME
  	if test "$?" -ne "0"; then
  	    exit 1
  	fi
!     else
! 	# create "noshare" allmo.o
! 	echo "$CMD $RUNTIME/linkbin $RUNTIME"
! 	$RUNTIME/linkbin $RUNTIME
  	if test "$?" -ne "0"; then
  	    exit 1
  	fi
*** runtime/Makefile.~1~	Wed Aug 25 16:11:14 1993
--- runtime/Makefile	Mon Aug  8 16:54:25 1994
***************
*** 56,65 ****
  export.o : tags.h
  
  prim.o : $(MACHINE).prim.s tags.h
! 	 $(CPP) -DASM $(DEFINES) $(MACHINE).prim.s >prim.s
  	 $(AS) -o prim.o prim.s
- 
- allmo.o : allmo.c tags.h ml_types.h ml_state.h mask.h
  
  linkbin: linkbin.c tags.h
  	$(CC) $(CFLAGS) -o linkbin linkbin.c
--- 56,63 ----
  export.o : tags.h
  
  prim.o : $(MACHINE).prim.s tags.h
! 	 $(CPP) -DASM -D_ASM $(DEFINES) $(MACHINE).prim.s >prim.s
  	 $(AS) -o prim.o prim.s
  
  linkbin: linkbin.c tags.h
  	$(CC) $(CFLAGS) -o linkbin linkbin.c
*** runtime/cfuns.c.~1~	Wed Sep  1 19:47:43 1993
--- runtime/cfuns.c	Mon Aug  8 16:12:51 1994
***************
*** 46,51 ****
--- 46,52 ----
  #ifdef HPUX
  #include <sys/utsname.h>
  #endif
+ #include <stdio.h>	/* declare sprintf() for raise_syserror() */
  
  #include "ml_state.h"
  #include "ml_types.h"
***************
*** 2350,2356 ****
  
  #ifdef SOLARIS
  #include <limits.h>
- #include <stdio.h>
  #include <fcntl.h>
  #include <signal.h>
  #include <errno.h>
--- 2351,2356 ----
***************
*** 2462,2468 ****
    fil.data = fbuf;
    fil.eptr = fil.ptr = 0;
    while((sts = getline(buf, &fil)) > 0) { 
!     if (((c = buf[0]) == '#') || (c == "\n") || (c == '\0')) continue;
      rest = buf;
      p = getfield(&rest);  /* get and test netid */
      if (p == NULL) continue;
--- 2462,2468 ----
    fil.data = fbuf;
    fil.eptr = fil.ptr = 0;
    while((sts = getline(buf, &fil)) > 0) { 
!     if (((c = buf[0]) == '#') || (c == '\n') || (c == '\0')) continue;
      rest = buf;
      p = getfield(&rest);  /* get and test netid */
      if (p == NULL) continue;
*** runtime/linkbin.c.~1~	Wed Sep  1 19:21:31 1993
--- runtime/linkbin.c	Mon Aug  8 17:07:41 1994
***************
*** 17,22 ****
--- 17,24 ----
   * into a "runtime"/allmo.o file that defines two symbols: "binst," which
   * occurs at the beginning, and "binend" at the end.
   * 
+  * linkbin runtime
+  * creates a dummy allmo.o to be used when building the "noshare" runtime.
   */
  
  #include <stdio.h>
***************
*** 121,134 ****
      TEXT(asfile);
      GLOBAL(asfile, "binst");
      LABEL(asfile, "binst");
!     WORD(asfile, MAGICNUM);
!     SPACE(asfile, size-4);
      GLOBAL(asfile, "binend");
      LABEL(asfile, "binend");
- 
  }
  
- 
  struct {char magic[16];
  	int import_cnt;
  	int export_cnt;
--- 123,136 ----
      TEXT(asfile);
      GLOBAL(asfile, "binst");
      LABEL(asfile, "binst");
!     if( size ) {
! 	WORD(asfile, MAGICNUM);
! 	SPACE(asfile, size-4);
!     }
      GLOBAL(asfile, "binend");
      LABEL(asfile, "binend");
  }
  
  struct {char magic[16];
  	int import_cnt;
  	int export_cnt;
***************
*** 185,194 ****
   char as_buf[200], o_buf[200], cmd_buf[200];
   FILE *asfile, *ofile; int ofd;
   int size, i, pos, sts;
!  if (argc!=3)
!    die("usage: linkbin bindir runtime");
!  dir=argv[1]; runtime=argv[2];
!  size=process_all("BOOTLIST",dir)+process_all("BINLIST",dir);
  
   sprintf(as_buf, "%s/allmo.s", runtime);
   sprintf(o_buf, "%s/allmo.o", runtime);
--- 187,199 ----
   char as_buf[200], o_buf[200], cmd_buf[200];
   FILE *asfile, *ofile; int ofd;
   int size, i, pos, sts;
!  if( argc == 2 ) {
!      runtime = argv[1]; size = 0;
!  } else if( argc == 3 ) {
!      dir = argv[1]; runtime = argv[2];
!      size = process_all("BOOTLIST",dir) + process_all("BINLIST",dir);
!  } else
!      die("usage:\tlinkbin bindir runtime\nor\tlinkbin runtime\n");
  
   sprintf(as_buf, "%s/allmo.s", runtime);
   sprintf(o_buf, "%s/allmo.o", runtime);
***************
*** 205,210 ****
--- 210,217 ----
  	fprintf (stderr, "cannot assemble %s, status = %d\n", as_buf, sts);
  	exit (1);
   }
+ 
+  if( size == 0 ) exit(0);
  
   out = fopen(o_buf,"r+");
   if (!out)

Status: fixed in 106 (cfuns.c has gone away)
----------------------------------------------------------------------
Number: 902
Title: tab character in string in lexgen/lexgen.sml
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			8/8/94
System(s) and Version:	lexgen 1.5.0 (a.k.a. lexgen94)
SML/NJ Version: 	1.03f
Machine: 		all
Severity: 		minor
Problem:

There's a "tab" character in a string literal in lexgen/lexgen.sml .
This provokes an error message from the sml/nj 1.03f lexer.

Code:
Transcript:
Comments:
Fix:

Change the "tab" character to "\t".

*** lexgen.sml.~1~	Thu Jun  2 21:22:15 1994
--- lexgen.sml	Mon Aug  8 18:28:46 1994
***************
*** 1090,1096 ****
  val skel_mid2 =
  "\t\t       | Internal.D k => action (i,(acts::l),k::rs)\n\
  \\t\t       | Internal.T k =>\n\
! \\t\t	 let fun f (a::b,r) =\n\
  \\t\t\t      if a=k\n\
  \\t\t\t        then action(i,(((Internal.N a)::acts)::l),(b@r))\n\
  \\t\t\t        else f (b,a::r)\n\
--- 1090,1096 ----
  val skel_mid2 =
  "\t\t       | Internal.D k => action (i,(acts::l),k::rs)\n\
  \\t\t       | Internal.T k =>\n\
! \\t\t\t let fun f (a::b,r) =\n\
  \\t\t\t      if a=k\n\
  \\t\t\t        then action(i,(((Internal.N a)::acts)::l),(b@r))\n\
  \\t\t\t        else f (b,a::r)\n\

Status: fixed in 106 (lexgen 1.6.0)
----------------------------------------------------------------------
Number: 903
Title: floating point broke on DECstation
Keywords: 
Submitter: 		Daniel R. Ehrlich <ehrlich@cse.psu.edu>
Date: 			08/29/94
System(s) and Version:	Compiler (?)
SML/NJ Version: 	0.93
Machine: 		DECstation 5000/33
Severity: 		critical
Problem: 		Can not use floating point numbers
Code:			4.2;
Transcript: 		
	Standard ML of New Jersey, Version 0.93, February 15, 1993
	val it = () : unit
	- 4.2;

	uncaught exception Overflow
	- 
Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 904
Title: equal but distinguishable strings
Keywords: 
Submitter: Alain.Deutsch@inria.fr
Date: 9/8/94
Version: 103f
System: ?
Severity: major
Problem: 
  Two strings test equal, but a function applied to both strings
  yields different results, therefore distinguishing them.
Transcript: 
Standard ML of New Jersey, Version 1.03f, April 11, 1994
- -  fun Bug(s: string) =
     let val file = "/tmp/G00099"
	 val stream = open_out(file)
	 val _ = output(stream, s)
	 val _ = close_out(stream)
	 val stream = open_in(file)
	 val s' = input(stream, size(s))
	 val _ = close_in(stream)

	 fun f(s: string) =
	     case s of
		 "OK\n" => 0
	       | _ => 1
     in
	 (f s, f s', s=s')
     end;

val Bug = fn : string -> int * int * bool

- - val bug = Bug("OK\n");
val bug = (0,1,true) : int * int * bool

- - Bug("FOObar");
val it = (1,1,true) : int * int * bool

Then the first  run  Bug("OK\n") gives the following  inconsistent
result: s and  s' are equal  but distinguishable. This  looks very
much like a bug.

Status: fixed in 1.07
----------------------------------------------------------------------
Number: 905
Title: type insecurity with local around functor declaration
Keywords: type checking, core dump, value restriction
Submitter:              Claudio Russo,cvr@dcs.ed.ac.uk
Date:                   9/12/94
System(s) and Version:  Compiler
SML/NJ Version:         0.93
Machine:                Solaris but I guess all others too
Severity:               critical
Problem:                

There is a type insecurity arising from the (non-standard according to
the Definition) use of local declarations in functor bindings,
ie. some well typed programs go "wrong" in the sense of Milner.
Consider the following:

Code:

  local val lr = ref [] in
    functor F (type t) =
    struct
      exception Empty;
      local datatype s = S of t
      in
	fun put x = lr:= [(S x)]
	fun get () = case !lr of
			[S x] => x
		    | _ => raise Empty
      end
    end
  end; (* local *)

  structure A = F(type t = unit -> unit);
  structure B = F(type t = bool);

  B.put true;
  (A.get ()) ();  (* an attempt to apply a boolean to an argument *)

Transcript:  
  nj-sml.93
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  - val it = () : unit
  - use "njmlbug.sml";
  [opening njmlbug.sml]
  functor F : <sig>
  structure A :
    sig
      exception Empty
      val get : unit -> ?.<Parameter>.t
      val put : ?.<Parameter>.t -> unit
    end
  structure B :
    sig
      exception Empty
      val get : unit -> ?.<Parameter>.t
      val put : ?.<Parameter>.t -> unit
    end
  val it = () : unit

  Process NJ-SML bus error (core dumped)

Comments:               

The bug occurs for two reasons. 

1) The type name assigned to s does not
   become one of the type names that need to be regenerated on each application
   of the functor F because it does not appear in the signature of the body.
   This is a problem with the Definition.

2) The type name assigned to s is allowed to escape its scope and instantiate
   the imperative type variable introduced by the declaration of the reference
   lr. This can't happen in the Definition because there is no construct
   for binding values local to a functor declaration 
   (or lambda abstraction over   functors).

With the above in mind we see why the problem arises. At the declaration
val lr = [], lr is given type '_a list.
In the functor body, s is given generative name n, say, causing '_a to 
unify with n. But n is really dependent on the imported type t so it
is unsound to unify it with '_a, since n
varies with each different choice of t.
   
Fix: 

Don't allow type names to escape their scope! I.e.the name
generated for s shouldn't be unifiable with any type variable
(imperative or not) appearing free in the context at the point of the
declaration of s. The reason I used an imperative type variable is that, in
the absence of functional abstraction over functors, it seems impossible to
introduce non-generic type variables that are free in the context and
allow s's name to escape its scope. However, in the presence of higher-order
functors it may be possible to construct similar examples of programs that
go wrong.

I'd be very interested in your comments on the above bug, and on what
the implications for your implementation of higher order functors are.

Fix: A "local" form for functor declarations is not part of SML 90
  or SML 96.  Eliminating this syntactic form should fix the bug.
Owner: dbm
Test: bug905.sml
Status: fixed in 109.26
----------------------------------------------------------------------
Number: 906
Title: subscript exception compiling sigs with type abbreviations
Keywords: 
Submitter:      Emden R. Gansner, erg@research.att.com
Date:           9/13/94
Version:        > 1.03
System:         all
Severity:       major
Problem:        Subscript exception raised when compiling signatures with 
                type abbreviations.
Code:           
signature WIDGET =
  sig
    datatype valign = VCenter
    type widget
  end

signature WIDGET_SET =
  sig
    structure W : WIDGET
    type set_item = W.widget
  end

Transcript:
Comments: This is variation on bug 869. If the datatype declaration
          is commented out, it compiles okay.
Status: fixed in 107 (dbm)
----------------------------------------------------------------------
Number: 907
Title: polymorphic exceptions allowed
Keywords: 
Submitter:      Bernard Berthomieu (bernard@laas.laas.fr)
Date:           9/13/94
Version:        0.93
System:         SparcStation IPC, SunOS 4.1.3
Severity:       
Problem:        Polymorphic exceptions allowed.
Code:           
Transcript:     
		- let exception A of 'a in (A: 'a -> exn) end;
		val it = fn : 'a -> exn

		(* but elaboration is correct if the type constraint
		   is removed: *)

		- let exception A of 'a in A end;
		Error: non-weak type variable in exception declaration

Owner: dbm
Test: bug907.sml, bug907.1.sml
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 908
Title: divide by 0.0 on Sparc  (see bug 716 -- claimed to be fixed in 1.02)
Keywords: 
Submitter:              ryan@cs.unt.edu (Ryan Stansifer)
Date:                   9/16/94
SML/NJ Version:         0.93
Machine:                SPARC under SunOS Release 4.1.3_U1
Problem:                segmentation fault
Code:                   #1 (2, 1.0 / 0.0);   
Transcript:

krum> sml
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- (2, 1 div 0);

uncaught exception Div
- #1 (2, 1 div 0);

uncaught exception Div
- (2, 1.0 / 0.0);

uncaught exception Div
-  #1 (2, 1.0 / 0.0);
Segmentation fault (core dumped)

Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 909
Title: divide by 0.0 on DECstation
Keywords: 
Submitter: 		John Hannan <hannan@cse.psu.edu>
Date: 			9/16/94
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		DECstation 5000/33 (Ultrix 4.4)
Severity: 		major
Problem: 		Divide by zero exception does not work
Code:			3.0/0.0;  or 3.0/0.0 handle Div => 0.0;
Transcript: 		

- 3.0/0.0;
strange floating point error, 3616

Process cmusml exited abnormally with code 3

Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- 3.0/0.0 handle DIV => 4.0;
strange floating point error, 3616

Process cmusml exited abnormally with code 3

Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 910
Title: real overflow on DECstation
Keywords: 
Submitter: 		John Hannan <hannan@cse.psu.edu>
Date: 			9/16/94
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		DECstation 5000/33 (Ultrix 4.4)
Severity: 		major
Problem: 		Overflow exception for reals does not work
Code:			1E300 * 1E300;
Transcript: 		

- 1E300 * 1E300;
strange floating point error, 7700

Comments:	I assume this is related to the bug report I
		sent earlier about the Div exception not working.

Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 911
Title: ^C hangs sml on Sparc
Keywords: 
Submitter: Dave MacQueen
Date: 9/30/94
Version: 1.05a
System: Sparc, SunOS 4.1.x
Severity: major
Problem: 
  Typing ^C (interrupt) at to level does not interrupt SML, but
  causes it to go catatonic so that it doesn't notice further input.
  This is with sml run in an xterm window.
Status: fixed in 107 (JHR; 11/14/94)
----------------------------------------------------------------------
Number: 912
Title: Compiler bug: PPVal.switch: none of the datacons matched
Keywords: 
Submitter: Gene Rollins
Date: 10/4/94
Version: 1.05b/fox
System: ?
Severity: major 
Problem: 
Code: 
  structure pp = struct
   open Compiler.PrettyPrint

    fun p () =
      mk_ppstream
	{linewidth = 79,
	 flush = fn () => flush_out std_out,
	 consumer = outputc std_out}

  end
Transcript: 
  loading /afs/cs/project/fox-7/member/cline/port/105a/bin/.heap/sml.alpha32 ......................... done
  Standard ML of New Jersey, Version 1.05b/fox, October 3,1994 [new runtime]
  - use "pp.sml";
  ...
  - pp.p();
  val it =
    PPS
      {++=fn,consumer=fn,flush=fn,left_index=ref 0,left_sum=ref 0,linewidth=79,
       right_index=ref 0,right_sum=ref 0,space_left=ref 79,the_delim_stack=-,
       Error: Compiler bug: PPVal.switch: none of the datacons matched
  - 

Status: fixed in 107.4+
----------------------------------------------------------------------
Number: 913
Title: Makestring.intToStr from smlnj-lib causes core dump
Keywords: 
Submitter: Gene Rollins
Date: 10/4/94
Version: 1.05b/fox
System: ?
Severity: critical 
Problem: 
  Library function Makestring.intToStr cases core dump.
Transcript: 
  loading /afs/cs/project/fox-7/member/cline/port/105a/bin/.heap/sml.alpha32 ......................... done
  Standard ML of New Jersey, Version 1.05b/fox, October 3,1994 [new runtime]
  - Makestring.int 3;
  val it = "3" : string
  - makestring 4;
  val it = "4" : string
  - use "smlnj-lib/makestring-sig.sml";
  [opening smlnj-lib/makestring-sig.sml]
  GC #0.0.0.0.1.11:   (14 ms.)
  signature MAKESTRING =
    sig
      val padLeft : string * int -> string
      val padRight : string * int -> string
      val boolToStr : bool -> string
      val intToBin : int -> string
      val intToOct : int -> string
      val intToStr : int -> string
      val intToHex : int -> string
      exception BadPrecision
      val realToFloStr : real * int -> string
      val realToSciStr : real * int -> string
      val realFFormat : real * int -> {mantissa:string, sign:bool}
      val realEFormat : real * int -> {exp:int, mantissa:string, sign:bool}
      val realGFormat : real * int
			-> {exp:int option, frac:string, sign:bool, whole:string}
    end
  val it = () : unit
  - use "smlnj-lib/makestring.sml";
  [opening smlnj-lib/makestring.sml]
  GC #0.0.0.1.2.22:   (25 ms.)
  GC #0.0.0.1.3.43:   (44 ms.)
  GC #0.0.0.1.4.57:   (67 ms.)
  GC #0.0.1.2.5.79:   (71 ms.)
  GC #0.0.1.2.6.87:   (35 ms.)
  GC #0.0.1.2.7.122:   (25 ms.)
  GC #0.0.1.2.8.153:   (15 ms.)
  GC #0.0.1.2.9.191:   (36 ms.)
  GC #0.0.1.2.10.243:   (20 ms.)
  GC #0.0.1.2.11.309:   (20 ms.)
  structure Makestring : MAKESTRING
  val it = () : unit
  - Makestring.intToStr;
  val it = fn : int -> string
  - Makestring.intToStr 3;
  /afs/cs.cmu.edu/project/fox-7/member/cline/port/105a/bin/sml[137]: 8308 Segmentation fault

  Process cmusml exited abnormally with code 139

Status: fixed in 106
----------------------------------------------------------------------
Number: 914
Title: "foo1" style names in productions in mlyacc
Keywords: 
Submitter: Andrew Appel
Date: 10/12/94
Version: ? (Need mlyacc version numbers?)
Severity: minor
Problem: 
There appears to be a minor bug in ML-Yacc.  The manual claims that
if you have a production whose right-hand-side 
uses symbol "foo" just once, you can refer to its value (in the semantic
action) as either "foo" or "foo1".  But "foo1" seems to lead to problems,
so just use "foo".  Example:

Doesn't work:

exp : MINUS exp      (f(exp1))

Does work:

exp : MINUS exp      (f(exp))

(Problem is that ML-Yacc needs to insert extra parentheses around an
"as" clause in the pattern-match code that it prints out for the
semantic action function.  Should be trivial to fix.

Owner: 
Status: open
----------------------------------------------------------------------
Number: 915
Title: bogus nonexhaustive match warning for bytearray
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           10/13/94
Version:        0.93, 1.05 (all?)
Severity:       minor
Problem:        bogus nonexhaustive match warning for bytearray
Code:           case ByteArray.sub(a,i) of 0 => ... | ... | 255 => ...
Comments:	it is annoying to get a bogus >250 line warning
Owner: John
Status: not a bug
----------------------------------------------------------------------
Number: 916
Title: Compiler bug: Misc.checkbound from type abbrev in sig
Keywords: 
Submitter:      Kwangkeun Yi kwang@research.att.com
Date:           10/18/94
Version:        1.05
System:         SGI Challenger, Irix 5.2
Severity:       major
Problem:        binding non-nullary type constructor inside signature
                does not elaborate
Transcript:
             - signature foo = 
             = sig
             = type 'a t = 'a list
             = end;
             Error: Compiler bug: Misc.checkbound
             - 
Comments: SML/NJ allows type binding inside signature specification, while
          the Definition does not.
Status: fixed in 107 (dbm)
----------------------------------------------------------------------
Number: 917
Title: CRC's computed inaccurately
Keywords: 
Submitter: 		appel
Date: 			October 21, 1994
System(s) and Version:	Compiler
SML/NJ Version: 	1.05
Machine: 		all
Severity: 		minor
Problem: 		CRC's computed inaccurately
Comments:

Here is the "init" function in util/crc.sml:

  fun init 256 = ()
    | init n =
      let fun f(0,_,r) = r
            | f(i,p,r) = if Bits.andb(i,1)<>0 then f(Bits.rshift(i,1),p+p,p+r)
                           else f(Bits.rshift(i,1),p+p,r)
       in update(table,n,f(n,poly,0)); init(n+1)
      end

The problem is that "p+r" should really be Bits.xorb(p,r).
(p+p is ok, however, that's just a left shift).

Correcting this code should lead to "better" CRC computations
(fewer collisions).

Thanks to Peter Sestoft for bringing this to my attention.

Fix:  shown above

Status: fixed in 1.06
---------------------------------------------------------------------
Number: 918
Title: incomplete sharing propagation after functor application
Keywords: 
Submitter:      Kwangkeun Yi kwang@research.att.com
Date:		10/21/94
Version:        1.05
System:         SGI Challenger
Severity:       major
Problem:        incomplete sharing propagation after functor application
Code: (* file test.sml *)
	signature SIG = sig end
	functor ID (X: SIG) = X
	functor H() = struct
			  structure A = struct end
			  structure B = ID(A)
			end
	structure S = H()
	functor F(structure X: SIG
                  structure Y: SIG sharing X = Y) = struct end
	structure foo = F(structure X = S.A structure Y = S.B)

Transcript:
	- use "test.sml";
	test2.sml:10.17-10.54 Error: structure sharing violation
	  ?.S.B.<Parameter> # <Parameter>.X
	-	
Comments: After the functor application
		structure S = H()
	  S.A and S.B become unsharable, causing the F application
		F(structure X = S.A structure Y = S.B)
	  to fail. If we apply F like
		F(structure X = struct type t = int end
		  structure Y = ID(X))
	  then it is OK, as expected.

Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 919
Title: bus error
Keywords: 
Submitter:      Lal George
Date:		25 Oct. 1994
Version:        105 and 105g
System:         Alpha and Mips
Severity:       critical
Problem:        bus error.
Comments:
	This bug was brought to my attention by Ken Cline.
	I have not tested it in versions before 105.
	The system will core dump faster if representations is turned off.

Code:   
	Approx. 20000 lines, available from 
		ftp.cs.cmu.edu:/afs/cs/project/fox/ftp/working/elfbug.tar.gz

Transcript:

    sequent/natded.elf --- 1 --- static
    sequent/sequents.elf --- 2 --- static
    sequent/cut-sequents.elf --- 3 --- static
    sequent/cut-admit.elf --- 4 --- dynamic
    sequent/cut-elim.elf --- 5 --- dynamic
    val it = () : unit
    Reading pragmas [mode, order, lex]: ......
    /usr/local/sml/105/bin/sml[137]: 5274 Bus error

Status: fixed in 106 (George)
----------------------------------------------------------------------
Number: 920
Title: tuple selector syntax not handled by debugger
Keywords: 
Submitter: 		Stephen Weeks, sweeks@cs.cmu.edu
Date: 			October 25, 1994
System(s) and Version:	Compiler, Debugger
SML/NJ Version: 	0.93
Machine: 		CPU=PMAX-2100 OS=UNIX (mach)
Severity: 		minor
Problem: 		tuple selector syntax not handled by debugger
Code:			UserDebugCommands.run "#1(13,17)"
Transcript: 
  bin% smld
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  - UserDebugCommands.run "#1(13,17)";
  Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking

Owner: 
Status: obsolete [debugger not supported]
----------------------------------------------------------------------
Number: 921
Title: nonexhaustive binding failure while elaborating functor decl
Keywords: 
Submitter: 		mahler@socs.uts.edu.au (Daniel Mahler)
Date: 			27/10/93
System(s) and Version:	Runtime System
SML/NJ Version: 	0.93
Machine: 		sparc IPC 
Severity: 		minor
Problem: 		A basic problem with higher order functors
Code:

  signature X = sig end

  functor Apply (functor F (A : X) : X) (B : X) : X =
	  F(B)

  functor FUN (functor G (C : X) : X) (D : X) : X =
	  Apply(G)(D);

Transcript:

std_in:24.8 Error: unbound structure: G
Error: Compiler bug: ModuleUtil: getStrStamp wrong origin

Comments: Although the example above is not stricltly the correct syntax,
	it nonetheless causes a Compiler error

The proper syntax is: (bug921.1.sml)

  signature X = sig end

  functor Apply (functor F (A : X) : X) (B : X) : X =
	  F(B)

  functor FUN (functor G (C : X) : X) (D : X) : X =
	  Apply(functor F = G)(D)

Comment: [dbm] In 109.21, no longer causes Compiler Bug,
but instead fails with nonexhaustive binding failure:

- use "bug921.sml";
[opening bug921.sml]
signature X = sig end
functor Apply : <sig>
GC #0.0.0.1.7.500:   (11 ms)
bug921.sml:10.8 Error: unbound structure: G

uncaught exception nonexhaustive binding failure
  raised at: elaborate/elabmod.sml:246.6-255.9
             elaborate/elabmod.sml:513.33
             util/stats.sml:168.40
             build/evalloop.sml:145.36
             build/evalloop.sml:232.54
             build/evalloop.sml:316.38-316.41

Comment: [dbm,11/14/96] Now fails on bug921.1.sml (which is legal syntax)
with uncaught exception Unbound.

Owner: dbm
Test: bug921.sml, bug921.1.sml, bug921.2.sml
Status: open
----------------------------------------------------------------------
Number: 922
Title: failure of functor currying
Keywords: 
Submitter: 		mahler@socs.uts.edu.au (Daniel Mahler
Date: 			28/10/94
System(s) and Version:	sml
SML/NJ Version: 	0.93
Machine: 		sparc IPC
Severity: 		critical (for my current project)
Problem: 		FAILURE OF FUNCTOR CURRYING
Code:
signature Index =
	sig
		type A
		type I
		val index : A -> I
	end

signature Square =
	sig
		structure Source : Index
		structure Target : Index
		val top : Source.A -> Target.A
		val bottom : Source.I -> Target.I
	end

signature FunctorSig =
	sig
		type 'a C
		val map : ('a -> 'b) -> 'a C -> 'b C
	end

functor MapIndex (structure F:FunctorSig) (structure In:Index) : Index =
	struct
		type A = In.A F.C
		type I = In.I F.C
		val index = F.map In.index
	end

functor MapSquare (structure G:FunctorSig) (structure Sq:Square) : Square =
	struct
		structure Source = MapIndex (structure F = G) (structure In = Sq.Source)
		structure Target = MapIndex (structure F = G) (structure In = Sq.Target)
		val top = G.map Sq.top
		val bottom = G.map Sq.bottom
	end

			
Transcript:
- use "p7.sml"
uncaught exception Subscript
 		
Comments: Subscript is an array exception; I am not using arrays, only the above code. Uncurried version of the code compiles ok:

signature Index =
	sig
		type A
		type I
		val index : A -> I
	end

signature Square =
	sig
		structure Source : Index
		structure Target : Index
		val top : Source.A -> Target.A
		val bottom : Source.I -> Target.I
	end

signature FunctorSig =
	sig
		type 'a C
		val map : ('a -> 'b) -> 'a C -> 'b C
	end

functor MapIndex (structure F:FunctorSig and In:Index) : Index =
	struct
		type A = In.A F.C
		type I = In.I F.C
		val index = F.map In.index
	end

functor MapSquare (structure G:FunctorSig) (structure Sq:Square) : Square =
	struct
		structure Source = MapIndex (structure F = G and In = Sq.Source)
		structure Target = MapIndex (structure F = G and In = Sq.Target)
		val top = G.map Sq.top
		val bottom = G.map Sq.bottom
	end
Comment: [Lal] This fails in 105 as well as 93.
  [dbm] This is a other variant of bugs 796, 803, 860.

Status: fixed in 107 (dbm)
----------------------------------------------------------------------
Number: 923
Title: getWD() generates a bus error
Keywords: 
Submitter:      Lal George, Elsa Gunter
Date:		10/27/94
Version:        105f, 106
System:         SGI, IRIX 5.2
Severity:       major
Problem:        getWD() generates a bus error
Transcript:
	radish:$ $s/105f/bin/sml
	loading /nfs/297/people/sml/105f/bin/.heap/sml.mipseb .............. done
	Standard ML of New Jersey, Version 105.6, October 18, 1994 [new runtime]
	- System.Directory.getWD();
	/usr/local/sml/105f/bin/sml[98]: 18662 Bus error
Comment: [John Reppy] 
  This bug will be fixed as soon as I get rid of the old getWD implementation
  and replace it by a call to the C library function.  Should happen in 107.

Status: fixed in 107 (jhr)
----------------------------------------------------------------------
Number: 924
Title: misspelling of function names throws me out of SML
Keywords: 
Submitter:      Leonid, libkin@research.att.com
Date:		november 4
Version:        106
System:         Linux
Severity:       critical
Problem:        misspelling of function names throws me out of SML
Transcript:     

Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime]
- f 1;
std_in:7.1 Error: unbound variable or constructor: f
Uncaught exception SystemCall with "fionread failed, Invalid argument"
% 

(same happens if I apply a function to unbound variable or if an
expression does not typecheck (e.g. 1 + "a"; has the same effect).

Status: fixed in 106.1
----------------------------------------------------------------------
Number: 925
Title: irix installation bug
Keywords: 
Submitter: 		Marshall Abrams, ab2r@midway.uchicago.edu
Date: 			10/25/94
System(s) and Version:	cc version 2.10 (?)
SML/NJ Version: 	0.93
Machine: 		Silicon Graphics 4D/280 IRIX:4.0.5

Severity: 		minor
Problem: 		'makeml -mips irix' puts '-cckr' in DEFS, which
                        thereby gets put in DEFINES in the Makefile in
                        src/runtime.  This is fine for cc, but cpp chokes
                        on '-cckr'.
Transcript: 		
/lib/cpp -P -DASM -DMIPS -D_BSD_SIGNALS -cckr -Dsgi -DSGI MIPS.prim.s >prim.s
cpp: error 0: unknown flag -cckr

Fix:			I didn't do a general fix, as it's a
                        simple problem and my style of fixing it may not 
                        what you'd prefer for your distribution.  (Though 
                        I will if you want.)

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 926
Title: Array.extract of zero length is broken
Keywords: 
Submitter:      Elsa L. Gunter, elsa@research.att.com
Date:		23 November 1994
Version:        106
System:         SGI IRIX Release 5.2 IP19, sparcstation 2 SunOS Release 4.1.1
Severity:       major
Problem:        Array.extract of zero length is broken
Code:           Array.extract (Array.arrayoflist ["a","b"],1,0);
Transcript:     
  radish% /usr/local/sml/106/bin/sml
  loading /usr/local/sml/106/bin/.heap/sml.mipseb ......................... done
  Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime]
  - Array.extract (Array.arrayoflist ["a","b"],1,0);
  /usr/local/sml/106/bin/sml[98]: 6133 Bus error

Status: fixed in 107
----------------------------------------------------------------------
Number: 927
Title: Compiler bug: getSigTSlots caused by include
Keywords: 
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 12/29/94
Version: 107
Severity: critical (for Fox code)
Problem: 
  There is a bug in 107 which causes the compiler to choke on included
  signatures that contain a type of the same name as a datatype declared
  earlier in the including signature.  The transcript below should clearly
  demonstrate the bug.
Transcript: 

    cline@silver.fox% ../../bin/sml
    loading /afs/cs.cmu.edu/project/fox-7/member/cline/port/107/bin/.heap
            /sml.alpha32 ......................... done
    Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime]
    - signature sig0 = sig type t end;
    signature sig0 = sig type t end
    - signature sig1 = sig
    =   datatype t = T
    =   include sig0 (*sharing type t = t*)
    = end;
    Error: Compiler bug: getSigTSlots
Comments:
  Please let me know when you fix the bug - I would like to patch my version
  with the fix.
Fix: Changed the default case in the function f inside getSigTSlots to do
  nothing instead of calling impossible.  The same slot is being initialized
  more than once because the !symbols list has duplicate names.  These duplicate
  names are caused by a bug in the treatment of include specs in elabsig.sml.
Status: fixed in 107.1(dbm)
----------------------------------------------------------------------
Number: 928
Title: double printing of datatype spec
Keywords: 
Submitter: Dave MacQueen
Date: 1/18/95
Version: 106
Severity: minor
Problem: 
  Datatype spec is printed twice.
Code: (same as bug927.sml)
  signature sig0 = sig type t end;

  signature sig1 =
  sig
    datatype t = T
    include sig0 (*sharing type t = t*)
  end;
Transcript: 
  - use "bug927.sml";
  [opening bug927.sml]
  signature sig0 = sig type t end
  signature sig1 =
    sig
      datatype t
	con T : t
      datatype t
	con T : t
    end
  val it = () : unit
  - 
Fix:
  [dbm] fix make_includespec in elabsig.sml so that duplicate names are
  not added to the symbols list when a type is (successfully) respecified
  by an included signature.
Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 929
Title: failure of respecifying type after include
Keywords: 
Submitter: Ken Cline (Kenneth_Cline@cs.cmu.edu)
Date: 1/19/95
Version: 0.93 through 107.1
Severity: major
Problem: 
  Included signatures are allowed to respecify a type, but only if the
  included type specification is a simple spec (not a datatype, or type
  definition(?)).
Code: 
Transcript: 
  - signature s = sig type t end;
  signature s = sig type t end
  - signature ss = sig datatype t = T; include s end;
  signature ss =
    sig
      datatype t
	con T : t
      datatype t   (*duplicate printing is bug 928*)
	con T : t
    end
  - 
but
  - signature s = sig type t end;
  signature s = sig type t end
  - signature ss = sig include s; datatype t = T end;
  std_in:7.20-7.45 Error: duplicate specifications for type constructor t in signature
  - 
Comments:
Fix: rewrite include treatment in elabsig.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 930
Title: "Fundef <n> unused in freeClose" warning
Keywords: 
Submitter:      Lorenz Huelsbergen (lorenz@research.att.com)
Date:		1/19/95
Version:        103 and above
System:         all
Severity:       seems minor
Problem:        internal compiler message 
		"WARNING: Fundef <n> unused in freeClose"
		generated when compiling (albeit unreachable) code

Code:           
	signature S_SIG = 
	    sig
	    end
	
	structure S : S_SIG  =
	    struct
		fun f x = x 
	
		fun g ([],[]) = f (g ([],[]))
		  | g (x,[]) = f (g ([],[]))
	    end


Transcript:     

: radish 190; /usr/local/sml/103/bin/sml   
loading /usr/local/sml/103/bin/.heap/sml.mipseb ......................... done
Standard ML of New Jersey, Version 1.03, February 14, 1994 [new runtime]
- use "bug.sml";
[opening bug.sml]
bug.sml:9.2-10.29 Warning: match nonexhaustive
          (nil,nil) => ...
          (x,nil) => ...
  
GC #0.0.0.0.1.1:   (51 ms.)
WARNING: Fundef 207 unused in freeClose
signature S_SIG = sig  end
structure S : S_SIG
val it = () : unit
- 

Comments:
The above code is the smallest fragment I found that produces this
warning; the signature, function f, and the tuples of list patterns 
all seem necessary to generate this.  Code executes OK.

Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 931
Title: sharing constraints incorrectly resolved
Keywords: 
Submitter:      Elsa L. Gunter elsa@research.att.com
Date:		22 December 1994
Version:        0.93 and 1.06.5 (at least)
System:         Sparcstation 2, SunOS 4.1.1,
	        SGI (radish), IRIX Release 5.2 IP19
Severity:       major
Problem:        The structure in a strdesc is being added to the basis
		before its sigexp body has been evaluated, causing
                sharing constrints to be incorrectly resolved.
Code:           

structure A = struct datatype A = A end;

signature S1 = sig structure B : sig type t sharing type t = A.A end end;

signature S2 = sig structure A : sig type t sharing type t = A.A end end;

signature S3 = sig structure B : sig type t sharing type t = B.t end end;


Transcript:     

radish% ./sml
loading /usr/local/sml/106.5/bin/.heap/sml.mipseb ......................... done
Standard ML of New Jersey, Version 106.5, December 18, 1994 [new runtime]
- structure A = struct datatype A = A end;
structure A :
  sig
    datatype A
      con A : A
  end
- signature S1 = sig structure B : sig type t sharing type t = A.A end end;
signature S1 =
  sig
    structure B : ...
    sharing type B.t = A.A 
  end
- signature S2 = sig structure A : sig type t sharing type t = A.A end end;
std_in:9.58-9.64 Error: unbound type constructor: A in path A.A
- signature S3 = sig structure B : sig type t sharing type t = B.t end end;
signature S3 =
  sig
    structure B : ...
    sharing type B.t = B.t 
  end
- 


Comments: 

* S1 works fine.

* S2 should work the same as S1, but fails instead.  This is because the real
  structure A has been hidden by the local structure A being specified,
  when it should not be.

* S3 should fail since there is no structure B, and hence no type B.t.
  However it does succeed.  

[dbm] This is related to bugs 816, 817.

Owner: dbm
Test: bug931.sml
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 932
Title: Compiler bug: applyTyfun: not enough arguments
Keywords: 
Submitter: Andrew Appel
Date: 2/10/95
Version: 107.2
Severity: critical
Problem: Compiler bug caused by parameterized type abbrev in a signature
Code: 
  signature A =
  sig
    type 'a f = 'a
  end;

  structure B: A =
  struct
    type 'a f = 'a
  end;
Code: (reported By Thomas Yan, 3/28/95)
  signature S = sig type 'a t = 'a list end
  structure T : S = struct type 'a t = 'a list end
Transcript: 
  - use "bug932.sml";
  [opening bug932.sml]
  Error: Compiler bug: applyTyfun: not enough arguments
  - 
Owner: dbm
Test: bug932.sml, bug932.1.sml
Status: open
----------------------------------------------------------------------
Number: 933
Title: bogus message after explicit "raise Match"
Keywords: 
Submitter: Andrew Appel
Date: 2/10/95
Version: 107, etc
Severity: minor
Problem: 
If the user code says explicity "raise Match" then the global 
line number ref is not reset, so the message written is whatever
it was set to in the compiler.
Fix: the compiler, before running user code, should clear the ref.
Owner: Andrew
Status: open
----------------------------------------------------------------------
Number: 934
Title: Control.CG.misc4 when retargeting
Keywords: 
Submitter: Lal George
Date: 10/7/94
Version: 105
System: SGI/IRIX 5.2 (mipseb)
Severity: ?
Problem: 
  Confusion of two versions of Control.CG.misc4 during retargeting compilation.
Code: 
Transcript: script from sml-scb
  - Compiler.Control.CG.misc4;
  val it = ref 0 : int ref
  -
  - Retarget.retarget("/usr/local/sml/105/bin.mipseb",".mipseb");
  ....
  structure SC_Cross : SEPARATE_COMPILATION
  structure Batch : BATCH
  val it = () : unit
  - 
  - MipsBigVisComp.Control.CG.misc4:=128;
  val it = () : unit
  - 
  - MipsBigVisComp.Control.CG.misc4;
  val it = ref 128 : int ref
  - 
  -  Compiler.Control.CG.misc4;
  val it = ref 128 : int ref

Owner: 
Status: open
----------------------------------------------------------------------
Number: 935
Title: NaN from 0.0/0.0 is not caught
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           10/27/94
Version:        1.05
System:         sparc
Severity:       major
Problem:        NaN from 0.0/0.0 is not caught
Code:           0.0/0.0
Transcript: 

on SunOS 5.3 Generic_101318-59 sun4m:

	    loading /amd/dusk/b/sml/src/105/bin/.heap/sml.sparc-solaris ......................... done
            Standard ML of New Jersey, Version 1.05, July 21, 1994 [new runtime]
            - 0.0/0.0;
            /amd/dusk/b/sml/src/105/bin/.run/run.sparc-solaris: Fatal error -- unexpected fault, signal = 8, code = 0x7

on SunOS 4.1.2 1 sun4m:
        
            loading /amd/dusk/b/sml/src/105/bin/.heap/sml.sparc-sunos ......................... done
            Standard ML of New Jersey, Version 1.05, July 21, 1994 [new runtime]
            - 0.0/0.0;
            /amd/dusk/b/sml/src/105/bin/.run/run.sparc-sunos: Fatal error -- unexpected fault, signal = 8, code = 0xd0

            Process Inferior sml105 exited abnormally with code 1

Comments:   not a problem in 0.93; other cases appear to be ok,
            e.g. NaN's from sqrt & ln, Overflow from x/0.0
Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 936
Title: failure translating abstype declarations
Keywords: 
Submitter: Philip Santas (santas@inf.ethz.ch)
Date: 11/7/94 
Version: 0.93
Severity: major
Problem: 
  There is a compiler bug which involves abstypes defined in the body
  of a function f. If the function 'f' is called recursively in the
  body of the abstype (which is local) then a compiler bug is revealed.
Code: 
  fun foo x = 
      let abstype t1 = T | F
	  with
	    fun goo y = foo T
	  end
       in x
      end;
Transcript: 
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  - fun foo x = 
  =   let abstype t1 = T | F
  =       with
  =         fun goo y = foo T
  =       end
  =    in x end;
  Error: Compiler bug: CoreInfo.coreLty3
  -
  - fun foo x = 
  =   let abstype t1 = T | F
  =       with
  =         val goo = foo
  =       end
  =    in goo x end;
  Error: Compiler bug: CoreInfo.coreLty3

  I do not know how the definition handles the above cases.
  The behaviour is normal in the following (different) case:

  - fun foo x = 
  =   let abstype t1 = T | F
  =        with 
  =         fun goo y = T
  =        end
  =    in goo() end;

In 109.19m, these now produce the following output

  - tuse "test/bugs/bug936.sml";
  [opening test/bugs/bug936.sml]
  ** Lvar ** v1 is unbound *** 
  Error: Compiler bug: CheckLty: unexpected lambda code in checkLty

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       test/evalloop.sml:202.20-202.23
  - tuse "test/bugs/bug936.1.sml";
  [opening test/bugs/bug936.1.sml]
  ** Lvar ** v1 is unbound *** 
  Error: Compiler bug: CheckLty: unexpected lambda code in checkLty

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       test/evalloop.sml:202.20-202.23

In 109.25.2, the error has become

  uncaught exception in compiler: exception ltUnbound
    raised at: basics/ltyenv.sml:246.64-246.73
	       util/stats.sml:164.40
	       util/stats.sml:164.40
	       util/stats.sml:164.40
	       build/evalloop.sml:191.58

Comment: reopened dbm 11/15/96
Test: bug936.sml, bug936.1.sml
Owner: Zhong
Status: fixed in 109.27 [Zhong]
----------------------------------------------------------------------
Number: 937
Title: installing HOL90 on Alpha
Keywords: 
Submitter: Kim Dam Petersen (kimdam@tdr.dk)
Date: 11/14/94
Version: 106
System: DEC Alpha, OSF/1
Severity: major
Problem: 
  I have changed the system call code (as suggested by you for NJ/SML
   version 102 - it also works for 106).
  I have also changed string to char where needed.

  My first problem is that  "System.Directory.listDir"  is not
  implemented.  This function is only used by "Lib.clean_directory",
  so I have solved this problem by manually cleaning the directory.

  My real problem is that the export file "hol90.01" generated by
  sys01.sml seems to be missing some links.  It is not an executable
  file (as in 0.93 NJ/SML) so I use the command:

    sml @SMLload=hol90.01

  to load it.  This command does start something that looks like
  hol90: I get the hol90 prompt, and it recognizes the hol90
  functions.  But when I ask hol90.01 to install the first theory
  "restr_binder" it crashes!

  The call ``new_theory(..)'' works just fine, the next call
  ``new_definition(...)'' makes the system crash.
  By manually single-stepping the code I've located the crash to
  a call of  ``strip_forall'' inside Const_def.  Executing this
  application yields the execption "Boxity", which I assume is some
  internal NJ/SML exception.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 938
Title: Compiler bug: MipsCM.three: bad args, followed by core dump
Keywords: 
Submitter:              Henrik Reif Andersen, hra@id.dtu.dk
Date:                   Wed Nov 16 09:02:33 MET 1994
System(s) and Version:  Compiler
SML/NJ Version:         0.93
Machine:                DEC mips running ultrix
Severity:               major
Problem:                "Error: Compiler bug"
Code:                   ~385049931 - 385049931;
Transcript:             
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  - ~385049931 - 385049931;
  Error: Compiler bug: MipsCM.three: bad args
  - ();
  Illegal instruction (core dumped)
Status: fixed in 106 (John Reppy)
----------------------------------------------------------------------
Number: 939
Title: confusing type error message
Keywords: type checking, error message
Submitter: John Reppy
Date: 11/16/94
Version: 106
Severity: cosmetic
Problem: 
  Confusing type error message.
Code:
              ...
  line 52 :   val (i, _) = wrapIn (ins, BitmapIO.readBitmap)
              ...
Transcript: 
  widgets/util/tile-server.sml:52.17-52.62 Error: case object and rules don't agree (tycon mismatch)
    rule domain: 'Z * 'Y
    object:      {hot_spot:?.Geometry.point option, image:?.Image.image}
    in expression:
      (case wrapIn (ins,readBitmap)
	of (i,_) => {1=i})
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 940
Title: memory blowup caused by unmatched close comment
Keywords: 
Submitter: Ravi Sethi
Date: 11/20/94
Version: 0.83
Severity: major
Problem: 
  Runaway computation growing heap indefinitely caused by unmatched
  close comment.
Transcript: 
  - fun reduce f [] v = v
  = |   reduce f (a::y) v = f(a, reduce f y v);
  val reduce = fn : ('a * 'b -> 'b) -> 'a list -> 'b -> 'b
  - reduce (op +) [1,2,3,4,5] 0;
  val it = 15 : int
  - reduce (op *) [1,2,3,4,5] 1;
  std_in:21.12 Error: unmatched close comment
  std_in:21.15 Error: syntax error found at LBRACKET
  - reduce;
  val it = fn : ('a * 'b -> 'b) -> 'a list -> 'b -> 'b
  - reduce (op *);
  std_in:22.12 Error: unmatched close comment

  [Major collection...
  [Increasing heap to 2858k]

  [Increasing heap to 3178k]

  [Increasing heap to 4778k]
   90% used (2078900/2307716), 1120 msec]

  [Increasing heap to 8194k]

  [Major collection...
  [Increasing heap to 12582k]
   94% used (4094228/4323420), 2470 msec]

  ...

  [Major collection...
  [Increasing heap to 176406k]
   94% used (58298012/61484672), 35527 msec]

  [Increasing heap to 180138k]

  Interrupt
  - 

Comments: (Reppy, 11/20/94)
  This doesn't seem to be a problem in 106; maybe Andrew's changes to the
  parser fixed the problem.
Status: fixed in 107.7
----------------------------------------------------------------------
Number: 941
Title: x86 configuration problems
Keywords: 
Submitter: Carsten Mueller <cmr@cs.tu-berlin.de>
Date: 11/21/94
Version: 106
System: x86, linux 1.0 (40MHz 386 with 8 MB RAM.)
Severity: minor
Problem: 
(1)	The source dist (106-sml-nj.tar.Z) contains the heapfile sml.x86
	which is > 2 MB compressed.  So everybody not interested in x86 has
	to get it.  (I needed it anyway, see (2).)

(2)	The little-endian x86 runtime cannot read big-endian binfiles written
	on big-endian machines (is this why you distribute sml.x86?).  In
	order to avoid ftp-ing the bin.x86 dist, is there a way to (a) build
	binfiles without having old binfiles, or (b) build other-endian
	binfiles (e.g. sparc -> x86), or [preferrably] (c) get a patch to
	heap-??-util.c that is capable of byte swapping?
	The heap management and blasting are not very much documented, so I
	probably can't do it myself.  BTW: Is there already a paper (or at
	least a draft or some plain textfile) on the new runtime (or the heap
	management), and if yes, how to obtain it?

(3)	You might think that bin/.arch-n-opsys doesn't need an i386 entry, but
	I still have such a box.  It mentions only i[45]86.  (If this is
	intentional: I think that SML *should* run on the i386.  For details
	see the note below.)

(4)	config/install.sh calls SC's buildsc script without a path prefix.
	Please don't rely on people having `.' in their search path.  Many
	omit it intentionally, and have to edit it into the scripts.  Maybe
	this also applies to other scripts or Makefiles.

Note for i386: About the only difference between an i486 and an i386 with 387
or math emulation should be speed.  I am not aware of additional 486 or 586
instructions usable (or profitable to a significant degree) in a code
generator for SML.  Different alignment of jump targets or instruction
scheduling won't affect backwards compatibility.

Comments: [John Reppy]
(1) That shouldn't have been there, but I think that there were a number of
    similar oversights.  We will try to do better next time.
(2) Unfortunately, byte-swapping doesn't work on heap images (and the blasted
    part of bin files), because there isn't enough information to get the
    swapping done right (consider reals vs. strings).  The code part of a
    bin file has the right byte order, and it is possible to boot without
    using the environment part of the bin files (using the "-elab" option
    to xmakeml).  The bin.x86 tar file should be little-endian.  There is a
    paper (somewhat out of date) on the new GC part of the run-time; look in
    ftp.research.att.com:/dist/ml/papers.
(3) I'll add the 386 to the script.
(4) This is fixed in 107 [jhr].
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 942
Title: bad syntax error correction
Keywords: 
Submitter: 		Kevin Skadron, Andrew Appel
Date: 			11/30/94
System(s) and Version:	Compiler
SML/NJ Version: 	1.05a
Machine: 		all
Severity: 		minor
Problem: 		bad syntax error correction
Code: [Skadron]			
 Why does ML-YACC say:
 
 semant.sml:130.11 Error: syntax error: inserting  END ID IN
 semant.sml:437.7 Error: syntax error: inserting  LET
 
 when I have
 let <blah>
     fun foo() =
 	let <blah>
 	in a			(* note missing ; *)
 	   if/then/else
 	end
 in
     <blah>
 end

Comments: [Appel]
Well, at the point of the missing semicolon, 
inserting END ID IN  works as well as inserting a semicolon.
The fact that this leads to another syntax error isn't discovered
for another 300 lines.  

However, this isn't ideal.  Shorter insertions (in this case, SEMICOLON)
should be considered before longer ones.

Fix: [Appel]
Add "-> SEMICOLON |"  to the beginning of the %change list in parse/ml.grm
Perhaps other common insertions should also be added at that point,
to give them higher priority.  

The "%prefer"  list specifies high-priority insertions; but to make
sure they have higher priority, it might be better to delete the
%prefer list and just make all these into %change commands.

Finally, it's necessary to check that the order that changes are listed
in the %change list is really the order that Yacc prioritizes them.

Status: fixed in 107.7 +
----------------------------------------------------------------------
Number: 943
Title: imploding a list containing a string containing a tab
Keywords: 
Submitter: Andreas Sesterhenn (andreas@measoft.com)
Date: 8/12/94
Version: 103
Severity: ?
Problem: 
  Try to evaluate the following code:
        implode["a      b"];
  where the character between a and b is a tab.

  The compiler returns:
        Error: Illegal non-printing character in string

Comments:
  This worked under 0.93 and we have some code which is generated as strings
  _with_ tabs and then evaluated. This fails under 1.03. (Is that really
  necessary?)

  [Andrew Appel] This bug report is unrelated to "implode", just
  the string literal alone would do it.  But this is not a bug, this
  is a change we made deliberately in order to conform with the
  Definition of Standard ML.  This would work fine if you write
  "a\tb".

Status: not a bug
----------------------------------------------------------------------
Number: 944
Title: sml .arch-n-opsys script
Keywords: 
Submitter: Lorenz Huelsbergen
Date: 11/7/94
Version: 105?
Severity: major
Problem: 
  The 'sml' script calls a program '.arch-n-opsys' to determine 
  the arch and opsys.   '.arch-n-opsys' creates new
  shell commands to set ARCH and OPSYS appropriately and
  echos them.  'sml' then executes whatever '.arch-n-opsys' echoed.  
  There's a potential problem however because executing '.arch-n-opsys'
  invokes the shell (and runs the user's .kshrc file or whatever)
  which may echo its own stuff before and after '.arch-n-opsys' executes.  
  'sml' may therefore not be able to execute the result of 
  executing '.arch-n-opsys'.

  How about having '.arch-n-opsys' set the environment
  vars ARCH and OPSYS directly?

Owner: John
Status: not a bug [Lorenz may disagree]
----------------------------------------------------------------------
Number: 945
Title: opening a structure at top level reveals infix binding
Keywords: 
Submitter:              Manuel Fahndrich manuel@cs.berkeley.edu
Date:                   December 1, 1994
System(s) and Version:  Compiler
SML/NJ Version:         0.93
Machine:                HP-UX A.09.05 A 9000/715
Severity:               minor
Problem:                Opening of structures w/o signatures containing
			infix declarations, preserves the infix at top-level
			(which it shouldn't according to NEWS). Opening
			the same structure inside another structure does not
			preserve the infix status, but "op" still works.
Code:
structure T =
struct
  infix 3 ||
  fun op || (x,y) = y
  fun foo n = n || 5
end;

structure S =
struct
  local open T in 
    fun bar n = n || 7
    val baz = op ||
  end
end;

open T;

val z = op ||;
val y = ||;

Transcript:

structure T :
  sig
    val foo : 'a -> int
    val || : 'a * 'b -> 'b
    infix 3 ||
  end
structure S :
  sig
    val bar : (('a * 'b -> 'b) -> int -> 'c) -> 'c
    val baz : 'a * 'b -> 'b
  end
open T
val || = fn : 'a * 'b -> 'b
val foo = fn : 'a -> int
/tmp/ml001010:25.9-25.10 Error: nonfix identifier required

Comments:               The type of bar inside S is correct, i.e. ||
			is not treated as infix. However baz, refers to
			op ||, which should be a syntax error.
			Then on toplevel, || is recognized as infix, but
			not as nonfix.

			When testing this example, make sure that || has no
			infix status at top level. This test works only
			once. 
Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 946
Title: runtime assertion failure on x86-linux
Keywords: 
Submitter: Carsten Mueller <cmr@cs.tu-berlin.de>
Date: 12/2/94
Version: 106
System: x86-linux version, compiled with gcc 2.4.5 (?) and -O2 -finline-functions.
Severity: major
Problem: 
It happened to me when trying to build the ML kit interpreter.

GC #0.0.0.1.n.m:  run.x86-linux: Assertion failure (cm->map[card] <= mark) at
		"major-gc.c:464"

Looks like that was the first major collection to promote stuff from the first 
generation to the second.

As SML/NJ 106 is not quite *Standard* ML, I had to redefine some stuff in the
initial basis -- implode/explode and such.  Source code for this follows.

THe problem occurs whether using SML/NJ's arrays or not, so it is not related
to these.

The sparc version does not show this behavior.

Code: 
  (* Stuff to be loaded by 106 to make it *Standard ML* again. *)
  (* Does not take account of arrays and vectors. *)
  (* implode works correctly only for single-character strings (I need it just
  for this purpose). *)

  val sml_dump_file_name = "sml"		(* Choose whatever you like. *)

  exception Ord
  exception Chr = Char.Chr

  val chr = str o Char.chr

  val ord = fn s => if (s = "") then raise Ord else (Char.ord o sub) (s,0)

  val explode = (map str) o explode

  (* CAUTION: this implode takes only the leading characters. *)
  and implode = implode o map (fn s => sub (s,0))

  (*
  fun implode l =
    let
      fun imp [] s = s
	| imp (e::r) s = imp r (s ^ e)
    in
      imp l ""
    end;
  *)

  ;
  (exportML sml_dump_file_name;
   print Compiler.banner;
   print " [new runtime]\n[Standard ML stuff loaded]\n");

Comment: [jhr, 4/3/97]
  I'm not able to reproduce this one (and it will become obsolete with
  the new runtime).
Owner: jhr
Status: can't reproduce
----------------------------------------------------------------------
Number: 947
Title: Compiler bug: not found in spill
Keywords: 
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 12/7/94
Version: 106
System: DECstation 5000, Mach
Severity: major
Problem: 
  My port 106 on MACH decstations fails to compile a program that
  compiles fine on the alpha/OSF1.  The symptom is a compiler error:

	  Error: Compiler bug: not found in spill

  Unfortunately, I have not been able to narrow this down to a small
  example which fails.  A somewhat sizeable example (600kbytes tarred
  and gzipped) can be obtained by anonymous ftp from
  ftp.cs.cmu.edu:/afs/cs/project/fox/ftp/working/bug.tar.gz.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 948
Title: heap images too large
Keywords: 
Submitter: Peter Sestoft (sestoft@research.att.com)
Date: 12/9/94
Version: 105, 106
System: sparc
Severity: major
Problem: 
  Making some comparisons of the size of executables, I have come across
  a possible `space leak' in the exportFn function of sml/nj 105 and 106.  
  I compiled the humongous nucleic.sml benchmark program (3215
  lines) and got these sizes for the exported executable:

  sml/nj 0.93: 3682336 bytes (exportFn, share, Sparc)
  sml/nj 0.93:  565280 bytes (exportFn, noshare, Sparc)
  sml/nj 1.05: 2349852 bytes (exportFn, Sparc)
  sml/nj 1.06: 2613012 bytes (exportFn, Sparc)

  The file is ~sestoft/sml/benchmarks/nucleic/x.sml 
  
  [Zhong Shao, 1/8/95]
  In 107:  the binary size for ml-yacc.rs6000 for RS6000 is only 0.58Mbytes
	   for ml-yacc.sparc for sparc is nearly 2.8Mbytes

	   on the other hand, ml-lex.rs6000 is 2.55Mbytes, 
	   ml-lex.sparc is 2.56Mbytes, which is consistent.

  Comments: I think 0.58Mbytes is the correct size for ml-yacc. All the rest
	    potentially contain space leaks (due to exportML or exportFn)
Owner: 
Status: open
----------------------------------------------------------------------
Number: 949
Title: bad type error caused by integer literal overloading
Keywords: type checking, overloaded literals, error message
Submitter: John Reppy
Date: 12/11/94
Version: 106?
Problem:
  The error messages for overloading conflicts are really bad in 106.
  For example:

    Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime]
    - 1.0+1;
    std_in:7.5 Error: expected numeric type
      found type: real
    -

  Compare this with 0.93:

    Standard ML of New Jersey, Version 0.93, February 15, 1993
    val it = () : unit
    - 1.0+1;
    std_in:2.1-2.5 Error: operator and operand don't agree (tycon mismatch)
      operator domain: real * real
      operand:         real * int
      in expression:
	+ : overloaded (1.0,1)
    -

  Another report by Peter Sestoft (3/29/95).
  The expected and the actual type seem to be swapped in the following
  error message:

      - fun g s i = size s + i;
      val g = fn : string -> int -> int
      - g 12;
      std_in:46.1-46.4 Error: expected numeric type
	found type: string

  This also looks puzzling; note the explicit type ascription at the
  literal 12:

      - g 12 "";
      std_in:0.0-0.0 Error: operator and operand don't agree (tycon mismatch)
	operator domain: int
	operand:         string
	in expression:
	  g (12 : string) ""
      std_in:0.0-0.0 Error: expected numeric type
	found type: string

  Another report by Robert Findler <cs.rice.edu!robby>:

      > - datatype num = zero | one_more_than of num;
      > datatype num = one_more_than of num | zero
      > - one_more_than(0);
      > stdIn:33.15 Error: expected integer type,
      >   found type: num

      This error message seems to have the wrong sense.

Comments:
  Most people consider real to be a numeric type!

Fix: introduced LITERAL variant of tvinfo (in Types).  Overloaded
literals now initially get a type which is a LITERAL tyvar, with
an appropriate kind (litKind = INT | WORD | REAL | CHAR | STRING).

Tests: bug949.1.sml, bug949.2.sml, bug949.3.sml
Owner: dbm
Status: fixed in 109.26 [dbm]
----------------------------------------------------------------------
Number: 950
Title: signature matching clobbers inline status
Keywords: 
Submitter: Thomas Yan (tyan@cs.cornell.edu)
Date:           12/12/94
Version:        (?) all through 1.06.3
Severity:       minor
Problem:        signature matching clobbers inline status
Code:           littered throughout the compiler
Comments:       this was never entered as a bug; consequently,
                every release i wonder if this has been dealt
                with. since there are comments all over the
                compiler about this bug, i assume it still exists.
Owner: Zhong
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 951
Title: configuration problems, suggestions
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			Dec 14 1994
System(s) and Version:	Compiler, Runtime, Installation
SML/NJ Version: 	106.3
Machine: 		SPARC, Solaris2
Severity: 		minor
Problem: 		

1. The treatment of EXTRA_LIBS in the runtime/objs/ makefiles is incorrect.
   `makefile' adds $(EXTRA_LIBS) (via $(LIBS)) as a dependency for the
   $(RUNTIME) target. This is wrong for such libraries that are specified
   using `-l<lib>' syntax, as found in mk.sparc-solaris and a few other
   makefiles. I suggest splitting EXTRA_LIBS into SYS_LIBS and EXTRA_LIBS,
   such that `-l<lib>' specifications go into SYS_LIBS, and `<path>.o' and
   `<path>.a' specs go into EXTRA_LIBS. `makefile' should then only add
   $(EXTRA_LIBS) (not $(SYS_LIBS)) to the dependencies for $(RUNTIME).
   Both sets of libraries are used for linking though.

2. config/install.sh wrongly assumes that $PATH includes `.'. A
   simple fix is to rewrite the various calls to the `build' scripts
   to use the unambiguous notation `./build' instead.

3. I prefer to use Gnu ZIP instead of compress, since it tends to do a
   much better job than old compress. The following patch allows
   config/unpack.sh to recognize gzipped archives (a similar patch
   is needed for install.sh as well):

*** config/unpack.sh.~1~	Mon Nov 14 19:45:10 1994
--- config/unpack.sh	Mon Nov 28 19:46:23 1994
***************
*** 13,18 ****
--- 13,22 ----
      cd $SRCDIR
      echo "unpacking $OBJECT source files"
      zcat $TARFILE.Z | tar -xf -
+   elif [ -r $TARFILE.gz ]; then
+     cd $SRCDIR
+     echo "unpacking $OBJECT source files"
+     gunzip < $TARFILE.gz | tar -xf -
    elif [ -r $TARFILE ]; then
      cd $SRCDIR
      echo "unpacking $OBJECT source files"

4. The heap images produced using `exportFn' tend, for my applications,
   to be 3-4 times larger than in SML/NJ 1.03f or 0.93 . What used to
   be a 950K image is now over 3M, and ml-lex has grown from 400K to 2.5M!
   This also makes application start-up markedly slower.
   It appears that `exportFn' considers far too many objects to be live.
   (It is also a real pain having to deal with separate heap image files,
   runtimes, and scripts, but I suppose there are technical reasons
   for not producing a.out-ish executables any more.)
Comment: [John Reppy]
   Point 1: This has been fixed in 107.  EXTRA_LIBS are user libraries, while
     the "-l" libraries are specified by LD_LIBS.
   Point 2: Same as point 4 of bug 941.  It has been fixed in 107.
   Point 3: I think that we will continue to use compress to distribute
      our files, since it is more accessable (there are sites that don't
      have Gnu stuff installed).
   Point 4: this is probably the same as bug 948 [dbm].
Status: fixed in 107 (except for Point 4)
----------------------------------------------------------------------
Number: 952
Title: unsound imperative types
Keywords: type checking, value restriction, core dump
Submitter: Philip Santas (santas@inf.ethz.ch)
Date: 12/16/94
Version: 93, 106
System: SPARC (it shouldn't matter)
Severity: major
Problem: Unsound imperative types
         Imperative type variables with integer strengths
         do not work well with type parameters in functors
         A workaround in the end.
Code:

   local val ll = ref []
   in functor F(type t val x:t) =
	  struct val l = (ll := x :: (!ll); !ll)
		 (* here ll gets the type
		    ll : t list ref
		 *)
	  end 
   end;
   structure S1 = F(type t = int val x = 4);
   structure S2 = F(type t = int->int val x = fn x => x);
   hd(tl(S2.l)) 3   (* Applies an integer to an integer ... *)

Result:  Bus error 

Comments:
  The scope of 't is from its right to the first "end".
  but it manages to participate in the type of ll.
  Probably constraing scopes like this for type variables
  is too much.
  There is a workaround though:
  Since 't is not an abbreviation, try to do typing with
	     t = 'a
  when t escapes (ie. it should be viewed as a type variable
  out of the functor definition in case of no abbreviations)
  and then imperative type variables are at work.
  For instance, the following is not accepted:

  local val ll = ref []
  in functor F(type 'a t val x:'a t) =
	struct val l = (ll := x :: (!ll); !ll)
	end 
  end;

  reporting
	Error: nongeneric weak type variable
		 l : '0Y t list

  (actually, the error should occur at "ll").
  Instead of increasing the arity of t, it could be directly
  replaced by 'a *out* of its scope --otherwise we would get errors
  in the safe code

  functor F(type t val x: t) = struct
	 val ll = ref []
	 val l = (ll := x :: (!ll); !ll)
  end 

Comment: [dbm] Same as bug 905.
Fix: A "local" form for functor declarations is not part of SML 90
  or SML 96.  Eliminating this syntactic form should fix the bug.
Owner: dbm
Test: bug952.sml
Status: fixed in 109.26
----------------------------------------------------------------------
Number: 953
Title: Compiler bug: Extern: extern_sharing_tyc (sharing on functor type args)
Keywords: 
Submitter: Philip Santas (santas@inf.ethz.ch)
Date: 12/16/94
Version: 93, 106
System: SPARC
Severity: minor
Problem: Compiler Bug when specifying sharings on functor
         type arguments

Transcript:

- functor F(type t1)
          (type t2 sharing type t1=t2
                   sharing type t1 = int) = struct end;
Error: Compiler bug: Extern: extern_sharing_tyc

Comments:

 These sharings should not be allowed anyway.
 The reason is that the sharing
         t1=int
 should occur when t1 was declared, ie. in:

 functor F(type t1 sharing type t1=int)
          (type t2 sharing type t1=t2) = struct end;

Owner: dbm
Test: bug953.sml
Status: fixed in 109.20
----------------------------------------------------------------------
Number: 954
Title: unsound signatures with type abbreviations
Keywords: 
Submitter: Philip Santas (santas@inf.ethz.ch)
Date: 12/16/94
Version: 106
System: SPARC
Severity: major
Problem: Unsound Signatures with Type Abbreviations
Code:

  signature S1 = sig
      type t = int
      val x:t
  end

  signature S2 = sig
      type t = string
  end

  signature S3 = sig
      include S2
      include S1
  end;

  abstraction M3:S3 = struct type t=real val x=3.4 end;
			  (* ACCEPTED! *)

  M3.x ^ "Memory fault";

Comments:
  I do not understand what signature S3 includes.
  It seems to me that 
    (a) it should be rejected due to incompatible abbreviations
    (b) if it is to be accepted, then what is 't?
	int or string or any?
Owner: dbm
Test: bug954.sml
Status: fixed in 109.20 (causes duplicate spec error)
----------------------------------------------------------------------
Number: 955
Title: Compiler bug: PPVal.switch: none of the datacons matched (Compiler)
Keywords: 
Submitter: Bob Harper <Robert_Harper@TERRIER.FOX.CS.CMU.EDU>
Date: 12/30/94
Version: 0.93
Severity: major
Problem: 
  I'm trying to hack up a string parser for SML expressions

	  parse : string -> System.Ast.exp

  using the primitives in System.Compile, System.Env, and System.Ast.  So far no
  luck.  Here's what I do for testing purposes:

  val ppc =
	  { linewidth=80, flush = fn () => flush_out std_out,
	    consumer = outputc std_out };

  (* the first two arguments to makeSource are a total guess because the
     documentation doesn't explain what the hell they are!  instead it goes on
     about whether the fourth argument is necessary or not and whether the first
     ought to be an option.*)
  fun mk_source s =
	  System.Compile.makeSource ("exp", 100, open_string s, false, ppc);

  val pervEnv = System.Env.staticPart (!System.Env.pervasiveEnvRef);

  fun parse s = System.Compile.parse (mk_source s, pervEnv);

  But parse "43" bombs with the message above.

Comment: probably obsolete.
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 956
Title: Compiler bug: empty data types in equal.sml
Keywords: 
Submitter: Roderick Moten <rodmoten@cs.cornell.edu>
Date: 1/5/95
Version: sml-sc 106.3
System: sparc
Severity: major
Problem: 
  When testing for equality of two values of non-equal type the
  following message appears:

  Error: Compiler bug: empty data types in equal.sml

Code: 
  See /usr/local/sml/bugs/moten/bug.
  The file transcript contains the transcript, the rest of the directory
  contains the code.
Owner: dbm
Status: unreproducible [dbm, 4/16/97]
----------------------------------------------------------------------
Number: 957
Title: scoping of explicit type variables
Keywords: 
Submitter: Peter Sestoft (sestoft@research.att.com)
Date: 1995-01-06
Version: 0.93 and 106
System: presumably all (since it is a static semantics pbm.)
Severity: major deviance from the Definition, 
          few users will encounter the problem 

Problem: Explicit type variables are not handled (scoped?) correctly.

Code: 
  val f = fn x => let val b = fn (y:'_a) => y in x b end;

Transcript: The following should elaborate, but does not:

    - val f = fn x => let val b = fn (y:'_a) => y in x b end;
    std_in:0.0-0.0 Error: nongeneric weak type variable
      b : '1aU -> '1aU

Comments: It looks like a problem in the scoping of explicit type
variables in nested valbinds, since b and f can be defined at
top-level without complaints:

    - val b = fn (y:'_a) => y;
    val b = fn : '1a -> '1a
    - val f = fn x => x b;
    val f = fn : (('1a -> '1a) -> 'b) -> 'b

and also, the program is accepted if the explicit type variable is
deleted:

    - val f = fn x => let val b = fn y => ref y in x b end;
    val f = fn : (('1a -> '1a ref) -> 'b) -> 'b

In the original code fragment, the type '_a -> '_a of b *can* be
generalized because the rhs of `val b =' is non-expansive, and '_a
does not occur in the context.  Moreover, '_a *must* be generalized,
or else the second side condition in rule 17 fails, since '_a is
scoped at `val b' (Definition section 4.6).

(BTW, I have compiled ML Kit 1.0 for SGI MIPS in
 	/usr/local/sml/mlkit/bin/mips.irix5/kit
Although it isn't the final authority on the matter, it is a handy
tool in finding out whether one's interpretation of a piece of SML
code is right).
Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 958
Title: Ctrl-Z under AIX 4.1 
Keywords: 
Submitter:      Zhong Shao (shao-zhong@cs.yale.edu)
Date:		January 8, 1995
Version:        107
System:         RS6000 with AIX 4.1
Severity:       severe
Problem:        Ctrl-Z under AIX 4.1 
Code:           
     > sml
       ctrl-Z
     > fg
       ......

Transcript:     
     -
     uncaught exception Io "Input "<std_in>": read failed, I/O error"
     -
     uncaught exception Io "Input "<std_in>": read failed, I/O error"
     -
     uncaught exception Io "Input "<std_in>": read failed, I/O error"
     -
     uncaught exception Io "Input "<std_in>": read failed, I/O error"
     -
     .................


Comments: 
  Sometimes it works. Sometimes the above infinite loop occurs.
 
  [John Reppy, 1/8/95]
  This is interesting.  I have seen a similar problem under Irix 4.0.5, but
  it disappeared in Irix 5, so I didn't track it down.  It is most likely
  a new-runtime bug.  I'll try to fix the Irix 4 problem, which I hope
  will also fix the AIX 4 problem (I think that we are still running AIX 3.2).

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 959
Title: core dump on unboxed float record
Keywords: 
Submitter:      Zhong Shao (shao-zhong@cs.yale.edu)
Date:		January 17, 1995
Version:        106.4, 107 
System:         RS6000, MIPS and SPARC
Severity:       severe
Problem:        core dump on unboxed float record
Code:           
Transcript:     

     sml
     - (4.0,4.0);
     core dump ....

Comments: 
     The pretty printing (in ppval.sml) on unboxed float record value is 
     wrong. It assumes that the unboxedfloat record uses "realdArray"
     tag, but it actually uses "tag_string". 

Fix: 
     This bug is now fixed. The fix has to cast a string into a 
     realdArray, which is ugly. In the future when the new runtime
     system can fully support tag_realdArray or a new tag for unboxedfloat,
     the above can be cleaned up.

     The new "ppaval.sml" will be sent to you in my next message.

Status: fixed in 107.7
----------------------------------------------------------------------
Number: 960
Title: infinite loop on floating Div exception
Keywords: 
Submitter:      Zhong Shao (shao-zhong@cs.yale.edu)
Date:		January 17, 1995
Version:        107 
System:         on SPARC (solaris) and RS6000
Severity:       severe
Problem:        infinite loop on floating Div exception
Code:           
     - 4.0 / 0.0;
Transcript:     

     sml
     - 4.0 / 0.0;
     GC #0.0.0.0.1.1:   (40 ms.)
     GC #0.0.0.1.2.9:   (2010 ms.)
     GC #0.0.1.2.3.10:   (490 ms.)
     GC #0.1.2.3.4.17:  ^C (4010 ms.)
     ... starting infinite loop ...

Comments: 
     This bug only occurs in version 107 (it raises the exception correctly
     in both version 106 and 106.4). Even on 107, it seems to work on Alpha. 
     What changes have been done from 106.4 to 107? 

     integer division works fine; 3 div 0 would still raise the Div exception.

     [John Reppy]
     I reorganized the signal code in 107, so maybe I introduced the bug.
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 961
Title: include type overlaying [same as 929]
Keywords: 
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 1/19/95
Version: 107
Severity: major
Problem: 
  Respecification of a simple type spec introduced by include is not
  allowed.
Code: 
Transcript: 
  Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime]
  - signature s = sig type t end;
  signature s = sig type t end
  - signature ss = sig include s; datatype t = T end;
  std_in:7.20-7.45 Error: duplicate specifications for type constructor t in signature
  - 
Comments:
  According to the _Definition of Standard ML_ this should be legal
  (with the latest spec remaining visible).  I'm trying a simple fix for
  this bug (removing the error test from fun bind in
  elavorate/elabsig.sml).  If this is seen as an important feature,
  maybe it should be made an optional warning.
Comment: [dbm] Same as bug 929.
Owner: dbm
Test: bug961.sml
Status: open
----------------------------------------------------------------------
Number: 962
Title: debugging warning message left in [duplicate of 930]
Keywords: 
Submitter:      Lorenz Huelsbergen (lorenz@research.att.com)
Date:		1/19/95
Version:        103 and above
System:         all
Severity:       seems minor
Problem:        internal compiler message 
		"WARNING: Fundef <n> unused in freeClose"
		generated when compiling (albeit unreachable) code
|> Code:           
	signature S_SIG = 
	    sig
	    end
	
	structure S : S_SIG  =
	    struct
		fun f x = x 
	
		fun g ([],[]) = f (g ([],[]))
		  | g (x,[]) = f (g ([],[]))
	    end
Transcript:     
  radish 190; /usr/local/sml/103/bin/sml   
  loading /usr/local/sml/103/bin/.heap/sml.mipseb ......................... done
  Standard ML of New Jersey, Version 1.03, February 14, 1994 [new runtime]
  - use "bug.sml";
  [opening bug.sml]
  bug.sml:9.2-10.29 Warning: match nonexhaustive
	    (nil,nil) => ...
	    (x,nil) => ...

  GC #0.0.0.0.1.1:   (51 ms.)
  WARNING: Fundef 207 unused in freeClose
  signature S_SIG = sig  end
  structure S : S_SIG
  val it = () : unit
  - 
Comments:
  The above code is the smallest fragment I found that produces this
  warning; the signature, function f, and the tuples of list patterns 
  all seem necessary to generate this.  Code executes OK.

  [Zhong Shao]
  John pointed this out to me a while ago, but I forgot turning the warning
  message off (it is printed during the closure analysis, in 
  "cps/nfreeclose.sml"). It has no effect on correct execution of the program. 
  I'll send Lal the modified "/cps/nclosure.sml" file (which fixes the above)
  to be included in 108. Thanks,
Comment: duplicate of bug 930.
Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 963
Title: including signatures produces Compiler bug: getSigTSlots
Keywords: 
Submitter: Roderick Moten  <rodmoten@cs.cornell.edu>    
Date:    1-30-95       
Version:    107    
System:         Sun Sparc IPC / Sun OS
Severity:       major
Problem:        including signatures 
Code:           
  signature l =
    sig
      type i
      val k : unit -> i
      val j : i * i -> i
    end;
  signature k =
  sig
      type i
      val k : unit -> int * i
      val j : i * i -> i
    end;
Transcript:   
  - signature p = sig include l include k end;
  std_in:35.19-35.38 Error: duplicate specifications for variable or constructor k in signature
  std_in:35.19-35.38 Error: duplicate specifications for variable or constructor j in signature
  Error: Compiler bug: getSigTSlots
Owner: dbm
Test: bug963.sml
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 964
Title: Compiler bug: applyTyfun: not enough arguments (compiling functor)
Keywords: 
Submitter: Edo Biagioni (esb@KITSUNE.FOX.CS.CMU.EDU)
Date: 1/30/95
Version: 106? 107?
Severity: major
Problem: 
   The bug appears to be related to having parametrized type
   abbreviations being used in contexts where the parameter is
   not defined, i.e. polymorphic; see the signature S below.
   The compiler error message is:
     Error: Compiler bug: applyTyfun: not enough arguments
Code: (bug964.sml)
  signature S =
   sig
    type 'a T = 'a
    val f: 'a T -> unit
   end (* sig *)

  (* either the functor or the structure (or both) will exercise the error. *)

  functor F (structure L: S): S =
   struct
    open L
   end

  structure ST: S =
   struct
    type 'a T = 'a
    fun f x = ()
   end

  (* another example from Ken Cline *) (bug964.1.sml)
  signature DECL =
   sig
    type 'a snark = 'a list
    datatype x = Y of int snark
   end;

  functor Test (structure Decl: DECL) =
   struct
    fun test (Decl.Y _) = ()
   end;

Comment: possibly related to bug 932.  Here is a short example from
  Robert Findler <Robert_Findler@INBOX.FOX.CS.CMU.EDU> (3/13/95)
  that doesn't involve functors and produces the same error message
  (in 107 and 107.7): (bug964.2.sml)

    - structure S : sig type 'a t = 'a end = struct type 'a t = 'a end;
    Error: Compiler bug: applyTyfun: not enough arguments

Owner: dbm
Test: bug964.sml, bug964.1.sml
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 965
Title: redundant datatype error message
Keywords: 
Submitter: 		appel
Date: 			Feb 1, 1995
System(s) and Version:	SML/NJ
SML/NJ Version: 	107.2
Machine: 		all
Severity: 		minor
Problem: 		Redundant datatype error message
Code:			

   functor F (datatype a = A of int * int) = struct end
   structure S = F(datatype a = A of int)

Transcript: 		
- use "foo.sml";
[opening foo.sml]
foo.sml:3.15-3.38 Error: The constructor A of datatype a
has different representations in the signature and the structure.  
Change the definition of the types carried by the constructors in the
functor formal parameter and the functor actual parameter so that
they are both abstract, or so that neither is abstract.

foo.sml:3.15-3.38 Error: value type in structure doesn't match signature spec
    name: A
  spec:   int * int -> _
  actual: int -> a

Comments:
   The first error message (about representations) should not appear
  if there is a genuine semantic error.
Owner: dbm
Status: obsolete
----------------------------------------------------------------------
Number: 966
Title: parsing large comments blows compiler away
Keywords: 
Submitter: 		Ken Zadeck zadeck@watson.ibm.com
Date: 			2/2/95
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		RS6000, AIX
Severity: 		minor though embarrassing
Problem: 		parsing large comments blows compiler away
Code:			any 800k comment (* nested comments not required *)
Comments:		we had commented out a large piece of computer generated code.
Transcript:

- use "comment2.sml";
[opening comment2.sml]

[Major collection... 38% used (2552312/6692292), 490 msec]

[Major collection... 86% used (5492516/6366364), 1230 msec]

[Increasing heap to 18652k]

[Major collection...
[Increasing heap to 28728k]
 88% used (9290916/10497588), 2240 msec]
...

[Increasing heap to 127548k]

[Increasing heap to 127576k]

[Increasing heap to 127604k]

Warning: can't increase heap

Ran out of memory
Status: fixed ("in recent versions"  - Appel)
----------------------------------------------------------------------
Number: 967
Title: Compiler bug: translate.transpath on unexpected access
Keywords: 
Submitter: 		John Reppy (jhr@research.att.com)
Date: 			Feb 3, 1995
System(s) and Version:	Compiler
SML/NJ Version: 	107.2
Machine: 		any
Severity: 		minor
Problem:
  When compiling stuff in the sml-nj/boot directory I got
    Error: Compiler bug: translate.transpath on unexpected access
Transcript:
Repairing blast GC (maxGen = 5 of 5)
[wrote bin.mipseb/NEWbuilt-in.sml.bin]
Error: Compiler bug: translate.transpath on unexpected access

!* CM error: (sorry, can't be more specific)

Comments:
  The problem was a reference to PrimTypes; changing that to PrimTypes1 fixed
  the problem, but a better error message would be nice.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 968
Title: overflow is not detected for integer subtraction
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           2/10/95
Version:        0.93
System:         Sparc IPC, both SunOS 4.1.1 and Solaris 5.3
Severity:       major
Problem:        Overflow is not detected for integer subtraction
Code:           fun t (a:int) c = a-c;
Transcript:    	- op - (1072807032,~2496144);
		uncaught exception Overflow
		(* however: *)
		- fun t (a:int) c = a-c;
		val t = fn : int -> int -> int
		- t 1072807032 ~2496144;
		val it = ~1072180472 : int
		(* NOTE: exception is raised in 1.07 under SunOS *)
Comments:	This might be a duplicate of 780.  I detected
		this by a simultaneous execution of bigint code
		from the sml-nj-lib; to my surprise, instead of
		finding no bugs or a bug in the bigint code, i
		found this problem with the small int code!
Owner: John
Status: fixed in 109.21 [new basis]
----------------------------------------------------------------------
Number: 969
Title: error in function recordDesc in cpscompile/ctreeify.sml
Keywords: 
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 2/13/95
Version: 107.7
Severity: major
Problem: 
  The function recordDesc in cpscompile/ctreeify.sml had the clause for
  pairs "(_, 2)" listed before the clause for blocks of int32's
  "(Access.RK_I32BLOCK, _)".  In practice, this meant that the closure
  phase created pairs of int32's using desc_pair for the descriptor
  instead of tag_string.

  This resulted in warnings of the form:

      /afs/cs.cmu.edu/project/fox-7/member/cline/port/107/bin/.run/run.alpha32-osf1: Error -- external address 0x8000 not registered

  during exportML, and is suspected to have caused segmentation
  violations.
Fix:
A corrected version of recordDesc appears below.

ctreeify.sml:

	  fun recordDesc (kind, content) =
	    let
	      val l = List.length content
	    in
	      case (kind, l)  of
		(Access.RK_VECTOR, _)   => T.make_desc (l, T.tag_record)
	      | (Access.RK_FCONT, _)    => T.make_desc (l*4, T.tag_string)
	      | (Access.RK_FBLOCK, _)   => T.make_desc (l*4, T.tag_string)
	      | (Access.RK_I32BLOCK, _) => T.make_desc (l*4, T.tag_string)
	      | (_, 2)                  => T.desc_pair
	      | _                       => T.make_desc (l, T.tag_record)
	    end

Owner: Lal
Status: fixed in 109.25.x [Lal]
----------------------------------------------------------------------
Number: 970
Title: Warning: binding contains no variables
Keywords: 
Submitter:      Lal George
Date:		2/14/95
Version:        107.4
System:         all
Severity:       minor
Problem:        Warning: binding contains no variables
Code:           
  datatype 'a tbl = H of {t: 'a Array.array, s:int};
  fun new(n,a) = H{t=Array.array(n,a), s=n};
  val c : int tbl = if false then new(32,0) else new(32,100);

 Andrew suggests this even simpler version

  val a: int = if false then 1 else 2;	

Transcript:

  - datatype 'a tbl = H of {t: 'a Array.array, s:int};
  datatype  'a tbl
    con H : {s:int, t:'a array} -> 'a tbl

  - fun new(n,a) = H{t=Array.array(n,a), s=n};
  val new = fn : int * 'a -> 'a tbl

  - val c : int tbl = if false then new(32,0) else new(32,100);
  std_in:36.1-36.58 Warning: binding contains no variables 	<<<<<<------
	    true = ...
  val c = H {s=32,t=[|100,100,100,100,100,100,100,100,100,100,100,100,...|]}
    : int tbl
  -
Comments:
	I have no idea what the warning message is complaining about.
	This does not occur in 0.93.
Fix: [Andrew]
Try this fix (though I'm not quite sure about it):  In elaborate/elabcore.sml,
replace the "bindpat" function with this:

fun bindpat pp =
    case pp 
     of VARpat(VALvar{access=INLINE(_),...}) => false
      | VARpat(VALvar{access=LVAR v,...}) => false
      | CONSTRAINTpat(p,_) => bindpat p
      | MARKpat(p,_) = bindpat p
      | _ => true

Status: fixed in 107.7 +
----------------------------------------------------------------------
Number: 971
Title: -p is not a legal option for uname
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           2/15/95
Version:        1.07, .arch-n-opsys script
System:         sparc, solaris
Severity:       <minor, major, or critical>
Problem:        -p is not a legal option for uname
Comments:	I don't know if this is just our local setup,
		but uname -p also does not work on our sunos sparcs.
Fix:		(Workaround?) assume sunos means sparc, and
		delete the uname -p check.
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 972
Title: memory fault caused by errors in cpscompile/mltreeGen.sml
Keywords: 
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 2/17/95
Version: 107, 107.4
Severity: major
Problem: 
  The semantic actions reg_MKSPECIAL_ureg_reg and reg_SETSPECIAL_reg_ureg
  in cpscompile/mltreeGen.sml were implemented incorrectly.  Diffs for
  a corrected version (from SML/NJ 107, _not_ 107.4) appear below.  Here
  is an example of what happens without the fix:
Transcript: 
    Standard ML of New Jersey, Version 107, December 25, 1994 [Batch SC 69(jhr)]
    val it = () : unit
    - datatype U = Empty | Delay of int;
    datatype  U
      con Delay : int -> U
      con Empty : U
    - System.Unsafe.Susp.force (System.Unsafe.Susp.delay (fn _ => Empty));
    /afs/cs/project/fox/member/cline/port/107/bin/sml-scb[99]: 20275 Memory fault
Fix:
*** 1.1	1995/02/16 16:00:29
- --- mltreeGen.sml	1995/02/16 18:42:41
***************
*** 658,664 ****
  	      in
  		GPR (M.SEQ (first,
  		     M.SEQ (second,
! 		     M.SEQ (M.MV (tmp, C.allocptr),
  		     M.SEQ (M.MV (C.allocptr, M.ADD (C.allocptr, M.LI 8)),
  			    tmp)))))
  	      end
- --- 658,664 ----
  	      in
  		GPR (M.SEQ (first,
  		     M.SEQ (second,
! 		     M.SEQ (M.MV (tmp, M.ADD (C.allocptr, M.LI 4)),
  		     M.SEQ (M.MV (C.allocptr, M.ADD (C.allocptr, M.LI 8)),
  			    tmp)))))
  	      end
***************
*** 923,931 ****
  	  | (Burm.reg_SETSPECIAL_reg_ureg kids, EX(_,_,order)) =>
  	      let
  		val (GPR r1, GPR r2, ord) = walk2 (kids, order)
- - 		val sw = if ord=M.LR then (fn x => x) else (fn (a,b,c)=>(b,a,c))
  	      in
! 		NOTHING (M.STORE32 (r1,			    (* XXX incorrect *)
  				    M.ORB (M.SLL (r2,
  						  M.LI T.width_tags,
  						  M.LR),
- --- 923,930 ----
  	  | (Burm.reg_SETSPECIAL_reg_ureg kids, EX(_,_,order)) =>
  	      let
  		val (GPR r1, GPR r2, ord) = walk2 (kids, order)
  	      in
! 		NOTHING (M.STORE32 (M.SUB (r1, M.LI 4, M.LR),
  				    M.ORB (M.SLL (r2,
  						  M.LI T.width_tags,
  						  M.LR),

Owner: 
Status: open
----------------------------------------------------------------------
Number: 973
Title: datatypes aren't generative
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           2/18/95
Version:        1.07
System:         sparc
Severity:       minor (? major -- unlikely to cause errors?)
Problem:        datatypes aren't generative
Code:           datatype a=A; val a=A; fun f A = 7; datatype a=A; f a
Transcript:     
	(* note: different behavior if batch-compile this
	  instead of typing it in line by line
	 *)
		- datatype a = A;
		datatype  a
		  con A : a
		- val a = A;
		val a = A : a
		GC #0.0.0.0.1.1:   (10 ms.)
		- fun f A = 7;
		val f = fn : a -> int
		- datatype a = A;
		datatype  a
		  con A : a
	(* should have a = A:?.a, f a = 7, f A undefined *)
		- a;
		val it = A : a
		- f a;
		val it = 7 : int
		- f A;
		val it = 7 : int
	(* note that pretty-printing is messed up *)
		- datatype b = A;
		datatype  b
		  con A : b
		- a;
		val it = A : a
	(* however, compiler correctly rejects f A *)
		- f A;
		std_in:18.1-18.3 Error: operator and operand don't agree (tycon mismatch)
		  operator domain: a
		  operand:         b
		  in expression:
		    f A
Comments:	declaring new constructors, e.g. datatype a = A | B,
		seems to unconfuse the compiler.  this is almost
		a feature: reloading the same datatype
		declaration does not invalidate code already compiled.

		i haven't tested it, but maybe this means that
		functor application doesn't create new types,
		either.
Owner: dbm
Status: not a bug [it's a feature]
----------------------------------------------------------------------
Number: 974
Title: running sc.make multiple times produces different sized heap images
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           2/18/95
Version:        1.07 
System:         sparc, solaris 5.3
Severity:       minor
Problem:        running sc.make () multiples times with
		different files loaded produces different size
		heap images and or fails to compile.
Code:           omitted; i dont' know how to isolate the
		problem.  i can send tar file...
Transcript:     here's a more complete description.

		we have installed sml with sc (sml-sc) and
		compiled .bin files for
		smlnj-lib/107-sources.sc, cml, and exene.  i
		have exported a heap file with all of the latter
		three included (exene-sc).

		i then compiled AML with modifications for 1.07
		with sc.make() under exene-sc.  successive runs
		first produce a heap image of size 4721088;
		subsequent runs have size 3271276.

		however, under sml-sc, compilation does not get
		very far (note that i've tried sc.make() twice):

    loading /usr/u/sml/src/107/bin/.heap/sml-sc.sparc ......................... done
    Standard ML of New Jersey, Version 107, December 25, 1994 [SC 69(jhr)]
    val it = () : unit
    - sc.make();
    GC #0.0.0.0.1.1:   (0 ms.)
     Defining the group...
    [scanning sources.sc]
    [scanning /usr/u/sml/src/107/src/smlnj-lib/107-sources.sc]
     Compiling...
    GC #0.0.0.0.2.35:   (0 ms.)
    GC #0.0.0.0.3.72:   (10 ms.)
    GC #0.0.0.0.4.133:   (10 ms.)
    GC #0.0.0.0.5.194:   (10 ms.)
    GC #0.0.0.0.6.286:   (10 ms.)
    GC #0.0.0.1.7.404:   (30 ms.)
    GC #0.0.0.1.8.499:   (10 ms.)
    GC #0.0.0.1.9.614:   (20 ms.)
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/finalize-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/100-finalizer.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/100-time-limit.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/lib-base-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/106-lib-base.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array-qsort.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array-sort-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array2-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/array2.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/ord-key-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/dict-sig.sml.bin]
    GC #0.0.0.1.10.630:   (50 ms.)
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/binary-dict.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/ord-set-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/binary-set.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/106-ctype-sig.sml.bin]
    [reading /usr/u/sml/src/107/src/smlnj-lib/.sparc/106-ctype.sml.bin]
    lookup cHC+ dTrkUa3
    lookupyNi1;l    Aotr
    lookup ,y5Z?D)m6f<D%
    lookup Sx]QLK6-
                   W"1
    lookup  Z`)b}9&,}Fy
     
    uncaught exception Compile: "imported objects not found or inconsistent"
    - sc.make();
     Defining the group...
    [scanning sources.sc]
    [scanning /usr/u/sml/src/107/src/smlnj-lib/107-sources.sc]
     Compiling...
    GC #0.0.1.2.11.696:   (110 ms.)
    GC #0.0.1.3.12.782:   (50 ms.)
    GC #0.0.1.3.13.862:   (10 ms.)
    GC #0.1.2.4.14.962:   (110 ms.)
    GC #0.1.2.4.15.1087:   (20 ms.)
    GC #0.1.2.4.16.1231:   (10 ms.)
    lookup cHC+ dTrkUa3
    lookupyNi1;l    Aotr
    lookup ,y5Z?D)m6f<D%
    lookup Sx]QLK6-
                   W"1
    lookup  Z`)b}9&,}Fy
     
    uncaught exception Compile: "imported objects not found or inconsistent"
Comment: [John Reppy]
  There are some problems with the sizes of exported images; I don't think 
  that they have anything to do with SC.  We no longer use SC (it hasn't
  been supported by its author for over a year).  As of 107.3, we are using
  CM; this will probably fix the other problem you mentioned.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 975
Title: incorrect code for x86 for storeindexb
Keywords: 
Submitter: Lorenz Huelsbergen <lorenz@research.att.com>
Date: 2/18/95
Version: 107.4?
System: x86
Severity: major
Problem: 
  All versions of the x86 codegen generate incorrect code 
  in some (seemingly rare) cases of storeindexb.  This bug
  may have to do with the recent problems in compiling the
  compiler with cm in 107.4.  I do not have a small example
  that generates this bug -- it occurred when stack-frame 
  based virtual registers were added to the x86 CG and then
  only when loading the compiler's bin files.
Fix: in x86/x86.sml, in function storeindexb, add a tick:

	 | (Direct y',	Displace _) => (V.movl (z,tempreg);
					storeb' (x,Index (y',0,tempreg',Byte)))
(* was:					storeb (x,Index (y',0,tempreg',Byte)))
 *)
Owner: Lorenz
Status: fixed
----------------------------------------------------------------------
Number: 976
Title: x / 0.0 causes infinite(?) consing loop
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			Feb 21, 1995
System(s) and Version:	
SML/NJ Version: 	107
Machine: 		SPARC Solaris 2.4
Severity: 		major
Problem: 		x / 0.0 causes infinite(?) consing loop
Code:			1.0 / 0.0;
Transcript:
  Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime]
  - 1.0 / 0.0;
  GC #0.0.0.0.1.1:   (60 ms.)
  GC #0.0.0.1.2.9:   (3030 ms.)
  GC #0.0.1.2.3.10:   (640 ms.)
  GC #0.1.2.3.4.17:   (6130 ms.)
  GC #1.2.3.4.5.18:   (6630 ms.)
  ^C
  Interrupt
  - ^D GC #2.3.4.5.6.24:   (180 ms.)
Comment: [John Reppy]
  This may be related to problems with imprecise interrupts on the
  SPARC.  There are already some bug reports about this in the
  masterbugs file.
Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 977
Title: sml > "a non-tty device" can cause GC failures
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			Feb 21, 1995
System(s) and Version:	runtime
SML/NJ Version: 	107
Machine: 		SPARC, Solaris 2.4
Severity: 		minor
Problem: 		sml > "a non-tty device" can cause GC failures
Code:			(many KLOC; too large to send)
Transcript: 		
  A colleague of mine has a medium-size SML program (> 5 KLOC).
  He "use"d the sources and exported an image.

  When executing this image with stdout referring to a tty
  device, everything goes well.

  Executing with stdout redirected to /dev/null or some other
  non-tty device causes the message below:

  GC #0.0.0.0.1.1:   (0 ms.)
  GC #0.0.0.1.2.16:  /u/pelab/sml/bin/.run/run.sparc-solaris: Fatal error 
  -- unknown tag 0xa @ 0xeeba00b4 in array arena

Owner: 
Status: open
----------------------------------------------------------------------
Number: 978
Title: Compiler bug: getSigTSlots from duplicate type specs
Keywords: 
Submitter: Roderick Moten <rodmoten@cs.cornell.edu>     
Date:    2/22/95       
Version:  107      
System:      Sparc 10, SunOS
Severity:       minor
Problem:   Error: Compiler bug: getSigTSlots
Code:     signature k = sig type k type k = int end;      
Transcript: 
  - signature k = sig type k type k = int end;
  std_in:0.0-14.9 Error: duplicate specifications for type constructor k in signature
  Error: Compiler bug: getSigTSlots 
Owner: dbm
Test: bug978.sml
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 979
Title: creating `real'-only tuple causes SIGSEGV
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			Feb 26, 1995
System(s) and Version:	
SML/NJ Version: 	107
Machine: 		SPARC - Solaris 2.4 and SunOS 4.1.3; SGI - IRIX 5.2
Severity: 		major
Problem: 		creating `real'-only tuple causes SIGSEGV
Code:			{1=15.0}
Transcript:
  Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime]
  - {1=15.0, 2=3};
  val it = (15.0,3) : real * int
  - {1=15.0};
  /files/pelab1/local/bin/sml[99]: 4578 Segmentation Fault(coredump)
Status: fixed in 107.7
----------------------------------------------------------------------
Number: 980
Title: correct code can trigger a fatal error in the GC
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			Feb 27, 1995
System(s) and Version:	runtime
SML/NJ Version: 	107
Machine: 		SPARC; both Solaris 2.4 and SunOS 4.1.3
Severity: 		major
Problem: 		correct code can trigger a fatal error in the GC
Code:			

===start of "ipc91-5.sml"===
(* Internet Programming Contest 1991, Problem 5 *)

(* utilities *)

fun flatten [] = []
  | flatten (xs::ys) = xs @ (flatten ys);

(* ex *) flatten [[1,2],[4,3]];

fun ind 0 = "\n"
  | ind n = ind (n-1)^" ";

fun wvars [x] = x
  | wvars (x::xs) = x^","^wvars xs;

fun impl [] = ""
  | impl (xs::ys) = xs^impl ys;  

fun unparse plist = impl (flatten (map (fn (str, vl) => [str, "writeln("^wvars vl^")"]) (rev plist)));

(* special-cons f|r listorna som representerar programmet *)
fun cons2 ((s1,l1),[(s2,l2)]) = [(s1^s2,l1@l2)]
  | cons2 ((s1,l1),(s2,l2)::xs) = (s2,l1@l2)::(cons2 ((s1,l1),xs));

(* ex *) cons2 (("else", ["b","a"]),[ ("else", ["d","c"]), ("if c<d then ", ["c","d"])  ]);

(* som cons2, men beh}ll split *)
fun cons3 ((s1,l1),[(s2,l2)]) = [(s1^s2,(l1,l2))]
  | cons3 ((s1,l1),(s2,l2)::xs) = (s2,(l1,l2))::(cons3 ((s1,l1),xs));

(* list product *)
fun crossprod ([],_) = []
  | crossprod (x::xs, ys) = cons3 (x,ys) @ crossprod (xs, ys); 


(* mergar och levererar en lista som ska tolkas bakl{nges 
   (pga att cons2 ska bli enklare *)
fun merge ([], []) = [("",[])]
  | merge ([], y::ys) = cons2 (("",[y]), merge (ys, []))
  | merge (x::xs, []) = cons2 (("",[x]), merge (xs, []))
  | merge (x::xs, y::ys) =
      cons2 ((ind(2)^"else ", [y]), merge (x::xs, ys))
    @ cons2 (("if "^x^"<"^y^" then"^ind(2), [x]), merge (xs, y::ys))
;

(* ex *) merge (["a"],["b"]); 
 
fun mergelists (a,b) = 
  flatten (map ( fn (str,(l1,l2)) => cons2 ((str,[]), merge (l1,l2))) (crossprod (a,b)));

(* ex *) mergelists ([ ("else", ["b","a"]), ("if a<b then ", ["a","b"])  ],
	   [ ("else", ["d","c"]), ("if c<d then ", ["c","d"])  ]);

(* somthing like ordinary mergesort *)
fun split2 [] = ([],[])
  | split2 [x] = ([x],[])
  | split2 (x::y::zs) =
      let
        val (M,N) = split2 zs
      in
        (x::M, y::N)
      end;

(* something like insertion sort *)
fun split1 [] = ([],[])
  | split1 (x::ys) = ([x],ys);

fun mergesort _ [] = [("",[])]
  | mergesort _ [x] = [("",[x])]
  | mergesort split L =
   let
     val (M,N) = split L;
     val M = mergesort split M;
     val N = mergesort split N
   in
     mergelists (M,N)
   end;

(* ex *) mergesort split1 ["a","b","c"]; 

fun listgen 0 = []
  | listgen n = listgen (n-1) @ [String.implode[Char.chr (n-1+Char.ord #"a")]];

fun pascalsort split n = 
 let val lista = listgen n;
     val progstr = "program sort(input,output);\n"^
                   "var "^wvars lista^" : integer;\n"^
		   "begin\n"^
                   "  readln("^wvars lista^");\n  "^
		   unparse (mergesort split lista)^
                   "\nend.\n";
 in
   print progstr
 end;

(* ex *) pascalsort split2 4;
(* ex *) pascalsort split2 6;
===end of "ipc91-5.sml"===

Transcript: 		

Script started on Mon Feb 27 17:18:52 1995
sen14_1_sml
loading /files/pelab1/ml/sml-107/bin/.heap/sml.sparc ......................... done
Standard ML of New Jersey, Version 107, December 25, 1994 [new runtime]
- use "ipc91-5.sml";
[opening ipc91-5.sml]
val flatten = fn : 'a list list -> 'a list
val it = [1,2,4,3] : int list
val ind = fn : int -> string
ipc91-5.sml:13.1-14.34 Warning: match nonexhaustive
          x :: nil => ...
          x :: xs => ...
  
GC #0.0.0.0.1.9:   (10 ms.)
val wvars = fn : string list -> string
val impl = fn : string list -> string
val unparse = fn : (string * string list) list -> string
ipc91-5.sml:22.1-23.66 Warning: match nonexhaustive
          ((s1,l1),(s2,l2) :: nil) => ...
          ((s1,l1),(s2,l2) :: xs) => ...
  
val cons2 = fn
  : (string * 'a list) * (string * 'a list) list -> (string * 'a list) list
val it = [("else",["b","a","d","c"]),("elseif c<d then ",["b","a","c","d"])]
  : (string * string list) list
ipc91-5.sml:28.1-29.68 Warning: match nonexhaustive
          ((s1,l1),(s2,l2) :: nil) => ...
          ((s1,l1),(s2,l2) :: xs) => ...
  
val cons3 = fn
  : (string * 'a) * (string * 'b) list -> (string * ('a * 'b)) list
val crossprod = fn
  : (string * 'a) list * (string * 'b) list -> (string * ('a * 'b)) list
val merge = fn : string list * string list -> (string * string list) list
val it = [("\n  else ",["b","a"]),("if a<b then\n  ",["a","b"])]
  : (string * string list) list
GC #0.0.0.0.2.37:   (10 ms.)
val mergelists = fn
  : (string * string list) list * (string * string list) list
    -> (string * string list) list
val it =
  [("\n  else ",["d","c","b","a"]),("\n  else ",["d","b","c","a"]),
   ("\n  else if b<c then\n  if a<c then\n  ",["d","b","a","c"]),
   ("\n  else ",["b","d","c","a"]),
   ("\n  else if a<c then\n  ",["b","d","a","c"]),
   ("elseif b<d then\n  if a<d then\n  ",["b","a","d","c"]),
   ("\n  else ",["c","d","b","a"]),("\n  else ",["c","b","d","a"]),
   ("\n  else if b<d then\n  if a<d then\n  ",["c","b","a","d"]),
   ("\n  else ",["b","c","d","a"]),
   ("\n  else if a<d then\n  ",["b","c","a","d"]),
   ("elseif c<d then if b<c then\n  if a<c then\n  ",["b","a","c","d"]),...]
  : (string * string list) list
val split2 = fn : 'a list -> 'a list * 'a list
val split1 = fn : 'a list -> 'a list * 'a list
val mergesort = fn
  : (string list -> string list * string list)
    -> string list -> (string * string list) list
val it =
  [("\n  else ",["c","b","a"]),("\n  else if a<b then\n  ",["c","a","b"]),
   ("\n  else if a<c then\n  ",["a","c","b"]),("\n  else ",["b","c","a"]),
   ("\n  else if a<c then\n  ",["b","a","c"]),
   ("if b<c then\n  if a<b then\n  ",["a","b","c"])]
  : (string * string list) list
val listgen = fn : int -> string list
val pascalsort = fn : (string list -> string list * string list) -> int -> unit
program sort(input,output);
var a,b,c,d : integer;
begin
  readln(a,b,c,d);
  if a<c then
  if b<d then
  if a<b then
  if c<b then
  writeln(a,c,b,d)
  else if c<d then
  writeln(a,b,c,d)
  else writeln(a,b,d,c)
  else if a<d then
  if c<d then
  writeln(b,a,c,d)
  else writeln(b,a,d,c)
  else writeln(b,d,a,c)
  else if a<d then
  if c<d then
  writeln(a,c,d,b)
  else if c<b then
  writeln(a,d,c,b)
  else writeln(a,d,b,c)
  else if a<b then
  if c<b then
  writeln(d,a,c,b)
  else writeln(d,a,b,c)
  else writeln(d,b,a,c)
  else if b<d then
  if c<b then
  if a<b then
  writeln(c,a,b,d)
  else if a<d then
  writeln(c,b,a,d)
  else writeln(c,b,d,a)
  else if c<d then
  if a<d then
  writeln(b,c,a,d)
  else writeln(b,c,d,a)
  else writeln(b,d,c,a)
  else if c<d then
  if a<d then
  writeln(c,a,d,b)
  else if a<b then
  writeln(c,d,a,b)
  else writeln(c,d,b,a)
  else if c<b then
  if a<b then
  writeln(d,c,a,b)
  else writeln(d,c,b,a)
  else writeln(d,b,c,a)
end.
val it = () : unit
GC #0.0.0.0.3.66:  /files/pelab1/ml/sml-107/bin/.run/run.sparc-solaris: Fatal error -- unknown tag 0xa @ 0xee4400f0 in array arena

sen14_2_exit
sen14_3_exit

script done on Mon Feb 27 17:19:09 1995

Comments:		

I reported this bug a week or so ago, but then didn't have the code to
reproduce it. Also, then I wrote that the bug depended on whether stdout
was redirected to a non-tty or not. This code appears to always trigger
the bug.

Owner: John
Status: obsolete [new runtime]
----------------------------------------------------------------------
Number: 981
Title: abstraction decl causes Compiler bug: Unexpected RELtyc in transtypes
Keywords: 
Submitter: Andrew Appel, Dave MacQueen
Date: 2/28/95
Version: 107.3
Severity: major
Problem: 
  Elaborating an equality expression using datacons imported
  from an abstraction whose signature was pickled fails with
  "Compiler bug: Unexpected RELtyc in transtypes".  The data
  constructor needs to be transparent.
Code: 
**** a.sig ****
signature S =
sig
  datatype d = A of int*int
end

abstraction X : S =
struct
  datatype d = A of int*int
end
**** a.sml ****
structure G = struct
  fun f(x: X.d,y) = x<>y
end

Transcript: 
  radish$ /usr/local/sml/107.3/bin/sml-cm
  loading /usr/local/sml/107.3/bin/.heap/sml-cm.mipseb ......................... done
  Standard ML of New Jersey, Version 107.3, February 7, 1995 [CM&CMB 1]
  val it = () : unit
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [dependency analysis completed]
  [recovering .mipseb/a.sig.bin... done]
  [compiling a.sml -> .mipseb/a.sml.bin]
  Repairing blast GC (maxGen = 5 of 5)
  [wrote .mipseb/a.sml.bin]
  val it = () : unit
  - CM.make();
  [starting dependency analysis]
  [parsing a.sig]
  [parsing a.sml]
  [dependency analysis completed]
  [compiling a.sig -> .mipseb/a.sig.bin]
  GC #0.0.0.0.1.18:   (5 ms.)
  Repairing blast GC (maxGen = 5 of 5)
  [wrote .mipseb/a.sig.bin]
  [compiling a.sml -> .mipseb/a.sml.bin]
  Repairing blast GC (maxGen = 5 of 5)
  [wrote .mipseb/a.sml.bin]
  val it = () : unit
  - 
  - ^Dradish$ rm .mipseb/a.sml.bin
  radish$ /usr/local/sml/107.3/bin/sml-cm
  loading /usr/local/sml/107.3/bin/.heap/sml-cm.mipseb ......................... done
  Standard ML of New Jersey, Version 107.3, February 7, 1995 [CM&CMB 1]
  val it = () : unit
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [dependency analysis completed]
  [recovering .mipseb/a.sig.bin... done]
  [compiling a.sml -> .mipseb/a.sml.bin]
  Error: Compiler bug: Unexpected RELtyc in transtypes

  !* CM error: (sorry, can't be more specific)
Fix: move call of Fixup.fixupStr into functions exported by Instantiate
  so that it will be called for abstraction declarations as well as
  after functor formal parameter instantiation.
  [dbm: the exact form of the fix might be improved a bit.  fixupStr
   doesn't need to be called everywhere that instantiate_argument
   is called.]
Status: fixed in 107.7
----------------------------------------------------------------------
Number: 982
Title: there are no ways to query the implementation of math
Keywords: 
Submitter: 		Ken Zadeck
Date: 			3/3/95
System(s) and Version:	all
SML/NJ Version: 	0.93
Machine: 		
Severity: 		frustrating
Problem: 		there are no ways to query the implementation of math
It would be very useful to be able to ask about the precision of
integers,  i.e., how many bits, largest number, smallest number.
I know that these things are written down, but given that there will
be 64 bit machines in the future, (and the possibility of using all 32
bits for some types) it would be nice to be able to write
code that always works.

The same is true for reals but I do not use them so I do not know what
the correct specific complaints should be.

Comment: [John Reppy]
The new standard basis that we are designing (in collaboration with
Harlequin and Moscow ML) includes:

    val precision : int option
    val minInt : int option
    val maxInt : int option

in the INTEGER signature (options because an implementation of integers
may support arbitrary precision).

Owner: John
Status: fixed in 109.20 [by new basis]
----------------------------------------------------------------------
Number: 983
Title: memory fault in sml-sc v107 on a sparc
Keywords: 
Submitter: dimock@das.harvard.edu
Date: 3/5/95
Version: 107
System: ?
Severity: major 
Problem: memory fault in sml-sc v107 on a sparc
Code: 
  source code:
  sources.sc

  regexp.sml
  fsa.sml
  smlnj-lib.sc

  where smlnj-lib.sc contains:

  /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/107-sources.sc

  file regexp.sml:

  datatype regexp
    = EMPTY
  | CHAR of char
  | CONC of regexp * regexp
  | ALT of regexp * regexp
  | STAR of regexp;

  datatype extended_regexp 
    = BASIC of regexp
  | STRING of string
  | PLUS of extended_regexp;


  (* val simplify_regexp = fn : extended_regexp -> regexp  *)
  fun simplify_regexp (BASIC r) = r
    | simplify_regexp (STRING s) = let
				   fun make_chars (x, EMPTY) = CHAR x
				     | make_chars (x, y) = CONC (CHAR x, y)
				 in
				   fold make_chars (explode s) EMPTY
				 end
    | simplify_regexp (PLUS p) = let
				 val r = simplify_regexp p
			       in
				 CONC (r, ALT (EMPTY, r))
			       end


  file fsa.sml

  (* use "fsa.sml"; *)
  (* sc.make(); *)

  exception Fsa of string			(* Exception for errors *)
  datatype ('a) trans = EPS | CHAR of 'a	(* transition on character or e *)

  type state = string			(* type of states, parameterize *)
  type alphabet = char			(* type of alphabets, parameterize *)
  type delta = state * alphabet trans * StateSet.set
					  (* type of transition relations *)
  local open LibBase			(* make some sets of the right sort *)
  in
    structure StateKey : ORD_KEY =
      struct
	type ord_key = state

	fun cmpKey (s1 : state, s2) = if s1 >= s2 then if s1 > s2 then Greater
						       else Equal
				      else Less
      end

    structure SigmaKey : ORD_KEY =
      struct
	type ord_key = alphabet

	fun cmpKey (s1 : alphabet, s2) = if s1 >= s2 then if s1 > s2 then Greater
						       else Equal
				      else Less
      end

    structure DeltaKey : ORD_KEY =
      struct
	type ord_key = delta

	fun cmpKey ((s1s,s1a,_), (s2s,s2a,_)) =
	  let val cmp1 = StateKey.cmpKey(s1s, s2s) in
	    case cmp1 of
	      Equal => (case (s1a, s2a) of
			  ((CHAR x), (CHAR y)) => SigmaKey.cmp_key(x,y)
			| (EPS, EPS)           => Equal
			| (EPS, _)             => Less
			| (_, EPS)             => Greater )
	    | _     => cmp1
	  end
      end
  end

  structure StateSet = SplaySet(StateKey);
  structure SigmaSet = SplaySet(SigmaKey);
  structure DeltaSet = SplaySet(DeltaKey);

  type states = StateSet.set
  type alphabet = SigmaSet.set
  type deltafun = DeltaSet.set
  type start = state
  type final = StateSet.set
  type fsa = states * alphabet * deltafun * start * final

  (* Make an empty FSA *)
  fun fsa_make() = (StateSet.empty, SigmaSet.empty, DeltaSet.empty, "",
		    StateSet.empty) 


  (* Manipulate start state *)
  fun fsa_set_start((K,S,d,s,F), s1) = (K,S,d,s1,F)
  fun fsa_get_start((K,S,d,s,F)) = if s = "" then raise Fsa "No Start State"
				   else s

  (* Manipulate final states *)
  fun fsa_clear_finals((K,S,d,s,F)) = (K,S,d,s,StateSet.empty)
  fun fsa_add_finals((K,S,d,s,F), fs) = (K,S,d,s, StateSet.addlist (F, fs))
  fun fsa_get_finals(K,S,d,s,F) = listItems F
Transcript: 
  - sc.make();
   Defining the group...
  [scanning sources.sc]
  [scanning smlnj-lib.sc]
  [scanning /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/107-sources.sc]
   Compiling...
  GC #0.0.0.1.9.692:   (30 ms.)
  GC #0.0.0.1.10.782:   (0 ms.)
  GC #0.0.1.2.11.906:   (80 ms.)
  GC #0.0.1.2.12.1057:   (20 ms.)
  GC #0.0.1.2.13.1202:   (20 ms.)
  GC #0.0.1.2.14.1218:   (10 ms.)
  [Parsing fsa.sml]
  GC #0.0.1.2.15.1224:   (10 ms.)
  [compiling regexp.sml]
  [writing .sparc/regexp.sml.bin]
  Repairing blast GC (maxGen = 5 of 5)
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/finalize-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/100-finalizer.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/100-time-limit.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/lib-base-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-lib-base.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array-qsort.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array-sort-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array2-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/array2.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/ord-key-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/dict-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/binary-dict.sml.bin]
  GC #0.0.1.2.16.1233:   (10 ms.)
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/ord-set-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/binary-set.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-ctype-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-ctype.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/bit-array-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-bit-array.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/bsearch.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-map-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-map.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/dynamic-array-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-dynamic-array.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/string-cvt-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-string-cvt.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/makestring-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-makestring.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-string-util-sig.sml.bin]
  GC #0.0.1.2.17.1249:   (60 ms.)
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-set-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-char-set.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-string-util.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/bigint-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-bigint.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-format-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-format.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intmap-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intmap.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intset-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/intset.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-format-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-list-format.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/listsort-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-mergesort.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-util-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-util.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-xprod-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/list-xprod.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/name-sig.sml.bin]
  GC #0.0.1.3.18.1293:   (130 ms.)
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/hash-key-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/hash-table-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/hash-table.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-hash-string.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/name.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-array-sort-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-array-qsort.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-hash-table-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/poly-hash-table.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/queue-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/fifo-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/fifo.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/queue.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/rand-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/rand.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/random-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/iterate-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/iterate.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/random.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/splaytree-sig.sml.bin]
  GC #0.0.2.4.19.1356:   (230 ms.)
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/splaytree.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/splay-dict.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/pathname-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/106-pathname.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/unix-path-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/unix-env-sig.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/unix-env.sml.bin]
  [reading /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/.sparc/107-unix-path.sml.bin]
   Introducing the new bindings...
  val it = () : unit
  - %1    7238 Memory fault         ${RUN} ${HEAP} ${ARGS} 

  Process sml-sc exited abnormally with code 139
Fix:
Workaround 1:

-smlnj-lib.sc     in sources.sc doesn't work:

- sc.make();
GC #0.0.0.0.1.1:   (0 ms.)
 Defining the group...
[scanning sources.sc]
[scanning smlnj-lib.sc]
[scanning /home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/107-sources.sc]
 Compiling...
GC #0.0.0.0.2.34:   (20 ms.)
GC #0.0.0.0.3.77:   (10 ms.)
GC #0.0.0.0.4.152:   (0 ms.)
GC #0.0.0.0.5.251:   (10 ms.)
GC #0.0.0.1.6.376:   (30 ms.)
GC #0.0.0.1.7.532:   (20 ms.)
GC #0.0.0.1.8.613:   (20 ms.)
% structure LibBase undefined in source /tmp_mnt/home/usr12/cheatham/dimock/courses/ta153/chapter2/fsa.sml
% functor SplaySet undefined in source /tmp_mnt/home/usr12/cheatham/dimock/courses/ta153/chapter2/fsa.sml
% signature ORD_KEY undefined in source /tmp_mnt/home/usr12/cheatham/dimock/courses/ta153/chapter2/fsa.sml
[reading .sparc/regexp.sml.bin]
 Introducing the new bindings...
val it = () : unit

Workaround 2 (works) include exactly the modules needed in sources.sc:
regexp.sml
fsa.sml
(* -smlnj-lib.sc *)
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/lib-base-sig.sml
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/106-lib-base.sml
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/ord-key-sig.sml
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/ord-set-sig.sml
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/splay-set.sml
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/splaytree-sig.sml
/home/usr12/cheatham/dimock/languages/smlnj107/src/smlnj-lib/splaytree.sml

Owner: John
Status: obsolete
----------------------------------------------------------------------
Number: 984
Title: Word32.notb returns incorrect result
Keywords: 
Submitter: Edo Biagioni (esb@KITSUNE.FOX.CS.CMU.EDU)
Date: 3/6/95
Version: 107
System: MIPS (DECstation?)
Severity: major
Problem: 
  Word32.notb returns incorrect result.
Transcript: 
  - Word32.notb (Word32.intToWord 0);
  val it = 0 : Word32.word
  - 
 (* another example from Thomas Yan: *)
  - map (Word32.notb o Word32.intToWord) [0,1,2,3,4];
  val it = [0,~1,~2,~3,~4] : Word32.word list
Comments:
  Should be 0xffffffff -- Word32.notb is off-by-one throughout its range.
  Unless it's been fixed, this is probably still a bug under 107.7 (which
  I haven't installed yet)
Status: fixed in 107.8+ 
----------------------------------------------------------------------
Number: 985
Title: Word32 operations yield incorrect results (1)
Keywords: 
Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU
Date: 3/7/95
Version: 107
System: alpha
Severity: major
Problem: 
  Word32 operations yield incorrect results
Transcript: 
  - val half = Word32.intToWord 0x8000;
  - val high = Word32.shift (half, 16);
  val high = 2147483648 : Word32.word
  - fun f (a, b) = Word32.div (a, b);
  val f = fn : Word32.word * Word32.word -> Word32.word
  - f (high, high);
  val it = 4294967295 : Word32.word

  - val divisor = Word32.orb (Word32.shift (Word32.intToWord 0xffff, 16),
			      Word32.intToWord 0xffff);
  - Word32.div (Word32.intToWord 1, divisor);
  val it = 4294967295 : Word32.word

Comments: f (high, high) should return 1.
  This happens for several different values, but in all either the
  dividend or the divisor seem to have the top bit set.
Status: fixed in 108.9 (maybe earlier -- lal)
----------------------------------------------------------------------
Number: 986
Title: Word32 operations yield incorrect results (2)
Keywords: 
Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU
Date: 3/7/95
Version: 107
System: mips (DECstation 5000?)
Severity: major
Problem: 
  Word32 operations yield incorrect results
Transcript: 
  - Word32.ashift (Word32.intToWord 1, ~32);
  val it = 1 : Word32.word
  - Word32.shift (Word32.intToWord 1, ~32);
  val it = 1 : Word32.word
Status: fixed in 107.8+
----------------------------------------------------------------------
Number: 987
Title: Word32 operations yield incorrect results (3)
Keywords: 
Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU
Date: 3/7/95
Version: 107
System: mips (DECstation 5000?) and alpha
Severity: major
Problem: 
  Word32 operations yield incorrect results
Transcript: 
  - val x = Word32.intToWord 1;
  val x = 1 : Word32.word
  - val y = Word32.shift (x, 31);
  val y = 0 : Word32.word
Status: fixed in 107.8+
----------------------------------------------------------------------
Number: 988
Title: serious bogosity on Alpha
Keywords: 
Submitter: Edoardo.Biagioni@FORTRAN.FOX.CS.CMU.EDU
Date: 3/7/95
Version: 107
System: alpha
Severity: major
Problem: 
  serious bogosity on Alpha
Code:
  val l = (Word32.shift (Word32.intToWord 0xffff, 16), Word32.intToWord 0)
  val r = (Word32.orb (Word32.shift (Word32.intToWord 0x7fff, 16),
		       Word32.intToWord 0xffff),
	   Word32.shift (Word32.intToWord 0xffff8, 12))

  (* l = 0xffff,0000,0000,0000    r = 0x7fff,ffff,ffff,8000 *)

  val zero = Word32.intToWord 0

  (* this is very fragile.
     Commenting out '"abcdef" ^ "ghi"' causes a loop. *)
  fun find_shift1 (n1 as (high1, low1), n2 as (high2, low2)) =
       ("abcdef" ^ "ghi";
	if Word32.< (high1, high2) then 0
	else Integer.+ (1, find_shift1 (n1, (Word32.shift (high2, 1), zero))))

  (* this is very fragile.
     Commenting out 'val lowhigh = Word32.shift (low, ~31)' causes a loop. *)
  fun lshift (high, low) =
       let val lowhigh = Word32.shift (low, ~31)
	   val highhigh = Word32.shift (high, 1)
       in (highhigh, zero)
       end

  fun find_shift2 (n1 as (high1, low1), n2 as (high2, low2)) =
       (if Word32.< (high1, high2) then 0
	else Integer.+ (1, find_shift2 (n1, lshift n2)))

  (* although functionally equivalent, find_shift1 and find_shift2
     compute different results.  The result computed by find_shift1
     is correct. *)
  val a = find_shift1 (l, r)
  val b = find_shift2 (l, r)
Comment:
  This program appears to demonstrate a rather obscure bug.
  The bug only appears on the alpha.
  The first symptom I noticed was:
      adding a print statement to a function changes the value returned.
  The print statement then became a string catenation, and the same
  result was obtained.
  In trying to reduce the problem I came to points where commenting
  out a piece of code would cause a loop (infinite?), and there I
  would stop.  As a result, this is the smallest piece of code
  I could isolate that would reproduce the bug.

[This bug exposes a subtle point about 32 bit implementations on 64
bit architectures. When a word32 object gets read from memory, the
high 32 bits may not have the proper sign extension. Two solutions
exist: when reading an object from memory, type information can be
used to provide the necessary sign extension, or each word32 operation
that is sign extension sensitive should perform the necessary sign
extension first on the operands.]

Status: fixed in 108.10 
----------------------------------------------------------------------
Number: 989
Title: Compiler bug: Instantiate:explore_tclass.5
Keywords: modules, functors, signatures, instantiate
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			03/08/95
System(s) and Version:	Compiler
SML/NJ Version: 	107.7
Machine: 		all
Severity: 		critical
Problem: 		Compiler bug: Instantiate:explore_tclass.5
Code:		
  (* bug.sml *)
  functor ParseFun(type Arg
		   type Result
		   val parser: string -> Arg -> Result
		   sharing type Arg = unit	(*1*)
		  ) =
    struct
      fun parse file = parser file ()		(*2*)
    end;

Transcript: 		

  Standard ML of New Jersey, Version 107.7, March 2, 1995 [new runtime]
  - use "bug.sml";
  [opening bug.sml]
  Error: Compiler bug: Instantiate:explore_tclass.5

A simpler version, from Ken Cline (3/10/95)

  - signature VOID_XDR =
     sig
       type T
       sharing type T = unit 
     end;
  Error: Compiler bug: Instantiate:explore_tclass.5
  -

Comments:		

If I change the "unit" on line (*1*) to be "int", and the
"()" on line (*2*) to be "99", the problem goes away.

This bug was not present in SML/NJ 107.

This code is abstracted from some code where I construct a nice
interface to an ml-yacc generated `ARG_PARSER'. I imagine many
parsers could be similarly affected.

Is this a re-appearance of bug #737?

Comment: [DBM] This is different from bug 737.

Fix: In modules/instantiate.sml I added a case in the definition of
finalize in explore_tclass to treat the case of external sharing with
type unit.  It looks like the top-level binding of "unit" changed between
107.1 and 107.3 so that the DEFtyc case no longer applies -- the binding
of "unit" is a RECORDtyc in 107.3.

Tests: bug989.1.sml, bug989.2.sml
Status: fixed in 107.7+
----------------------------------------------------------------------
Number: 990
Title: Error: Compiler bug: access_type.
Keywords: modules, signatures, sharing
Submitter: Robert Findler <Robert_Findler@INBOX.FOX.CS.CMU.EDU>
Date: 3/13/95
Version: 107, 107.7
Severity: major
Problem: "Error: Compiler bug: access_type" while elaborating a signature.
Code: 
  signature U =
  sig
    structure A: sig type 'a t type s end
    structure B: sig type u = int end
    type v=B.u A.t
    sharing type A.s=v
  end
Status: fixed in 109.20
----------------------------------------------------------------------
Number: 991
Title: Error: Compiler bug: Instantiate:explore_class.3
Keywords: modules, signatures, instantiation
Submitter: Robert Findler <Robert_Findler@INBOX.FOX.CS.CMU.EDU>
Date: 3/13/95
Version: 107, 107.7
Severity: major
Problem: "Error: Compiler bug: Instantiate:explore_class.3" while
  elaborating signatures.
Code: 
  signature S=
  sig
    type 'a t
    type s
  end

  signature T=
  sig
    type u = int
  end

  signature U =
  sig
    structure A:S
    structure B:T
    type v=B.u A.t
    sharing type A.s=v
  end
Status: fixed in 109.20
----------------------------------------------------------------------
Number: 992
Title: Support of local type abbreviations in signatures
Keywords: modules, signatures, types abbreviations
Submitter:      John Reppy, Zhong Shao 
Date:           March 14, 1995
Version:        107, 107.7 (any version)
System:         all platforms
Severity:       medium
Problem:        Support of local type abbreviations in signatures
Code:           
     signature SIG = sig local type t = int * real in val f : t -> t end end
     structure S : SIG  = struct fun f (x,y) = (x+1,y+1) end

Transcript:     

     - Compiler.Stats.sayEnd := true;
     End   Execute                                     0.0 sec
     val it = () : unit
     - signature SIG = sig local type t = int * real in val f : t -> t end end
       structure S : SIG  = struct fun f (x,y) = (x+1,y+1) end
     = = ;
     End   Compiler 010 Parse                          0.0 sec
     std_in:9.26-9.73 Warning: LOCAL specs are only partially implemented
     End   Compiler 030 Elaborate                      0.0 sec
     Error: Compiler bug: type conflicts happened in transtypes-unwrapOp2
     End   Compiler 040 Translate                      0.0 sec

Comments:       

     The compiler bug is caused when the wrappers are built for S.f (for
     representation analysis). "f" in SIG is considered having type t->t
     instead of int*real->int*real. But the bug is mainly caused by lack of
     support of "local type abbreviations" in signatures. See the bug
     report below and my comments:

     The first bug is the warning message --- we need to support local type
     abbreviations in signatures. The compilation passes beyond the 
     Elaboration phase while it should not, because S does not match the
     signature SIG (f 's type is int*int -> int*int while its spec is
     int*real -> int*real ). 

     First we need resolve the "warning" message, then I'll fix the 
     representation analysis wrapper function code accordingly.

Owner: dbm
Status: not a bug (DBM: a feature request)
----------------------------------------------------------------------
Number: 993
Title: the control character ^\ in a string dumps core
Keywords: 
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           3/14/95
Version:        1.07
System:         sparc, solaris 5.3, under emacs 19.22.1
Severity:       minor
Problem:        the control character ^\ in a string dumps core
Code:           ""
Transcript:  	- ""; (* no problem *)
		std_in:131.2 Error: illegal non-printing character in string
		- ""; (* oops... *)
		
		Quit (no coredump)
		
		Process Inferior eXene exited abnormally with code 208

Comments:	somehow it doesn't seem to be a problem at the
		console.  
[Reppy: It appears that emacs is mapping the CNTRL-\ character into the
SIGQUIT signal as it is typed, and this signal aborts the process.]

Status: not a bug
----------------------------------------------------------------------
Number: 994
Title: realround (in math.sml) rounds up, not to nearest
Keywords: 
Submitter:              appel
Date:                   Thu Mar 16 10:12:46 EST 1995
System(s) and Version:  compiler
SML/NJ Version:         107.7
Machine:                Alpha
Severity:               minor
Problem:                realround (in math.sml) rounds up, not to nearest
Code:                   

   val maxint = 4503599627370496.0 (* This is the IEEE double-precision *)
   fun realround x = if x>=0.0 then x+maxint-maxint else x-maxint+maxint

Transcript:

val maxint = 4.50359962737051E15 : real
val realround = fn : real -> real
- (realround 0.1, realround 0.5, realround 0.7, realround 1.0, realround 1.1);
val it = (1.0,1.0,1.0,1.0,2.0) : real * real * real * real * real
- maxint - 4.503E15;
val it = 599627370496.001 : real
- 

Correct transcript (taken from SML/NJ 107.7 running on SGI):

- (realround 0.1, realround 0.5, realround 0.7, realround 1.0, realround 1.1);
val it = (0.0,0.0,1.0,1.0,1.0) : real * real * real * real * real
-  maxint - 4.503E15;
val it = 599627370496.0 : real
- 

Comments:
This will make sin/cos very slightly inaccurate; most users wouldn't notice.
However, it indicates an error in the rounding of floating-point operations
on the Alpha.  Perhaps we are using the wrong rounding modes?

I believe the problem is that "Dynamic" rounding is used.
We should probably use "normal" rounding instead.
For example, in Alpha32MC.sml, we have

	| I.ADDT arg		=> FOperate 22 0xe0 arg
	| I.SUBT arg		=> FOperate 22 0xe1 arg

But better would be:

	| I.ADDT arg		=> FOperate 22 0xa0 arg
	| I.SUBT arg		=> FOperate 22 0xa1 arg

The same applies for other FOperate instructions.

Owner: Lal
Status: fixed in 109.25.x [Lal]
----------------------------------------------------------------------
Number: 995
Title: error in cosine
Keywords: 
Submitter:      Lal George
Date:		3/20/95
Version:        0.93 and 107.7
System:         Pentium, Linux
Severity:       Major
Problem:        error in cosine
Code:
	val theta =  arctan (19.75 / 24.0);
	cos theta

Transcript:     
	- val theta = arctan (19.75 / 24.0);
	  val theta = 0.688559158136141 : real

	- cos theta;
	  val it = ~0.00133576476614669 : real

Comments:
[Lal George:] Cosine theta is completely off. 

[Lorenz Huelsbergen:]
This is the same bug that caused nucleic to fail under Linux 107.x;
it is fixed in the runtime for 108.

Linux 107.x runtime was not calling fpenable to 
properly initialize the FPU to IEEE double precision.

Status: fixed in 108
----------------------------------------------------------------------
Number: 996
Title: sharing constraints and datatypes
Keywords: modules, functors, signatures, sharing, datatypes
Submitter:              Edo Biagioni, esb@cs.cmu.edu
Date:                   Wed Mar 22 1995
System(s) and Version:  Compiler v. 107
SML/NJ Version:         107.0
Machine:                Alpha and Mips (presumed typechecker bug)
Severity:               minor
Problem:                sharing constraints are not enough to make a
			type into a datatype if the type is declared
			textually before a datatype in a signature

Code (test.sml):                   
signature DERIVED =
 sig
(* this doesn't work. *)
  type new_name
  datatype dtype = Constructor of int
(* this does
  datatype dtype = Constructor of int
  type new_name
*)
  sharing type dtype = new_name
 end 

functor F1 (structure Derived: DERIVED): DERIVED =
 struct
  structure Subtyped = Derived
  open Subtyped
 end 

functor F2 (structure Derived: DERIVED): DERIVED =
 struct
  structure New = F1 (structure Derived = Derived)
  open New
 end 

Transcript:
- use "test.sml";
[opening test.sml]
test.sml:19.1-23.4 Error: type dtype must be a datatype

Status: fixed in 109.20
----------------------------------------------------------------------
Number: 997
Title: lexgen doesn't check for unmatched quotes
Keywords: 
Submitter: John Reppy
Date: 2/13/94
Version: ?
Severity: minor
Problem: 
  lexgen should check for unmatched double quotes.  Right now, it just
  keeps eating characters (including newlines) until it sees a ".  This
  gives an error message that is hard to understand.
Owner: Andrew
Status: fixed in 110.1
----------------------------------------------------------------------
Number: 998
Title: Compiler bug: Escapemap on 10976
Keywords: modules, functors
Submitter: 		Alan Smaill, smaill@dcs.ed.ac.uk
Date: 			27/3/95
System(s) and Version:	Compiler 
SML/NJ Version: 	0.93
Machine: 		sparc and solaris, also sparc and sunOS
Severity: 		awkward
Problem: 		fails to compile, raising compiler error
Code:			
(* compiler bug  *)

signature MESSAGE_LANG =
    sig                              
               (* need more than two contructors in next *)
	datatype agent_id = UK | Kenya | Japan | World
	datatype commodity = Steel | Cars
        eqtype state_attribute
        datatype amount = Amount of int | Query
	datatype statement = State_info of agent_id * state_attribute * amount
	type message 
    end;

signature AGENT =
    sig
        structure Message_Lang : MESSAGE_LANG
        open Message_Lang
	type agent 
	val update_beliefs : agent -> statement list -> agent
    end;
    
signature AGENT_DYNAMICS =
    sig
	structure Agent : AGENT
        val process_message :
	      Agent.Message_Lang.message * Agent.agent -> Agent.agent 
	val core_functions : Agent.agent -> Agent.agent  
    end;


functor Neutral_Agent_Dynamics ( structure Agent : AGENT ) =
    struct
	structure Agent = Agent
        fun add_belief bel agt = agt
        fun process_message (_,a) = a
    end;


functor World_Agent_Dynamics (structure Agent : AGENT
			     ) : AGENT_DYNAMICS =
    struct
	structure Neutral_Dynamics =
	    Neutral_Agent_Dynamics( structure Agent = Agent )
	structure Agent = Agent
        open Agent
        open Message_Lang

          (* "Expand" is raised without next line  *)
	fun revise_beliefs agt bels = agt 

        exception NoStock of agent_id * commodity
        exception NoMoney of agent_id

        fun process_message (msg ,agt) = agt 

        fun show s = output( std_out, s )
	    (* this needs def by cases *)
            (*    and no wildcard      *)
        fun showtr World = "World" 
	  | showtr UK    = "UK"
	  | showtr Japan = "Japan"
	  | showtr Kenya = "Kenya" (* wildcard here removes the bug *)
        fun show_neg_info ( NoStock ( agent_id, cdy ) ) =
	    show ( "Trader "^(showtr agent_id))
    	  | show_neg_info ( NoMoney agent_id ) =
	    show ( "Trader "^(showtr agent_id) )  


        fun update_stock_level trader agt =
            let val newC = Amount 0
                           handle SubAmt =>
			       ( show_neg_info(NoStock ( trader, Cars));
				       Amount 0 )
                      (* two decls needed here  *)
		val newS = Amount 0
		           handle SubAmt =>
			       ( show_neg_info(NoStock (trader, Steel));
				       Amount 0 )
	    in  agt end

                      (* this also needed *)
                      (*  -- identity function not enough *)
        fun core_functions a = update_stock_level Kenya a

    end;
    
===========================================================================

Transcript: 		<an output transcript exhibiting the buggy behavior>

[opening bug.sml]
signature MESSAGE_LANG =

[ ... sigs deleted ...]

signature AGENT_DYNAMICS =
  sig
    structure Agent : ...
    val process_message : Agent.Message_Lang.message * Agent.agent
                          -> Agent.agent
    val core_functions : Agent.agent -> Agent.agent
  end
functor Neutral_Agent_Dynamics : <sig>
bug.sml:66.9-69.41 Warning: match nonexhaustive
          NoStock (agent_id,cdy) => ...
          NoMoney agent_id => ...
  
Error: Compiler bug: Escapemap on 10976

Owner: 
Status: open
----------------------------------------------------------------------
Number: 999
Title: absolute path to CM.stabilize'd library doesn't work
Keywords: 
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			03/27/95
System(s) and Version:	CM 107.8
SML/NJ Version: 	107.8
Machine: 		probably all
Severity: 		major
Problem: 		absolute path to CM.stabilize'd library doesn't work
Code:

We have a library, in $LIBPATH, consisting of

	(* lib.sml *)
	structure Lib =
	  struct
	    val version = "Lib Version 1.0"
	  end
and
	(* sources.cm *)
	Library
	structure Lib
	is
	lib.sml

The client application, in a completely unrelated directory, consists of

	(* main.sml *)
	structure Main =
	  struct
	    fun main() = (print Lib.version; print "\n")
	  end
and
	(* sources.cm *)
	Group is
-->	/u/mikpe/tmp/lib/sources.cm	(* actually $LIBPATH/sources.cm *)
!	main.sml
!
This has to be an absolute path.


Transcript:

sen14_1_pwd
/u/mikpe/tmp
sen14_2_ls -RA
app/		lib/

app:
main.sml	sources.cm

lib:
lib.sml		sources.cm

### First make the library using CM.stabilize()

sen14_3_cd lib
sen14_4_echo 'CM.stabilize()' | sml-cm
loading /files/pelab1/ml/sml-107.8/bin/.heap/sml-cm.sparc ......................... done
Standard ML of New Jersey, Version 107.8, March 24, 1995 [CM&CMB 1]
val it = () : unit
- = [starting dependency analysis]
[scanning sources.cm]
[parsing lib.sml]
[dependency analysis completed]
[compiling lib.sml -> .sparc/lib.sml.bin]
Repairing blast GC (maxGen = 5 of 5)
[wrote .sparc/lib.sml.bin]
val it = () : unit

### Ok. Let's make the application now.

sen14_5_cd ../app
sen14_6_echo 'CM.make()' | sml-cm
loading /files/pelab1/ml/sml-107.8/bin/.heap/sml-cm.sparc ......................... done
Standard ML of New Jersey, Version 107.8, March 24, 1995 [CM&CMB 1]
val it = () : unit
- = [starting dependency analysis]
[scanning sources.cm]
[scanning /u/mikpe/tmp/lib/sources.cm]
[parsing main.sml]
[dependency analysis completed]

!* CM error: cannot find SML source file u/mikpe/tmp/lib/lib.sml (u/mikpe/tmp/lib/lib.sml (stable))

uncaught exception SourceFileDoesNotExist

### Notice the missing "/" at the start of the path.
### Now if I make a symlink `ln -s /u u', then CM.make() finds the library.

sen14_7_ln -s /u u
sen14_8_echo 'CM.make()' | sml-cm
loading /files/pelab1/ml/sml-107.8/bin/.heap/sml-cm.sparc ......................... done
Standard ML of New Jersey, Version 107.8, March 24, 1995 [CM&CMB 1]
val it = () : unit
- = [starting dependency analysis]
[scanning sources.cm]
[scanning /u/mikpe/tmp/lib/sources.cm]
[dependency analysis completed]
[recovering u/mikpe/tmp/lib/.sparc/lib.sml.bin... done]
[compiling main.sml -> .sparc/main.sml.bin]
Repairing blast GC (maxGen = 5 of 5)
[wrote .sparc/main.sml.bin]
val it = () : unit
sen14_9_exit
sen14_10_exit

script done on Mon Mar 27 21:53:22 1995

Comments:

This worked in 107.7. It also works in 107.8 if the library is
built using CM.recompile() or CM.make() instead of CM.stabilize().

Owner: Matthias
Status: fixed in 109.21 [according to jhr]
----------------------------------------------------------------------
Number: 1000
Title: top-level printing of multiple occurrences of the same name
Keywords: top level, modules
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           3/28/95
Version:        1.07
System:         sparc (all?)
Severity:       major
Problem:        top-level printing of multiple occurrences of the same name
Code:           (see examples below)
Transcript:     
    (* this doesn't crash, but is in some sense wrong *)
	- val x = 2 val x = 3;
	val x = 3 : int
	val x = 3 : int

    (* this is interesting... *)
	- val x = 3 val x = [7];
	
	uncaught exception Boxity

    (* this is perhaps similar to appel's example in 863 *)
	-  structure U = struct datatype u = U end
	=  structure T = struct datatype t = T of U.u end
	=  val l = U.U
	=  val l = T.T U.U;
	structure U :
	  sig
	    datatype u
	      con U : u
	  end
	structure T :
	  sig
	    datatype t
	      con T : U.u -> t
	  end
	Error: Compiler bug: PPVal.switch: none of the datacons matched

Comments:	see also 863, and possibly 955, 912, 758, 695
		for similar (past) problems.  note that 863 blames
		the "open" statement in the example.
Fix: a temporary work around is to sequentialize the
     declarations, e.g. val x=3; val x=[7]
 [Zhong, 3/24/97]
  Fixing the coredump bug caused by duplicate top-level declarations.
  For example, in almost any versions of SML/NJ, typing 
          val x = "" val x = 3
  would lead to core dump. This is avoided by changing the "exportLexp"
  field returned by the pickling function (pickle/picklemod.sml) into
  a list of lambdavars, and then during the pretty-printing (print/ppdec.sml),
  each variable declaration is checked to see if it is in the "exportLvars"
  list, if true, it will be printed as usual, otherwise, the pretty-printer
  will print the result as <hiddle-value>.

Owner: Zhong
Test: bug1000.sml, bug1000.1.sml, bug1000.2.sml
Status: fixed in 109.26 [Zhong]
----------------------------------------------------------------------

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0