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.0601-0800
ViewVC logotype

View of /bugs/branches/smlnj/bugs.0601-0800

Parent Directory Parent Directory | Revision Log Revision Log


Revision 945 - (download) (annotate)
Thu Oct 4 13:38:32 2001 UTC (17 years, 9 months ago)
File size: 283522 byte(s)
This commit was manufactured by cvs2svn to create branch 'smlnj'.
Number: 601
Title: bad implementation of Assembly.A.logb
Keywords: arithmetic, Assembly
Submitter:      John Reppy (jhr@research.att.com)
Date:		7/29/92
Version:        0.75-0.85 (probably earlier versions too)
System:         SPARC
Severity:       minor
Problem:        The implementation of logb in runtime/SPARC.prim.s
		doesn't work for 0.0
Code:
  (System.Unsafe.Assembly.A.logb 0.0)
Transcript:
  Standard ML of New Jersey, Version 0.86, July 22, 1992
  val it = () : unit
  - (System.Unsafe.Assembly.A.logb 0.0);
  val it = 
  uncaught exception Boxity
Fix:  "beq 1f" should be "beq 2f"
Status: fixed in 0.87
----------------------------------------------------------------------
Number: 602
Title: uncaught exception UnboundTable using System.Env.describe
Keywords: environment, describe
Submitter: Dave MacQueen
Date: 9/29/92
Version: 0.85
Severity: major
Problem: 
  Invoking System.Env.describe on topLevelEnv with structure symbol
  "System" yields uncaught exception UnboundTable
Transcript: 
  Standard ML of New Jersey, Version 0.85, July 17, 1992
  val it = () : unit
  - System.Env.describe (System.Env.staticPart (!System.Env.topLevelEnvRef))
     (System.Symbol.strSymbol "System");
  uncaught exception UnboundTable
  - 
Comment: System is in Pervasives, not topLevelEnv, but describe should
	 catch the exception and give a report.
Status: fixed in 0.89 (Cregut)
----------------------------------------------------------------------
Number: 603
Title: System.Symbol.makestring gives erroneous answer
Keywords: makestring
Submitter:      cregut
Date:		7/29/92
Version:        .83 -> .86
System:         all
Severity:       minor
Problem:        System.Symbol.makestring gives erroneous answer
Code: 
Transcript:     
- open System.Symbol;
open Symbol
- makestring(sigSymbol "s");
val it = "TYC$s" : string
Comments:	bad order of namespaces
Fix:		change makestring in env.sml 
Test File:

let open System.Symbol 
in 
if (makestring(valSymbol "s")^makestring(tycSymbol "s")^
    makestring(sigSymbol "s")^makestring(strSymbol "s")^
    makestring(fctSymbol "s")^makestring(fixSymbol "s")) 
   = "VAL$sTYC$sSIG$sSTR$sFCT$sFIX$s"
then "System.Symbol.makestring seems O.K." 
else "Verify the behaviour of System.Symbol.makestring"
handle _ => "System.Symbol.makestring has a major bug"
end
Status: fixed in 0.87
----------------------------------------------------------------------
Number: 604
Title: blast_read/blast_write broken
Keywords: I/O, blast_read, blast_write
Submitter:      Emden R. Gansner erg@ulysses.att.com
Date:           7/30/92
Version:        0.86
System:         Sparc 2, SunOS 4.1
Severity:       major
Problem:        blast_read/blast_write is broken
Code:           
  (* The following function writes a value, then reads it back in
   * and compares them. In 0.86, the values are not equal.
   * If one attempts to print v', the system hangs, causing a
   * core dump on interrupt.
   * You can replace 'int list' with your favorite eqtype
   *)
fun btest v = let
  val ofd = open_out "dump"
  val bwrite : outstream * int list -> int = System.Unsafe.blast_write
  val bread : instream * int -> int list = System.Unsafe.blast_read
  val sz = bwrite(ofd,v)
  val _ = close_out ofd
  val ifd = open_in "dump"
  val v' = bread(ifd,sz)
  in
    close_in ifd;
    if v = v' then print "v = v'\n" else print "print v <> v'\n"
  end
Transcript:
  Standard ML of New Jersey, Version 0.86, July 22, 1992
  val it = () : unit
  - use "btest.sml";
  val btest = fn : int list -> unit
  [closing btest.sml]
  val it = () : unit
  - btest [];
  
  [Major collection...abandoned]
  print v <> v'
  val it = () : unit
  - btest [1,2];

  [Major collection...abandoned]
  print v <> v'
  val it = () : unit
  - 
Comments: Does this have anything to do with bug 548 being fixed?
Fix: [Appel]
    at the beginning of ml_blast_out in cfuns.c, insert the following line
    after "blast_fd = REC_SEL..."

       msp->ml_arg = arg;

    Then do a makeml -noclean and things ought to work better.
Status: fixed in 0.87
----------------------------------------------------------------------
Number: 605
Title: whose bug?
Keywords: 
Submitter:      Charles Krasic
		cckrasic@plg.waterloo.edu
Date:		7/31/92
Version:        0.75
System:         Sparc, SunOS 4.1.2
Severity:       critical
Problem:        file compiles OK with batch compiler, but runtime/run
 	        fails with "uncaught exception (Loader): Syntax"
Comments:	I am working on the source code of NJSML itself.  I have made some
		fairly significant changes so it would be a non-trivial amount of
		work for me to give you all the code necessary to run NJSML and 
		reproduce my problem.   I have isolated my problem to 1 line of code
		in the source code which is will briefly summarize here.  The 
		file that contains the code in question is at the end of this message.
		This code is part of my modified type checker.  Roughly, it is
		called prior to the 0.75 typechecker (there are many changes...)

		This seems to be a very nasty bug to me. It should be noted that, while 
		I am changing the compiler, I am compiling my changed version with the 
		stock 0.75 version of the batch compiler.  My changes are confined
		entirely to the front end of the compiler (nothing after typechecking).

		Some of the things I tried:	

		The offending section of code is:

1.		(case var of
2.		    (VALvar{constraints,...}) => 
3.			(ConstraintsStack.push constraints;
4.			 constructList := (constraints :: (!constructList));
5.			 expType(env,exp,err,loc); 
6.			 ConstraintsStack.pop())
7.		  | _ => (ErrorMsg.impossible "MakeImplicitsPass.Pass2.valrecType"))

		If lines 3,4 and 6 are removed (and 5 has the semicolon removed), it
		will build OK.  Alternatively, if line 5 is removed, it also will
		build OK.  Of course, either of those things doesn't do what I want
		it to do.  I have tried many variations on the above code but could
		not get any to work.

Status: not a bug (bug was in his own code)
----------------------------------------------------------------------
Number: 606
Title: Allocating space for saved FP registers is awkward
Keywords: floating point, registers
Submitter:      Mark Leone (mleone@cs.cmu.edu)
Date:		7/31/92
Version:        0.82
System:         i386
Severity:       Necessary change for i386 runtime
Problem:        Allocating space for saved FP registers is awkward
Code:           none
Transcript:	none
Comments:
   In runtime/signal.c, in make_ml_sigh_arg(), floating point registers
   are saved as follows:

   #if (NSAVED_FPREGS > 0)
       savefpregs (msp);
       fpregs = PTR_CtoML(msp->ml_allocptr + sizeof(long));
       msp->ml_allocptr += (NSAVED_FPREGS*2 + 1) * sizeof(long);
   #else
       ...

   This code assumes that savefpregs only needs NSAVED_FPREGS*2 + 1
   words.  This assumption fails on the 386, since the entire FP
   coprocessor state must be saved, not just the registers.  

Fix:		
   A better approach is for savefpregs() to update the allocptr itself
   and return a pointer to the saved state:

   #if (NSAVED_FPREGS > 0)
       fpregs = savefpregs (msp);
   #else
       ...
Comment: [jhr]
  A better fix might be introducing a machine dependent constant for the
  fp-save area size.  Also, savefpregs should probably get the save area
  pointer as its argument, since this would simplify the assembly code
  a bit.
Status: obsolete
----------------------------------------------------------------------
Number: 607
Title: weak typing
Keywords: types, type checking, weak types
Submitter: John Greiner <John.Greiner@WAGOSH.FOX.CS.CMU.EDU>
Date: 8/4/92
Version: 0.86
Severity: major
Problem: 
  Weak typing error allows failure of type security.
Transcript: 
  - fn x => let val a = ref nil in
	  (let val b = a in b := [true]; hd (!b) + 1; (fn z => z) end) () end;
  val it = fn : 'a -> unit
Fix: This can be fixed by replacing "absd-abs" by "max(0,absd-abs)" in
     basics/typesutil.sml.
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 608
Title: minor error in runtime
Keywords: runtime, cfuns
Submitter: David Tarditi
Date: 8/4/92
Version: 0.85
Severity: minor
Problem: 
  In version 0.85, line 114: run.c, there's a function call of
  the form:
      init_externlist(msp)
  but you'll see in cfuns.c that init_externlist takes no arguments.
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 609
Title: include syntax
Keywords: syntax, include
Submitter: Larry Paulson <Larry.Paulson@cl.cam.ac.uk>
Date: 7/31/92
Version: 0.75
Severity: minor
Problem: 
  Standard ML of New Jersey, Version 75, seems to reject the syntax

     include SIGID1 ... SIGIDn

  (See the definition of Standard ML, page 13.)
Status: fixed in 0.90
----------------------------------------------------------------------
Number: 610
Title: changeLvars broken
Keywords: lambda
Submitter: Gene Rollins
Date: 8/5/92
Version: 0.87
Severity: major (for separate compilation)
Problem: 
  There is a compiler bug in SML/NJ 0.85 and 0.87 that is not present in 0.80.
  I tracked it down to this: the function changeLvars when applied to
  a staticUnit sometimes eliminates bindings to fixity symbols.  So, if you try
  to read a compiled binary file, and then compile a file that uses symbols
  defined in the binary file, you sometimes get an error such as this:

      a.sig:1.15-1.19 Error: FIRST undefined (parser)

  If the symbol is really undefined you also get this message:
      a.sig:1.15-1.19 Error: unbound signature: FIRST

  This happens on pmax_mach and sun4_mach machines.  I found that once you have
  a binary file that this bug happens with, it is repeatable.  But, not all
  binary files tickle this bug.
Transcript: 
  - System.system "cat first.sig";
  signature FIRST = sig val x:int end

  - val perv = !System.Env.pervasiveEnvRef;
  val perv = prim? : environment

  - val se = System.Env.staticPart perv;
  val se = prim? : staticEnv

  - val (staticUnit, codeUnit) = SepComp.compileSource ("first.sig", se);
  [closing first.sig]
  val staticUnit = {boundLvars=[],staticEnv=prim?} : System.Compile.staticUnit
  val codeUnit = prim? : codeUnit

  - val delta = System.Compile.execute ((staticUnit, codeUnit), perv);
  signature FIRST
  <other binding>
  val delta = prim? : environment

  - appSE (findName "FIRST") delta; (* catalogEnv; filter for symbols "FIRST" *)
  FIRST
     fixity information of a module component
  FIRST
     signature
  val it = () : unit

  - val staticUnit2 = System.Compile.changeLvars staticUnit;
  val staticUnit2 = {boundLvars=[],staticEnv=prim?} : System.Compile.staticUnit

  - val delta2 = System.Compile.execute ((staticUnit2, codeUnit), perv);
  signature FIRST
  val delta2 = prim? : environment

  - appSE (findName "FIRST") delta2;
  FIRST
     signature
  val it = () : unit
  -
Fix: adjust for new representation of fixity bindings?
Status: fixed in 0.91 (dbm)
----------------------------------------------------------------------
Number: 611
Title: batch compiler doesn't like local structure declarations
Keywords: modules, syntax, local
Submitter:      Mark Leone (mleone@cs.cmu.edu)
Date:		8/5/92
Version:        0.82
System:         all
Severity:       very minor
Problem:        batch compiler doesn't like local structure declarations
Code:         
	(* From bug report #278 *)
	local
	   structure Internal = struct val x=1 val y=2 end
	in
	   structure First  : sig val x : int end = Internal
	   structure Second : sig val y : int end = Internal
	end
Transcript:
	Standard ML of New Jersey, Version 82, June 1, 1992 (batch compiler)
	[Compiling tmp.sml]
	Error: signature, functor, or structure expected
	[closing tmp.sml]
Comments:
	This seems to be the same problem exhibited by the interactive
	top-level in bug report #278 (which has been fixed).
Status: fixed in 1.03f
----------------------------------------------------------------------
Number: 612
Title: bad lambda depth calculated in type checker
Keywords: type checking
Submitter:      Mark Lillbridge (mdl@cs.cmu.edu)
Date:		8/5/92
Version:        0.87
System:         Sparc
Severity:       major
Problem:        Lambda depth is miscalculated in some cases causing
		the compiler to core dump
Code:           
		fun id x = x;

		(fn y => id (let val u = y in u end)) 1 2;

Transcript:
		- fun id x = x;
		val id = fn : 'a -> 'a
		- (fn y => id (let val u = y in u end)) 1 2;
		Bus error (core dumped)

Comments:	The code in typesutil.sml that calculates lamdepth is
		wrong.  In cases like this, lamdepth can actually
		decrease instead of being monotonically increasing.
		(Here, lamdepth is 1 at the fn y => but 0 at the let.)

Status: fixed in 0.89
----------------------------------------------------------------------
Number: 613
Title: Compiler bug message on occurence of typevar in signature
Keywords: modules, signatures, type variables
Submitter:      Kees van Schaik <kees@diku.dk>
Date:		8/7/92
Version:        Version 75
System:         Sun 4 Sparc station running SunOS Release 4.1.1
Severity:       minor
Problem:        Compiler bug message on occurence of typevar in signature
Code: 		
		signature BuggySignature = 
		   sig exception IllegalException of '_a ref end

Transcript:	
		Standard ML of New Jersey, Version 75, November 11, 1991
		The Edinburgh SML Library Make is now pre-loaded.
		val it = () : unit
		- signature BuggySignature = 
		     sig exception IllegalException of '_a ref end;
		signature BuggySignature = 
		  sig
		    exception IllegalException of Error: Compiler bug: domain

Comments:	The signature is not a legal one since it is not allowed to
		use type variables in exception declarations in signatures.
		A somewhat more informative way of telling that would be
		nice (mostly to people who did not know/realise that their
		code was not legal when triggering the bug, who will most
		probably the only ones triggering it), but the bug does not
		cause any serious problems.

Comments: [dbm] Now generates an error message when signature is elaborated.

Status: fixed in 0.91 (dbm)
----------------------------------------------------------------------
Number: 614
Title: high-order-functor thinning-in
Keywords: modules, functors, signature matching, thinning
Submitter:    Zhong Shao   (zsh@cs.princeton.edu)
Date:         8/6/92
Version:      0.86
System:       mipsb/riscos
Severity:     critical
Problem:      high-order-functor thinning-in
Code:
              signature SIG = sig val e : real
                              end

              funsig PROD (structure M : SIG
                           structure N : SIG) = SIG

              structure S = struct val e = 100.0
                            end

              structure P = struct val e = 0.0
                            end

              functor Square(structure X : SIG
                             functor Prod : PROD) : SIG =
                  Prod(structure M = S
                       structure N = X)

              functor F(structure N : SIG) = struct val e = (N.e * N.e)
                                             end

              structure A = Square(structure X = P
                                   functor Prod = F);

              A.e;

Transcript:
              .....................
              - A.e;
              val it = 10000.0 : real

Comments:     A.e should be 0.0 instead. The problem is that
              when F is applied to (structure M=S structure N=P) in
              the body of functor Square, the argument is not thinned
              against the parameter signature of the functor F.

Status: fixed in 0.89
----------------------------------------------------------------------
Number: 615
Title: System.Symbol.makestring has incomplete implementation
Keywords: makestring
Submitter:      Andrew Tolmach (apt@research.att.com)
Date:		8/10/92
Version:        0.85 through 0.88
System:         mips riscos
Severity:       minor
Problem:        Can't apply System.Symbol.makestring to pervasive environment.
Code:           - let open System.Env System.Symbol 
		  in map makestring (catalogEnv (staticPart(!pervasiveEnvRef)))
		  end;
Transcript:     above code causes 
		Compiler bug: Symbol.makestring
	
Fix:  Add TABspace case to Env.symbolToString (?)
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 616
Title: overloading versus user-bound type variable
Keywords: types, overloading, type variables
Submitter: Lars Birkedal <birkedal@diku.dk>
Date: 8/12/92
Version: 0.87 (and earlier)
Severity: minor
Problem: 
  I assume you resolve arithmetic overloading in NJSml by 
  binding the operators, such as +, to a generel type-scheme, such 
  as \forall 'a. 'a *'a -> 'a, where the type-variables are marked
  as overloaded, and then elaborates as usual with the exception
  that overloaded type variables are not allowed to be quantified. 
  (Some examples I've run indicates this.)

  The following example seems to indicate that you allow unification of
  overloaded type variables with explicit type variables and when
  unifying marks the explicit type variables as overloaded. This mark
  prohibits quantification of the explicit type variable at its scoping
  declaration, hence violating rule 17 in the Definition.  My question
  is --- why allow unification of overloaded typevariables with explict
  type variables at all?; since quantification is not allowed,
  overlaoding cannot be resolved this way (as in let val f = fn x => x +
  x in f 2 end, which elaborates), so the only other way is to unify the
  explicit type variable with int or real, which is not allowed, hence
  overloading cannot be resolved this way either. So what do you gain?

Transcript: 
  - let val f = fn (x: 'a) => x + x in f 2 end;
  std_in:1.5-1.31 Error: explicit type variable cannot be generalized at its scoping declaration: 
  'a
  std_in:1.29 Error: overloaded variable "+" cannot be resolved

Comment: [dbm]
  The type variables of the type scheme of an overloaded variable are
  "marked as overloaded" when an instance of the type scheme is created
  for a particular applied occurence of the variable.  This marking is
  accomplished by a book-keeping device -- each type metavariable
  substituted for a bound variable of the scheme is given a "depth" of
  zero.  The depth attribute is used to determine whether a metavariable
  can be generalized at a val binding, and a depth of zero will prevent
  these metavariables (or metavariables in types substituted for them)
  from ever being generalized.

  When one of these metavariables is unified with a "user-bound" type
  variable like the 'a in your example, the depth of the metavariable is
  propagated to the user-bound variable, which in this case prevents the
  user-bound variable from being generalized at the appropriate place.
  This looks like a bug -- in fact, I think that the user-bound variable
  should probably not have a depth attribute at all.

Status: not a bug (but alternate handling might be better)
----------------------------------------------------------------------
Number: 617
Title: interpreter fails with "no default in interp"
Keywords: interpreter
Submitter:      Andrew Tolmach (apt@research.att.com)
Date:		8/12/92
Version:        0.87
System:         mips riscos
Severity:       major
Problem:        On a variety of programs, the interpreter 
		fails with "no default in interp". 
Code:		System.Control.interp := true;
		use "/usr/local/sml/benchmarks/leroy.sml";
			(* the standard knuth-bendix benchmark *)

Transcript:   

signature KB = 
  sig
    datatype ordering
      con Equal : ordering
      con Greater : ordering
      con NotGE : ordering
    datatype term
      con Term : string * term list -> term
      con Var : int -> term
    val doit : unit -> unit
    val kb_complete : (term * term -> bool) -> (int * (int * (term * term))) list -> ('a * ('b * (term * term))) list -> unit
    val lex_ext : (term * term -> ordering) -> term * term -> ordering
    val rpo : (string -> string -> ordering) -> ((term * term -> ordering) -> term * term -> ordering) -> term * term -> ordering
  end
/usr/local/sml/benchmarks/leroy.sml:603.1-608.22 Warning: match not exhaustive
        "U" => ...
        "*" => ...
        "I" => ...
        "B" => ...
        "C" => ...
        "A" => ...
Error: Compiler bug: no default in interp
[closing /usr/local/sml/benchmarks/leroy.sml]
Comments: Failure to track changes in data representations?
  
If the debugger is built using makeml -i, this bug occurs
the first time a usedbg_live is tried.

Status: fixed in 0.90
----------------------------------------------------------------------
Number: 618
Title: LOOKUP FAILS, Compiler bug: 110 in CPSgen
Keywords: CPSgen
Submitter: Dave MacQueen
Date: 8/15/92
Version: 0.87
System: Sparc, Mips
Severity: critical
Code: 
  (* bug618.sml *)

  signature S0 =
  sig
    exception Error of string  (* string arg necessary *)
  end

  functor F (X : S0) =
  struct
    open X
    fun extend_one (i,v,r) j = if i = j then v else (r j) (* necessary *)
    fun extend_env _ = raise Error "foo"
  end

  structure A : S0 =
  struct
    exception Error of string
  end

  structure B = F(A)
Transcript: 
  skye$ sml
  Standard ML of New Jersey, Version 0.87, July 31, 1992
  val it = () : unit
  - use "bug618.sml";
  LOOKUP FAILS in close(FIX 2373
  ) on 2310
  in environment:
  2370 2368 2451 2448 2449 2450 
  2369/callee 2451 - 2448 2449 2450
  Error: Compiler bug: 110 in CPSgen
  [closing bug618.sml]
  - use "bug618.sml";
  Illegal instruction(coredump)
  skye$ 
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 619
Title: Compiler bug: Escapemap on xxxx
Keywords: modules, functors, code generation
Submitter: Dave MacQueen
Date: 8/15/92
Version: 0.87
System: Sparc, Mips
Severity: critical
Code: 
  (* bug619.sml *)

  signature SIG =
  sig
    exception Error of string
  end

  functor F (X : SIG) =
  struct
    open X

    datatype Exp = APP of Exp * (Exp list)
    datatype Val = FUNC of Val list -> (Val -> unit) -> unit

    fun extend_one (i,v,r) j = if i = j then v else (r j)
    fun extend_env([],[],r) = r
      | extend_env(i::is,v::vs,r) = extend_env(is,vs,extend_one(i,v,r))
      | extend_env _ = raise Error "mismatching environment extension"

    fun  meaning (APP(e,es)) r k =
	  meaning e r (fn (FUNC f) => meaninglis es r (fn vs => f vs k))

    and meaninglis [] r k = k []
      | meaninglis (e :: es) r k =
	  meaning e r (fn v => meaninglis es r (fn vs => k (v :: vs)))
  end

  structure A : SIG =
  struct
    exception Error of string
  end

  structure B = F(A)  (* necessary *)
Transcript: 
  - skye$ sml
  Standard ML of New Jersey, Version 0.87, July 31, 1992
  val it = () : unit
  - use "bug619.sml";
  Error: Compiler bug: Escapemap on 2423
  [closing bug619.sml]
  - 
Comment: probably closely related to bug 618.  Minor simplifications
	 of the code produce a version of bug 618.
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 620
Title: higher-order functor causes Compiler bug
Keywords: modules, functors, higher-order functors
Submitter: Dave MacQueen
Date: 8/15/92
Version: 0.87
Severity: major
Problem: 
  Higher order functor definition fails with
  "Compiler bug: abstractfct:tyconSeries1: param tycon not found"
Code: 
  signature SIG =
  sig
    datatype d = D of unit   (* the "of unit" is necessary for bug *)
  end

  functor Twice(functor F(A:SIG):SIG) =
  struct
    functor TwiceF(A: SIG) = F(F(A))
  end
Transcript: 
  - use "bug620.sml";
  Error: Compiler bug: abstractfct:tyconSeries1: param tycon not found
  [closing bug620.sml]
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 621
Title: polymorphic equality not eliminated as often as it should be
Keywords: equality, polymorphism
Submitter:   aitken@cs.cornell.edu (William E. Aitken)
Date:        8/13/92
Version:     0.87 (also 0.88b)
System:      sun4 sunos 
Severity:    minor
Problem:     polymorphic equality not eliminated as often as it should be
Code:        
	     val eq = (op =)
	     val eq1 : int * int -> bool = (op =)
	     val eq2 = (op =) : int * int -> bool
	     
Transcript: 
(Script started on Thu Aug 13 11:46:13 1992)
ai $ sml
Standard ML of New Jersey, Version 0.87, July 31, 1992
val it = () : unit
- System.Control.CG.printit := true;
val it = () : unit
- (* this should be implemented as poly-eq *)
= val eq  = op =;

After convert:
2316(2314,2315) =
   2317(2313,2318) =
      2319(2320) =
         2318((I)0)
      2313((I)99,2319)
   2317(2314,2315)
.
.
.
val eq = - : ''a * ''a -> bool

- (* this should be implemented as integer equality, but isn't *)
= val eq1 : int * int -> bool = (op =) ;

After convert:
2346(2344,2345) =
   2347(2343,2348) =
      2349(2350) =
         2348((I)0)
      2343((I)99,2349)
   2347(2344,2345)
.
.
.
val eq1 = - : int * int -> bool
-
- (* this should be implemented as integer equality, and is *)
= val eq2 = (op =) : int * int -> bool;

After convert:
2376(2374,2375) =
   2377(2373,2378) =
      2379(2380) =
         2382(2381,2383) =
            2381.0 -> 2384
            2381.1 -> 2385
            if ieql(2384,2385) [2388] then
               2383((I)1)
            else
               2383((I)0)
         {2382} -> 2389
         2378(2389)
      2373((I)99,2379)
   2377(2374,2375)

.
.
.

val eq2 = fn : int * int -> bool

(script done on Thu Aug 13 11:47:39 1992)

Comments:

eq1 implements the equality check as a call to
polymorphic equality, while eq2 
inline expands the equality for the type int.

This is particularly obnoxious since, at least to me, 
the declaration of eq1 looks prettier.

Status: fixed in 0.89
----------------------------------------------------------------------
Number: 622
Title: Bus error on DECstation 5000/200
Keywords: DECstation
Submitter: Urban Engberg <urban@daimi.aau.dk>
Date: 8/18/92
Version: 0.75-0.80
System: DECstation 5000/200 and 5000/240
Severity: major
Problem: 
  I have been using SML of NJ for a couple of years, mostly for writing
  compiler-related tools.  The tool I am currently working on contains about 7000
  lines of sml-code, including the code produced by sml-lex and -yacc.  The
  relatively large size of the program seems essential to my problem to be
  described.

  When compiling the code, by reading in the files with "use", the sml system
  once in a while crashes with messages such as

    pid 22613 (tlac.orig) was killed on an unaligned access, at pc 0x100a3550
    Bus error (core dumped)

  The problem has been specific to running on DECstations 5000/200 and 5000/240
  (at least) but occurs on all the machines of this kind that I have tried.

  I have been able to bear over with the problems for some time, without trying
  to find the error, as I would just have to restart the compilation at the right
  point a couple of times.

  Lately, however, the problem has started showing up more and more often when I
  execute the binary image I create with the library-construct "exportFn".  As my
  code has been growing, I have now got a ratio of well-functioning runs to ones
  crashing of about 1:10!  Thus it is beginning to be a very big problem.

  [added 8/19/92]
  The problem occurs at random.  But running a compilation which takes about five
  seconds will currently produce the crash nine times out of ten.

  I am running Ultrix version 4.2A (Apr 92), which I suppose is one of the
  newest.  I remember having had problems all the time since I began using DEC
  machines though, since March 91.  You are quite right in that `unaligned
  access' errors seems to indicate some sort of Ultrix bug.
Comments: [George]
  This brings back memories of when I was bringing up the new MIPS
  code generator. The regression tester specifically, would run
  just fine on a MIPSEB but would crash once in a while in a 
  non-deterministic manner on a MIPSEL. The error message was 
  identical - unaligned access, at pc ...

  At the time, we concluded that this was an operating system related 
  problem, and not the fault of the generated code. Unfortunately, I 
  did not persist in getting to the root of the problem. I am not 
  able to reproduce the error as the regression tester being used
  is gone!!

  My suggestion would be to try a post v 0.82 release that had
  even less reliance on the operating system - i.e., any trapless gc
  version.

Followup: [Urban Engberg, 8/24/92]
  It has been making me curious that the errors lately doesn't seem to show up in
  other programs than my compiler (where it with earlier sml versions has been a
  problem with many programs, and also when compiling the compiler).  So with a
  good guess, I tried removing some calls I had to `IO.execute'.  This made a
  crucial difference; the compiler now runs without any problems.

  To help finding the error, it should be noted that the compiler works fine
  *with* the `IO.execute' commands, when run from within an interactive sml
  session.

  I have tried to reproduce the error in a smaller program, but without success.

  The calls to `IO.execute' looked as follows:

	  val (datestream, dummy) =
		      IO.execute ("/bin/csh", ["-cfb", 
				  "/bin/date +\"%a %h %d%H:%M 19%y\""])
	  val date = input (datestream, 21) before (close_in datestream;
						    close_out dummy)
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 623
Title: wildcard is equivalent to a series of wildcards (see also 629)
Keywords: syntax, wildcards
Submitter:      cregut 
Date:		20/8/92
Version:        .88
System:         all
Severity:       minor/major
Problem:        wildcard is equivalent to a serie of wildcards
Code:
  fun foo x 0 = x | foo _ = 0;  (* this failed in pre-0.88 versions *)
Transcript:
  val foo = fn : int -> int -> int
Status: fixed in 0.90
----------------------------------------------------------------------
Number: 624
Title: System.Env.filterEnv causes Compiler bug: copystat.
Keywords: environment, filterEnv
Submitter: Gene Rollins
Date: 8/21/92
Version: 0.88
Severity: major
Problem: 
  System.Env.filterEnv causes compiler bug: copystat.
Code: 
==== env.sml ====
structure TestEnv = struct
 fun printEnv (e:System.Env.environment) =
   app (fn s=> (print ((System.Symbol.makestring s) ^ "\n")))
     (System.Env.catalogEnv (System.Env.staticPart e))
 val TestStructure = System.Symbol.strSymbol "Test";
 fun test() =
   (use "test.sml";
    printEnv (!System.Env.topLevelEnvRef); print "----------\n";
    printEnv(System.Env.filterEnv(!System.Env.topLevelEnvRef,[TestStructure])))
end
==== test.sml ====
structure Test = struct val x = 4 end
Transcript: 
Standard ML of New Jersey, Version 0.88, August 14, 1992
- use "env.sml";
structure TestEnv : sig
    val TestStructure : symbol
    val printEnv : environment -> unit
    val test : unit -> unit
  end
- TestEnv.test();
structure Test : sig val x : int end
[closing test.sml]
STRTAB$Test
STRTAB$TestEnv
STR$Test
STR$TestEnv
VAL$it
----------
Error: Compiler bug: copystat
- 

Status: fixed in 0.89 (Cregut)
----------------------------------------------------------------------
Number: 625
Title: Runbind exception still being raised.
Keywords: Runbind
Submitter: Gene Rollins, Andrew Appel
Date: 8/21/92
Version: 0.88
Severity: major
Problem: Runbind exception still being raised.
Status: fixed in 0.91 (not verified)
----------------------------------------------------------------------
Number: 626
Title: extra spaces in SPARC.prim.s
Keywords: assembly
Submitter: Gene Rollins
Date: 8/21/92
Version: 0.88
System: SPARC
Severity: 
Problem: 
It appears that our assembler can't handle the extra spaces given in several
of the #defines in the original file SPARC.prim.s.0.  The new SPARC.prim.s
works fine.  Here are the differences.  They are all within the first 55 lines.
Fix:
% diff SPARC.prim.s.0 SPARC.prim.s
26c26
< #define exncont  g7  /* exception handler (ml_exncont)	*/
---
> #define exncont g7   /* exception handler (ml_exncont)	*/
29,35c29,35
< #define limit    g4  /* heap limit pointer (ml_limitptr)*/
< #define stdarg   i0  /* standard argument (ml_arg)  	*/
< #define stdcont  i1  /* standard continuation (ml_cont) */
< #define stdclos  i2  /* standard closure  (ml_clos)	*/
< #define baseptr  i3  /* base code pointer (ml_roots[])  */
< #define varptr   i5  /* var pointer       (ml_varptr)   */
< #define stdlink  g1  
---
> #define limit g4     /* heap limit pointer (ml_limitptr)*/
> #define stdarg i0    /* standard argument (ml_arg)  	*/
> #define stdcont i1   /* standard continuation (ml_cont) */
> #define stdclos i2   /* standard closure  (ml_clos)	*/
> #define baseptr i3   /* base code pointer (ml_roots[])  */
> #define varptr i5    /* var pointer       (ml_varptr)   */
> #define stdlink g1  
49,53c49,53
< #define tmp1  o2
< #define tmp2  o3
< #define tmp3  o4
< #define tmp4  o5  /* also used to pass register mask to g.c. */
< #define gclink  o7   /* link register for return from g.c.  (ml_pc) */
---
> #define tmp1 o2
> #define tmp2 o3
> #define tmp3 o4
> #define tmp4 o5     /* also used to pass register mask to g.c. */
> #define gclink o7   /* link register for return from g.c.  (ml_pc) */
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 627
Title: blast-writing objects outside the heap leads to failure
Keywords: I/O, blast_write
Submitter: David Tarditi
Date: 8/21/92
Version: 0.88
Severity: major
Problem: 
  blast-write fails when given an object that is outside the
  heap.   The following program (for version 0.75, shareable) demonstrates this.
  You'll have to change the program slightly to run it in the latest version of
  the compiler, since the type of blast_read has changed.
Code: 
  structure blast =
      struct
	  val s = System.version
	  val outblast = fn () =>
	    let val outfd = open_out "testblast"
	     in (System.Unsafe.blast_write (outfd, s); close_out outfd)
	    end
	  val inblast = fn () =>
	    let val infd = open_in "testblast"
		val res : string = System.Unsafe.blast_read infd
		val _ = close_in infd
	    in
	      (print "Got back: "; print res; print " : from testblast\n")
	    end

	  val _ = outblast ()
	  val _ = inblast ()
  end
Transcript: 
  - use "/usr/dtarditi/tmp";
  [opening /usr/dtarditi/tmp]

  [Major collection...abandoned]
  Got back:  : from testblast
  structure blast : 
    sig
      val inblast : unit -> unit
      val outblast : unit -> unit
      val s : string
    end
  [closing /usr/dtarditi/tmp]
  val it = () : unit
Comments:
  In the shareable version of the compiler, where the code for the compiler
  is palced outside the heap, the string System.version ends up outside the
  heap.
Fix:
  The solution is to add a check to the code for blast-write, I think,
  for the case where the object being blasted out is a pointer that is outside
  the heap.
  [Tarditi, 8/21/92:]
  I remember there was some problem about import not working across 
  different compiled versions of the same compiler.  For example,
  I think import files created with a shareable version of the compiler
  caused the nonshared version to crash.   I've realized what the problem
  is, and it is worth noting down for future reference.

  The basic problem is that blast_write isn't fully generally, and only
  works with a particular executable.  If you blast-write an object which
  contains pointers that are outside the heap, the garbage collector
  just copies the pointers as though they were integers.   The problem is
  that with different executables, the objects outside the heap may not
  exist at all, may be different (that is, the pointer points to junk), or
  they may be at a different address.

  Think about what happens when you blast-write a function.   The function
  will most likely contain objects from the pervasive environment in its
  closure.  Suppose one of those objects from the pervasive environment
  is a closure.  It will contain a code pointer.  If the compiler is 
  shareable version, the code pointer will be outside the heap.  Now,
  if we try to read blast_read this function into a nonshareable version
  of the compiler, the code pointer will be junk!  

  Note that you'll have this problem even if only the runtime has been
  changed across executables.  This will change the address of code for
  the assembly language primitives, and the addresses of ML objects allocated
  as static C data structures.

  A possible solution to add a level of indirection between objects in the
  runtime system and blast-written objects.

  (1) give every possible ML object in the runtime system a unique name
  (2) when blast-writing an object, translate ML objects outside the heap to
      their unique names
  (3) when blast-reading an object, translate from the unique names back to the
      ML objects.

  We could hack something up to deal with the code strings for the pervasives
  being either in the heap or text segment.

  We'd have to put a limitation that you can only blast-read/blast-write objects
  outside the heap which are "registered" (i.e. you can't blast-write things
  like the code for the compiler).   At least things could fail gracefully
  instead of crashing.

Status: fixed in 0.89
----------------------------------------------------------------------
Number: 628
Title: System.Env.filterEnv broken (accidental duplicate of 624)
Status: fixed in 0.89 (Cregut)
----------------------------------------------------------------------
Number: 629
Title: fun declaration syntax  (see 623)
Keywords: syntax, fun declaration
Submitter:      aitken@cs.cornell.edu (William E. Aitken)
Date:		8/29/92
Version:        0.88 (back to 0.83 -- worked in 0.82)
System:         Sun 4m/670 MP Sparc, SunOS Release 4.1.2
Severity:       minor
Problem:        function declarations made using `fun' may
		arbitrarily mix clauses in which the 
		formal parameters are curried and 
		clauses in which they are uncurried.  
		Note that if they are uncurried, the formal
		pattern must be of n-tuple type.  That is,
		it may be a variable pattern or a wildcard pattern
		or a tuple pattern of the appropriate arity.

Code:           
		fun foo 1 x = 17
                  | foo (a, b) = a + b
		
		fun bar (1, x) = 17
		  | bar a b = a - b

		fun splat a b = 4
		  | splat x = 5

Transcript: 
    
% sml
Standard ML of New Jersey, Version 0.88, August 14, 1992
val it = () : unit
- fun foo 1 x = 17
=   | foo (a, b) = a + b;
val foo = fn : int -> int -> int
- fun bar (1, x) = 17
=   | bar a b = a - b;
val bar = fn : int * int -> int
- fun splat a b = 4
=   | splat x = 5;
std_in:5.17-6.15 Warning: redundant patterns in match
        (a,b) => ...
        x => ...
val splat = fn : 'a -> 'b -> int
- ^D
% 

Comments:

	There are two function declarations in
	translate/tempexpn.sml that (accidentally)
	exploit this bug.  They are the last two functions of
	the structure.  In the first case, the second argument needs
	to be uncurried, in the second case, the final clause
	needs a second wildcard pattern.  Similarly,
	the function labBranchOff in mips/mipsinstr.sml, needs
        a second wildcard pattern in its final clause's formal parameters.

	The problem occurs because no explicit test is ever made 
	to ensure that clauses have the same number of argument 
	patterns.  In elaborating a function declaration,
	the compiler produces something of the form

		fn x1 => ... => fn xn => case (x1, ..., xn) of
			p1 => e1
			.
			.
			.
			pm => em

	x1, ..., xn are distinct new variables.
	ei is the expression of the ith clause.
	n is the number of patterns in the *first* clause
	If the ith clause has r > 1 patterns (pi1, ..., pir), pi is the 
	the pattern (pi1, ..., pir).   If the ith clause has only
	one pattern, pi is that pattern.

	The type checker will detect most mis-matches between
	numbers of arguments --- e.g.,

		fun foo a b c = 4 
		  | foo a b = 5;
		std_in:7.17-7.31 Error: rules don't agree (tycon mismatch)
  		  expected: 'Z * 'Y * 'X -> int
  		  found:    'W * 'V -> int
  		  rule:
    		    (a,b) => 5

	but will not catch mis-matches between appropriately typed single 
	patterns and multiple patterns.  	
	
Fix:	Add a check that the number of formal parameters agrees in  
	each clause.  Rewriting checkFB in parse/astutils.sml as 
	follows should work, the compiler compiles itself to a fixpoint
	with it installed, but I have *not* tested the resulting code
	very thoroughly.   (Note that translate/tempexpn.sml and 
	mips/mipsinstr.sml need to be fixed too, as described above).

	fun checkFB(clauses as ({name,pats,...}:rawclause)::rest, err) = 
	      let 
	        val patslen = length pats
      	      in 
		if exists (fn {name=n,...} => not(Symbol.eq(n,name))) rest
      	          then err COMPLAIN "clauses don't all have same function-name"
      	        else if exists (fn {pats=p,...} => length p <> patslen) rest
      	        then 
		  err COMPLAIN "clauses don't all have same number of patterns"
	        else ();
	        clauses
	      end
  	  | checkFB _ = ErrorMsg.impossible "CoreLang.checkFB"

	if calculating the length is too expensive here, 
	using the function

	fun len1 [x] = true | len1 _ = false

	will suffice, at the expense of less good error reporting.
Status: same as 623
----------------------------------------------------------------------
Number: 630
Title: smallest number literal in patterns (same as 507)
Keywords: literals, patterns
Submitter:      aitken@cs.cornell.edu (William E. Aitken)
Date:		8/29/92
Version:        0.88
System:         Sun 4m/670 MP Sparc, SunOS Release 4.1.2
Severity:       minor
Problem:        the special constant denoting the smallest 
		member of the type int (~1073741824) causes
		compilation failure if it appears in patterns. 
		It is legal in expressions.

Code:           
		 fun foo ~1073741824 = 5 
		       | foo x = 3

Transcript: 
    
% sml
Standard ML of New Jersey, Version 0.88, August 14, 1992
val it = () : unit
- ~1073741824;
val it = ~1073741824 : int
- fun foo ~1073741824 = 5 | foo x = 3;
Error: Compiler bug: Overflow in cps/generic.sml
- ~1073741824;
val it =
uncaught exception Boxity
- ~1073741824;
val it = ~1073741824 : int
1073741824;
std_in:2.1-2.10 Error: integer too large
- ^D
% 

Comments: 	If I've already submitted this bug, sorry.
	
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 631
Title: PrintVal can't print a value of the Ast type
Keywords: printing
Submitter:      cregut
Date:		8/29/92
Version:        from .86
System:         sparc mips..
Severity:       
Problem:        PrintVal can't print a value of the Ast type
Code:
(* int.sml *)
structure interface = struct
  local
    open System.Compile System.Env
  in
  fun ast name =
     let val f = open_in name
         val source = makeSource (name,0,f,false,std_out)
         val (ast : System.Ast.dec,_) =
           parse(source,staticPart (!pervasiveEnvRef))
     in ast end
  end
end

Transcript:

- use "int.sml";
structure interface :
  sig
    val ast : string -> System.Ast.dec
  end
[closing int.sml]
val it = () : unit
- interface.ast "int.sml";
val it = SeqDec [MarkDec (Error: Compiler bug: PrintVal.switch: none of the data
cons matched
-

Comments: The AST type is built in parse/ast.sml but another version is
in system.sig and perv.sml so that the user can access it.
It is not a problem of consistency of defs (no changes with 85).
Fix: make sure ast.sml is compiled with newconreps having the
same value that will be default for the user.  That is, 
put "^newconreps !ast.sml ^newconreps" in the "all" file.
Status: fixed in 0.89
----------------------------------------------------------------------
Number: 632
Title: minimal or maximal integer literals in patterns cause compiler bug
Keywords: literals, patterns
Submitter:      aitken@cs.cornell.edu (William E. Aitken)
Date:           8/30/92
Version:        0.88, also 0.75
System:         SunOS Release 4.1.2, Sun 4m/670 MP Sparc
Severity:       major
Problem:        Integer patterns larger than 2^29-1 or
	        smaller than ~2^29 trigger a compiler bug.
Code:           
		fun foo 0x20000000 = true | foo x = false;

Transcript:     Standard ML of New Jersey, Version 0.88, August 14, 1992
		val it = () : unit
		- fun foo 0x20000000 = 5 ;
		std_in:2.1-2.22 Warning: match not exhaustive
			536870912 => ...
		Error: Compiler bug: Overflow in cps/generic.sml
		- 12;
		val it = 
		uncaught exception Boxity
		- fun foo  ~0x20000000 = 5 ;
		std_in:0.0-0.0 Warning: match not exhaustive
		        ~536870912 => ...
		val foo = fn : int -> int
		- fun foo ~0x20000001 = 5; 
		std_in:2.1-2.23 Warning: match not exhaustive
		        ~536870913 => ...
		Error: Compiler bug: Overflow in cps/generic.sml
		- 

Comments:	This is just a generalization of a bug reported 
		yesterday.
Status: same as 507
----------------------------------------------------------------------
Number: 633
Title: space leak
Keywords: space leak, memory management
Submitter: John Reppy
Date: 1/9/92
Version: 0.88
Severity: major
Problem: 
The old space leak in capture/escape seems to have reappeared.
I ran my test on versions 0.75-0.88, and here is a summary of
the results:

  version    space leak?
    75		no
    76		no
    77		yes
    78		yes
    79		yes
    80		yes
    81		no
    82		no
    83		no
    84		yes
    85		yes
    86		yes
    87		yes
    88		yes

Note that the two rounds of contract before eta were eliminated in
version 0.84.

As a reminder, the simple example of this problem is the function
select.

Code: 
  local
    open System.Unsafe.PolyCont
  in
    fun select x = capture (fn k => let
          val return = escape k
          in
            return (x ())
          end)
  end;

  which is called in the following loop:

  fun loop () = select loop
Comments: This should be constant space!
Status: fixed in 0.90 (again!)
----------------------------------------------------------------------
Number: 634
Title: Uncaught expception NotDirectory
Keywords: 
Submitter:    Zhong Shao   (zsh@cs.princeton.edu)
Date:         9/4/92
Version:      0.88 
System:       mipsb/riscos and mipsl/ultrix
Severity:     major 
Problem:      Uncaught expception NotDirectory
Code:
(**************************************************************************
 * THIS IS THE FILE getwd.sml ---------  Modified from SourceGroup        *
 * version 2.2  tools/sourcegroup/local/System/getwd.sml                  *
 **************************************************************************)

  structure GetWorkingDirectory :sig val getwd :unit -> string end = struct

  fun withInOutStreams (inS :instream, outS :outstream)
      (action :instream * outstream -> 'a -> 'b) (argument:'a) :'b =
    let val result = action (inS, outS) argument
                       handle exn => (close_in inS; close_out outS; raise exn)
     in
      close_out outS; close_in inS;
      result
    end

  val SYS_wait = 84

  fun waitForProcess () =
   (while (((System.Unsafe.CInterface.syscall (SYS_wait, System.Unsafe.cast 0))
      handle System.Unsafe.CInterface.SysError _ => 0) > 0) do ())

  fun firstLine (program:string, args :string list) =
    let fun strip_newline str =
             let val len = size str in
               if len > 0 then substring (str, 0, len - 1)
                          else str end
        fun first_line (inS,outS) () = strip_newline (input_line inS)
        val result =
          withInOutStreams (execute (program, args)) first_line ()
     in
      waitForProcess(); result
    end

  fun getwd () = firstLine ("/bin/pwd", [])

  end

  val _ = 
   (let
      val cwd = GetWorkingDirectory.getwd() 
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd() 
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd() 
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd
      val cwd = GetWorkingDirectory.getwd()
      val _ = System.Directory.cd cwd

    in print "\n \n This is correct! \n \n"
   end) handle _ => 
          (print "\n\n This is wrong, Why exceptions? \n\n")

Transcript:

  - use "getwd.sml";


   This is wrong, Why exceptions?

  structure GetWorkingDirectory :
    sig
      val getwd : unit -> string
    end
  [closing /u/zsh/tcps/work/new/bug/tt.sml]
  val it = () : unit
  -

Comments:  "Uncaught exception NotDirectory" happened RANDOMLY(50%)
           when doing "val cwd = GetWorkingDirectory.getwd();
           System.Directory.cd cwd;" This is why I did ten runs
           of it in the above script. I suspect the getwd.sml
           in SourceGroup is coded in an incompatible way with 
           the version 88's Directory.cd function in perv.sml (or 
           runtime/cfuns.c), since the above bug did not occur in 87. 

           This bug occurs (sometimes,say one out of two times) when 
           making smlsg using version88.

	  ** This is probably another example of bug #651 (JHR, 10/6/92) **
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 635
Title: ByteArray.update and ByteArray.sub raise Ord
Keywords: ByteArray
Submitter: 	Robert Cooper (rcbc@cs.cornell.edu)
Date: 		9/10/92
Version: 	0.75 (broken in 0.89)
System: 	any
Severity: 	minor
Problem: 	ByteArray.update and ByteArray.sub raise Ord
		instead of Subscript
Transcript: 
	Standard ML of New Jersey, Version 0.89, September 4, 1992
	val it = () : unit
	- open ByteArray;
	open ByteArray
	- val a = array(2, 0);
	val a = - : bytearray
	- update (a, 2, 100);

	uncaught exception Ord
	- a sub 2;

	uncaught exception Ord

Comments: The inline operators are incorrectly defined.
Status: fixed in 0.90
----------------------------------------------------------------------
Number: 636
Title: Vector patterns don't work at top level
Keywords: vectors, patterns, top level
Submitter: Dave MacQueen
Date: 9/10/92
Version: 0.88
Severity: major
Problem: Vector patterns don't work at top level
Transcript: 
  Standard ML of New Jersey, Version 0.89, September 4, 1992
  val it = () : unit
  - val v = #[1,2,3];
  val v = #[1,2,3] : int vector
  - val #[a,b,c] = v;
  std_in:5.1-5.16 Warning: binding not exhaustive
          #[a,b,c] = ...
  - a;

  uncaught exception IntmapF
  - let val #[a,b,c] = v in a end;
  std_in:0.0-0.0 Warning: binding not exhaustive
          #[a,b,c] = ...
  val it = 1 : int
Status: fixed in 0.90
----------------------------------------------------------------------
Number: 637
Title: Compiler bug printing signatures with polymorphic exceptions (same as 613)
Keywords: modules, signatures, printing
Submitter: Gene Rollins
Date: 9/10/92
Version: 0.88?
Severity: minor
Problem: 
The Compiler reports a compiler bug when trying to print signatures that
contain polymorphic exceptions.  This happens with both 0.75 and 0.80 versions
on both sun4 and decstation machines running mach.
Code: 
Transcript: 
- signature SEQUENCE = sig 
   exception no_next of 'a
   end;
signature SEQUENCE = 
  sig
    exception no_next of Error: Compiler bug: domain
Comments:
If we set:
  System.Control.Print.signatures := 0;

the compiler compiles the signature fine, and does not report the compiler
bug.
[DBM:] Polymorphic exception specifications in signatures are (or should
be) illegal, so these should cause some error message.
Status: same as 613
----------------------------------------------------------------------
Number: 638
Title: subnormal numbers
Keywords: floats, literals
Submitter: Appel
Date: 9/15/92
Version: 0.89
System: Sparc
Severity: minor
Problem: The "ln" function does not expect subnormal numbers, and gives wrong
answers.  Other functions may have similar problems.

Code: 
Transcript: 
val x = 1.0E~160;
val x = 1.0E~160 : real
- x * x;
val it = 9.99988867182683E~321 : real
- ln it;
val it = ~4.05753556581235 : real
-
Comments:
Fix:
Status: fixed in 0.90
----------------------------------------------------------------------
Number: 639
Title: multiple compiler compilations on sparc fail
Keywords: sparc
Submitter: Pierre Cregut
Date: 9/15/92
Version: 0.89
System: SunOS 4.1, SPARC 2, 64MB
Severity: major
Problem: 
  When multiple compilations of the ML compiler are launched
  on a single sparc 2, some of them fail with "Bus error" or
  "Segmentation fault".
Transcript: 
I have done the experiment but forgot it... so here is the result of
launching 3 smlc (.89) on skye

One is Ok and has finished...
another:
> [closing elaborate/normalize.sml]
> [Compiling modules/moduleutil.sml]
> structure ModuleUtil : ...
> 
> [Major collection... 7% used (1403140/20038536), 1040 msec]
> Bus error
and the last
> signature GENERAL = ...
> [closing boot/perv.sig]
> [Loading boot/system.sig]
> 
> [Increasing heap to 24114k]
> Segmentation fault
who died very quickly !!
Comments:
Why did it asked for such a swap space suddenly: it is completely ridiculous
at that point...
Status: obsolete
----------------------------------------------------------------------
Number: 640
Title: flakiness of System.Env (particularly filterEnv)
Keywords: environment, filterEnv
Submitter: Sanjiva Prasad <sanjiva@ecrc.de>
Date: 9/16/92
Version: 0.88
Severity: major
Problem: 
Perhaps someone in your group has already discovered and fixed these bugs
in v88.  We had pulled over a copy of v88 to experiment with the new
environment features you had advertised (with the intention of trying out
an mini interpreter that does not maintain the application environment, but 
evaluates a syntax tree in a given environment). 

I mucked around a bit, trying to create some small environments by making 
type, structure, functor and value declarations, then using map, 
some list operations like rev and some auxiliary functions, and
(from System.Env) catalogEnv, topLevelEnvRef, staticPart and filterEnv.
Unfortunately, I kept getting Compiler Bug messages when I used filterEnv
(I organized my program carefully enough to isolate the occurrence of these
to the use of filterEnv).

The ugly part of the story is that although repeating the evaluation
resulted in the same bug message or exception being raised, there was
no pattern to it.  For instance, filtering out an environment from the top-level 
environment using a list of seven symbols -- obtained from applying
staticPart and then catalogEnv --  resulted in  a compiler bug message
"compstat" (I think it was that).  With a different list (again obtained
using list operations, catalogEnv, staticPart and topLevelEnvRef), I got
uncaught exception IntmapF,  and then with another list (this time built using
string-to-symbol functions in System.Symbol), I got another compiler bug
(I can't recall which).  In all cases, it is when trying to use filterEnv.
Comment: [dbm] can't reproduce
Status: not reproducible
----------------------------------------------------------------------
Number: 641
Title: higher-order functors give Compiler bug: PrintVal.switch: none ...
Keywords: modules, functors, higher-order functors, printing
Submitter: Sanjiva Prasad <sanjiva@ecrc.de>
Date: 9/16/92
Version: 0.88
Severity: major
Problem: 
  Use of higher-order functors results in Compiler bug when a value
  of a datatype is printed.
Transcript: 
- signature SIG1 = sig type t	type u	val x:t	   val y:u end;
signature SIG1 = 
  sig
    type t
    type u
    val x : t
    val y : u
  end
- structure A:SIG1 = struct type t=int	type u=bool	val x=5    val y=true end;
structure A : SIG1
- 
- signature SIG2 = sig 
=                       functor Foo(X:SIG1) : sig val  z : A.t val  w: X.t end 
=                  end;

(* This was to test if the restriction on what names may be used -- relevant 
   for separate compilation -- was enforced in v88 *)

signature SIG2 = 
  sig
    functor Foo : <sig>
  end

- structure B : SIG2 = struct functor Foo(X:SIG1) = struct val z = A.x + 1 val w = X.x 
=                                                          type foo = bool 
=                                                   end
=                      end;
structure B : SIG2

(* This was to test if signature contraints of SIG2 were propagated down to the body
   of the functor. Pleasantly, it is *)

- open B;
open B

- structure C = Foo(A);
structure C : 
  sig
    val z : A.t
    val w : A.t
  end

- structure D :SIG1 = struct type t = bool type u = int val x = false val y = 7 end;
structure D : SIG1

- structure E = Foo(D);
structure E : 
  sig
    val z : A.t
    val w : D.t
  end

- C.w;
val it = 1 : A.t	(* should have been equal to A.x = 5  !!!!! *)

- A.x;
val it = 5 : A.t

- C.z;
val it = 6 : A.t	(* rightly so *)

- E.z;
val it = 6 : A.t	(* again rightly so *)

- E.w;			(* should have been false *)
val it = Error: Compiler bug: PrintVal.switch: none of the datacons matched

Status: fixed in 0.89
----------------------------------------------------------------------
Number: 642
Title: Sourcegroup 2.1 dependency analysis fails (see also bug 649)
Keywords: Sourcegroup
Submitter:      Amy Felty, felty@research.att.com
Date:		9/17/92
Version:        0.90a
System:         sun4 sparc
Severity:       major

Problem:        SG2.1 compiles, but doesn't execute propery. The last
version that I know of where it works properly is 0.87. In a call to
SourceGroup.make, one of the arguments is the name of the top-level
functor (ElpSymtab in this example). It should then be able to
determine all the necessary files to compile and build the structures.
Instead, it replies with:

% structure ElpSymtab undefined

Code:           I have put a tar file in ~felty/lp-sml/SGbug.tar. It
is not very large, but contains files in several subdirectories. (It
is a very small piece of the Lambda Prolog code.)

Transcript:     I'm including a transcript of the execution in 0.90a
with the bug, followed by a transcript of the working version in 0.87.

------------------------
transcript for SML 0.90a
------------------------
% /usr/local/sml/bin/sparc/sml-sg.90a
Standard ML of New Jersey, Version 0.90a September 16, 1992
  with SourceGroup 2.1 built on Wed Sep 16 20:11:34 EDT 1992
val it = () : unit
- use "build.sml";
val it = () : unit
val it = () : unit
val it = () : unit
structure SG : SOURCEGROUP
structure SA : SOURCEACTION
structure FL : FILELIST
val smlFiles = fn : string list -> string list
val mlyaccFiles = fn : string list -> string list
hash/Hash.sig
hash/Hash.sml
hash/link-hash.sml
val hashGroup = 1 : ?.group
sys/hasher.sml
sys/link-sys.sml
sys/location.sml
sys/profile.sml
sys/sys.sig
sys/sys_newjersey.fun
sys/time.sml
val sysGroup = 3 : ?.group
val libraries = [1,3] : ?.group list
[closing group-libraries.sml]
val it = () : unit
lam/basic.fun
lam/basic.sig
lam/term.fun
lam/term.sig
lam/naming.fun
lam/naming.sig
val lamGroup = 5 : ?.group
elp/elp_symtabs.fun
elp/elp_symtabs.sig
elp/link-elp.sml
val elpGroup = 7 : ?.group
val makeElp = fn : unit -> unit
[closing group.sml]
val it = () : unit
val make = fn : unit -> unit
% structure ElpSymtab undefined
val it = () : unit
[closing build.sml]
val it = () : unit
-----------------------
transcript for SML 0.87
-----------------------
% /usr/local/sml/bin/sparc/sml-sg
Standard ML of New Jersey, Version 0.87, July 31, 1992
  with SourceGroup 2.1 built on Mon Aug  3 14:02:28 EDT 1992
val it = () : unit
- use "build.sml";
val it = () : unit
val it = () : unit
val it = () : unit
structure SG : SOURCEGROUP
structure SA : SOURCEACTION
structure FL : FILELIST
val smlFiles = fn : string list -> string list
val mlyaccFiles = fn : string list -> string list
hash/Hash.sig
hash/Hash.sml
hash/link-hash.sml
val hashGroup = 1 : ?.group
sys/hasher.sml
sys/link-sys.sml
sys/location.sml
sys/profile.sml
sys/sys.sig
sys/sys_newjersey.fun
sys/time.sml
val sysGroup = 3 : ?.group
val libraries = [1,3] : ?.group list
[closing group-libraries.sml]
val it = () : unit
lam/basic.fun
lam/basic.sig
lam/term.fun
lam/term.sig
lam/naming.fun
lam/naming.sig
val lamGroup = 5 : ?.group
elp/elp_symtabs.fun
elp/elp_symtabs.sig
elp/link-elp.sml
val elpGroup = 7 : ?.group
val makeElp = fn : unit -> unit
[closing group.sml]
val it = () : unit
val make = fn : unit -> unit
[reading sys/time.sml]
[closing sys/time.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/time.sml.bin]
signature TIME
<other binding>
functor Time
<other binding>
[reading sys/sys.sig]
[closing sys/sys.sig]
[writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/sys.sig.bin]
signature SYS
<other binding>
[reading sys/sys_newjersey.fun]
[closing sys/sys_newjersey.fun]
[writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/sys_newjersey.fun.bin]
functor NewJersey
<other binding>
[reading sys/location.sml]
[closing sys/location.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/location.sml.bin]
signature LOCATION
<other binding>
functor Location
<other binding>
[reading sys/hasher.sml]
[closing sys/hasher.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/hasher.sml.bin]
functor Hasher
<other binding>
signature HASHER
<other binding>
[reading sys/link-sys.sml]
[closing sys/link-sys.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/link-sys.sml.bin]
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
[reading lam/term.sig]
[closing lam/term.sig]
[writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/term.sig.bin]
signature TERM
<other binding>
[reading lam/term.fun]
[closing lam/term.fun]
[writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/term.fun.bin]
functor Term
<other binding>
[reading lam/naming.sig]
[closing lam/naming.sig]
[writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/naming.sig.bin]
signature NAMING
<other binding>
[reading lam/basic.sig]
[closing lam/basic.sig]
[writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/basic.sig.bin]
signature BASIC
<other binding>
[reading lam/naming.fun]
[closing lam/naming.fun]
[writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/naming.fun.bin]
functor Naming
<other binding>
[reading lam/basic.fun]
[closing lam/basic.fun]
[writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/basic.fun.bin]
functor Basic
<other binding>
[reading hash/Hash.sig]
[closing hash/Hash.sig]
[writing /shadow/12/people/felty/lp-sml/SGtest/hash/.@sys/Hash.sig.bin]
signature HASH
<other binding>
[reading hash/Hash.sml]
[closing hash/Hash.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/hash/.@sys/Hash.sml.bin]
functor HashFun
<other binding>
[reading hash/link-hash.sml]
[closing hash/link-hash.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/hash/.@sys/link-hash.sml.bin]
<other binding>
<other binding>
[reading elp/elp_symtabs.sig]
[closing elp/elp_symtabs.sig]
[writing /shadow/12/people/felty/lp-sml/SGtest/elp/.@sys/elp_symtabs.sig.bin]
signature ELPSYMTAB
<other binding>
[reading elp/elp_symtabs.fun]
[closing elp/elp_symtabs.fun]
[writing /shadow/12/people/felty/lp-sml/SGtest/elp/.@sys/elp_symtabs.fun.bin]
functor ElpSymtab
<other binding>
[reading elp/link-elp.sml]
[closing elp/link-elp.sml]
[writing /shadow/12/people/felty/lp-sml/SGtest/elp/.@sys/link-elp.sml.bin]
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
<other binding>
val it = () : unit
[closing build.sml]
val it = () : unit

Comments:	Lal and John suggest that a regression test be made
		for source groups.
Status: fixed in 0.91 (Shao)
----------------------------------------------------------------------
Number: 643
Title: building smld produces Compiler bug: DebugError: ...
Keywords: debugger, building
Submitter:	John Reppy (jhr@research.att.com)
Date: 		9/17/92
Version: 	0.89
System: 	n.a.
Severity: 	major
Problem: 	attempting to build smld produces an error
Code: 
  makeml -debug -sun4 sunos
Transcript: 
  makeml> (cd runtime; make clean)
  rm -f *.o lint.out prim.s linkdata allmo.s run
  makeml> rm -f mo
  makeml> ln -s ../mo.sparc mo
  ...
  [closing dbguser/hstore.sml]
  val it = () : unit
  val it = () : unit
  [debugging support included]
  structure DebugList : LIST
  [closing dbguser/list.sml]
  val it = () : unit
  Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking

  [closing dbguser/general.sml]
  [closing dbguser/load.sml]

Comments:
  This works in version 0.88.

Comments: [APT]
  I looked in and looked at this briefly.  I suspect some complication
  due to the introduction of type options in the absyn.
  The correct way to diagnose this sort of problem is:

  1) use makeml -debug0 to build a debugger version that doesn't attempt
  to execute dbguser/load.sml.

  2) execute dbguser/load.sml up to the file that causes problems.

  3) Set System.Control.debugging := true.  Under the debugger, this will
  cause the absyn of the pre- and post-instrumented versions of the code to
  be printed.  

  4) Try using "dbguser/general.sml" (in this case) and look where the MARKexps
  come in the absyn.  Compare this to what the code in debug/static.sml
  (where the exception was raised) is expecting.

  If you don't get anywhere with this, please leave the result of step 1
  around in 89/bin/mipsb (I usually call it smld0) and let me know; I'll try
  diagnosing from here.  Unfortunately, my machine is not up yet here, and
  telneting cross country is painfully slow...  I should have a proper environment
  for looking at this sort of bug by early next week.

Status: obsolete
----------------------------------------------------------------------
Number: 644
Title: checking for stale continuations
Keywords: continuations
Submitter: MacQueen
Date: 9/17/92
Version: 0.89
Severity: major
Problem: 
  Checking for stale continuation returns at top level has been disabled
  (possibly by one of Tolmach's changes to interact).
Comments: See bug 145.
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 645
Title: Compiler bug from bugs 183,228,343 code: CoreInfo.coreLty3
Keywords: CoreInfo
Submitter: Lal George
Date: 9/18/92
Version: 0.90
System: Sparc, SunOS
Severity: major
Problem: 
  Code for bugs 183, 228, 343 now causes "Error: Compiler bug: CoreInfo.coreLty3".
Code: /usr/local/sml/testing/bugs/tests/bug183.sml, etc.
Status: fixed in 0.91 (Shao)
----------------------------------------------------------------------
Number: 646
Title: module test file mod14.sml fails with Compiler bug: ModuleUtil: getFctStamp
Keywords: modules, functors, higher-order functors
Submitter: Lal George (regression testing)
Date: 9/18/92
Version: 0.90a (& 0.89)
Severity: major
Problem: 
  Module test case mod14.sml in /usr/local/sml/testing/hof/tests/mod14.sml
  fails with "Compiler bug: ModuleUtil: getFctStamp".
Status: fixed in 0.90
----------------------------------------------------------------------
Number: 647
Title: PWR_2_CALLEESAVE not defined in some cases
Keywords: code generation, registers, callee-saves
Submitter:      Kjeld H. Mortensen (kjeld@metasoft.com)
Date:           9/22/92
Version:        0.89
System:         HP9000s400 HPUX8.0
Severity:       minor
Problem:        PWR_2_CALLEESAVE not defined in some cases, which shows
                up when assembling prim.s.
Code:           PWR_2_CALLEESAVE will not be defined when CALLEESAVE
                is already defined. This happens when HPUX (and M68) is 
                defined, because makeml has a special case for this and ends
                up calling cpp with -DCALLEESAVE=...
Transcript:     
Comments:
Fix:            If CALLEESAVE, HPUX, and M68 is defined then PWR_2_CALLEESAVE
                should be set to 1 because CALLEESAVE has the default value 0.
                I don't know if there are other cases (e.g. if -callee 
                is used with makeml).
Status: obsolete
----------------------------------------------------------------------
Number: 648
Title: Compiler core dumps in the boot process for HP9000s400 HPUX8.0
Keywords: hppa
Submitter:      Kjeld H. Mortensen (kjeld@metasoft.com)
Date:           9/22/92
Version:        0.89
System:         HP9000s400 HPUX8.0
Severity:       critical
Problem:        Compiler core dumps in the boot process
Code:           
Transcript:     Both 'makeml -m68 hpux8 -noshare' and 'makeml -m68 hpux8'
                results in a core dump ("Illegal instruction" or 
                "Memory fault").

neptune 65: makeml -m68 hpux8 -noshare
makeml> (cd runtime; make clean)
	rm -f *.o lint.out prim.s linkdata allmo.s run
makeml> rm -f mo
makeml> ln -s ../mo.m68 mo
makeml> (cd runtime; rm -f run allmo.o allmo.s)
makeml> (cd runtime; ...)
makeml>   /lib/cpp -DCALLEESAVE=0 -DM68 -DHPUX -DASM M68.prim.s > prim.s
makeml>   emacs -batch -l sun2hp.el prim.s prim.s
Wrote /d1/release/tools/njsml/work89/src/runtime/prim.s
makeml>   as -o prim.o prim.s
makeml> (cd runtime; make  MACHINE=M68 'DEFS= -DHPUX' CPP=/lib/cpp 'CFL=-Wl,-a,archive' 'AS=as' 'LIBS=')
	cc -O -Wl,-a,archive -DM68 -DHPUX -c run.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c run_ml.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c callgc.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c gc.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c export.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c timers.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c ml_objects.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c cfuns.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c cstruct.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c signal.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c exncode.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c malloc.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c mp.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c sync.c
	cc -O -Wl,-a,archive -DM68 -DHPUX -c allmo.c
"allmo.c", line 15: warning: incorrect combination of pointer and integer for operator '='
	cc -O -Wl,-a,archive -DM68 -DHPUX -o run run.o run_ml.o callgc.o gc.o export.o timers.o  ml_objects.o cfuns.o cstruct.o signal.o exncode.o malloc.o  mp.o sync.o prim.o allmo.o 
makeml> echo ( exportML "sml"; output(std_out,System.version); output(std_out,(chr 10)); output(std_out, "")); | runtime/run -m 8192 -r 5 -h 2048 IntM68

[Increasing heap to 2048k]
[Loading mo/CoreFunc.mo]
[Executing mo/CoreFunc.mo]
[Loading mo/Initial.mo]
...
[Loading ArrayExt]
[Executing ArrayExt]
[Executing TypesUtil]
[Loading Sort]
makeml: 988 Illegal instruction - core dumped
neptune 66: 

Comments: The compiler boots fine on a Sun3, so it doesn't have to be
          an MC680x0 related problem.
Comments: [Kjeld]
I have an additional comment: if -g is turned on in runtime/Makefile
(i.e. all the runtime sources are compiled with -g and without -O),
SML/NJ will boot. BUT, the compiler is flaky. It dumps a core if
large integers are evaluated, and it yields compiler bug messages
now and then in code that was compiled successfully on previous
versions.

Let me know if I can be of any help.  I'm not sure what the right
way is for debugging this.

**** From Kjeld H. Mortensen, 11/22/92, version 0.92:
I have tried to build the compiler on our HP9000s400. In order to get to
the boot point I had to make the following modifications:

-------------------------
diff cfuns.c.orig cfuns.c     (because the gethostid call isn't known)
-------------------------
30a31,33
> #ifdef HPUX
> #include <sys/utsname.h>
> #endif
1432a1436,1446
> #ifdef HPUX
>     char        buf[SNLEN+1];
>     ML_val_t    name;
>     struct utsname utsname;
>
>     uname(&utsname);
>     bcopy ((char *)(utsname.idnumber), buf, SNLEN);
>     buf[SNLEN] = '\0';  /* insure null termination */
>     name = ML_alloc_string (msp, buf);
>     RETURN(msp, name);
> #else /* !HPUX */
1442c1456
<
---
> #endif /* HPUX */

-----------------------------
diff sun2hp.el.orig sun2hp.el   (see also 564 in the masterbugs list)
-----------------------------
97,98c98
<       (goto-char point)
<       (beginning-of-line)
---
>       (goto-char (- point 2))
137a138
>   (replace-re "\\.word" "short")

The last change (converting .word to short) is new, and is thus not
mentioned
in 564.

These changes allowed me to get to the boot point (i.e. all C-sources could
be compiled). But then the compiler dumped a core. So, I have the following
bug report:

===========================================
Submitter:      Kjeld H. Mortensen (kjeld@metasoft.com)
>Date:           11/22/92
Version:        0.92
System:         HP9000s400 (M68k), HPUX 8.0
Severity:       Major
Problem:        Compiler fails to boot.
Code:           
Transcript:     
neptune 180: makeml -m68 hpux8 -noshare
makeml> (cd runtime; make clean)
        rm -f *.o lint.out prim.s linkdata allmo.s run
makeml> rm -f mo
makeml> ln -s ../mo.m68 mo
makeml> (cd runtime; rm -f run allmo.o allmo.s)
makeml> (cd runtime; ...)
makeml>   /lib/cpp -DCALLEESAVE=0 -DM68 -DHPUX -DASM M68.prim.s > prim.s
makeml>   emacs -batch -l sun2hp.el prim.s prim.s
Wrote /d1/release/tools/njsml/work92/src/runtime/prim.s
makeml>   as -o prim.o prim.s
makeml> (cd runtime; make  MACHINE=M68 'DEFS= -DHPUX' CPP=/lib/cpp 
'CFL=-Wl,-a,archive' 'LDFLAGS=' 'AS=as' 'LIBS=')
        cc -O -Wl,-a,archive -DM68 -DHPUX -c run.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c run_ml.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c callgc.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c gc.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c export.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c timers.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c ml_objects.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c cfuns.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c cstruct.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c signal.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c exncode.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c malloc.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c mp.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c sync.c
        cc -O -Wl,-a,archive -DM68 -DHPUX -c allmo.c
        cc -O -Wl,-a,archive -DM68 -DHPUX  -o run run.o run_ml.o callgc.o
gc.o
export.o timers.o  ml_objects.o cfuns.o cstruct.o signal.o exncode.o
malloc.o 
mp.o sync.o prim.o allmo.o
makeml> echo ( exportML "sml"; output(std_out,System.version);
output(std_out,(chr 10)); output(std_out, "")); | runtime/run -m 8192 -r 5 
-h 2048 IntM68

[Increasing heap to 2048k]
[Loading mo/CoreFunc.mo]
[Executing mo/CoreFunc.mo]
[Loading mo/Initial.mo]
[Executing mo/Initial.mo]
Initial done
[Loading mo/Loader.mo]
[Executing mo/Loader.mo]
makeml: 3591 Memory fault - core dumped

Comments:
  - I have been succesful building the compiler without '-noshare', 
    but sometimes it gives a bus error when it gets to "Go for it". 

  - The version that was successfully build with 'makeml -m68 hpux8' dumps 
    a core when evaluating an integer that is too large:
        neptune 205: sml
        Standard ML of New Jersey, Version 0.92, November 18, 1992
        val it = () : unit
        - 536870911;  (* 2^29 - 1 *)
        val it = 536870911 : int
        - 536870912;  (* 2^29 *)
        Illegal instruction (core dumped)

  - This is probably the same problem as in 648 (masterbugs).

  - The system builds fine on our Sun3 (also M68k) and doesn't core dump on
    large integers.

Status: obsolete
----------------------------------------------------------------------
Number: 649
Title: too strong optimization of datatype constructor (same as 642)
Keywords: types, datatypes, representation
Submitter: Pierre Cregut
Date: 9/22/92
Version: 0.89
Severity: critical
Problem: 
  Printing simple datatype value causes "Compiler bug: constant datacon in
  decon".
Code: 
  datatype dt = a of int | b of unit; (* a is necessary *)
  b ();
Transcript: 
  datatype  dt
  con a : int -> dt
  con b : unit -> dt
  val it = b Error: Compiler bug: constant datacon in decon

  Another version is that a piece of code is not executed
  if it is an argument of such a constructor.
  ----------------------------------------------------
  - (b (print "aa\n") ; ());
  val it = () : unit
Comment:
  That is what happened in sourcegroup.
  To make connections, sourcegroup parse the file
  The toplevel rule is of type unit so a constructor
  " interdec of unit " is associated (interdec is the
  name of the rule). 
  Because of the too strong optimization, the body
  of the rule that updates the tables by side
  effect is never executed, so source group never hears
  about the structures contained in the files it looks at.
Status: fixed in 0.91 (Shao)
----------------------------------------------------------------------
Number: 650
Title: Real.realfloor has wrong type
Keywords: floats, realfloor
Submitter: John Reppy
Date: 9/27/92
Version: 0.90
Severity: minor
Problem: 
  Isn't realfloor supposed to have type real -> real?
Transcript: 
  Standard ML of New Jersey, Version 0.90 September 22, 1992
  val it = () : unit
  - Real.realfloor;
  val it = fn : 'a -> 'b
Fix: obvious
Status: fixed in 0.91 
----------------------------------------------------------------------
Number: 651
Title: System.Directory.cd fails on numbers as directory names
Keywords: System, directory
Submitter: Konrad Slind
Date: 9/28/92
Version: 0.90
System: MIPS/RISCos 4.52
Severity: major
Problem: 
  System.Directory.cd doesn't seem to recognize numbers as possible directory
  names:
Transcript: 
  $ mkdir 7
  $ sml
  Standard ML of New Jersey, Version 0.90 September 22, 1992
  val it = () : unit
  - System.Directory.cd "7";

  uncaught exception NotDirectory
  -
Status: fixed in 0.91
----------------------------------------------------------------------
Number: 652
Title: Compiler bug: contmap enterv 123 building HOL
Keywords: contmap
Submitter:      elsa  elsa@research.att.com
Date:		9/27/92
Version:        90, 91a
System:         MIPS & SPARC, UNIX
Severity:       critical
Problem:        compiler quits with Compiler bug: contmap enterv 123
Comment: [Elsa Gunter, 9/29/92]
  I spent some time last night removing the HOL code from the example.
Below is a mimimal example that causes the problem.  Along my descent
I found that the process of elimination was VERY NON-monotonic.  At
some time during the elimination process I had 
     if true then 2 else 2
which could note be replaced by 2 without the bug going away.
However, after removing some other aspects, the if_then_else was no
longer necessary.  At some point, the length of the string in the
exception being handled made a difference, but now it only matters
that there is a string.  There were other fluxuations as well.  I'm
afraid I left them on my machine at home, but if you need them, I can
try to bring them in tomorrow.
  This is very possibly not the only minimal code that causes this
bug.  I found that exceptions A and B must be different, that the one
being handled needed to take a record with at least one field having
string type and that that field had have a match against a string,
i.e., not a wild-card.
Code:
(* File: bug-652.sml *)

exception A

exception B of int*string

val _ = (raise A) handle B (_,"") => 2

(* end of file *)
Transcript:

shadow% sml
Standard ML of New Jersey, Version 0.90 September 22, 1992
val it = () : unit
- use "bug-652.sml";
Error: Compiler bug: contmap enterv 123
[closing bug-652.sml]
- exception A;
exception A
- exception B of int*string;
exception B
- val _ = (raise A) handle B (_,"") => 2;
Error: Compiler bug: CoreInfo.coreLty3

Another variation of the bug, still present in 91b:
Code:
(* File: bug.sml *)`

structure C =
struct
exception A
exception B of int * string
val C = (raise A) handle B (_,"") => 2
end

Transcript:
hunny% sml
Standard ML of New Jersey, Version 0.91a, October 1, 1992
val it = () : unit
- use "bug.sml";
Error: Compiler bug: contmap enterv 123
[closing bug.sml]
-

Another variation: (from Sheard at ogi)
- exception foo;
- fun bar x = raise foo;
Error: Compiler bug: CoreInfo.coreLty3

Comments:
  This is a variation on bug 652.  If you unwrap the code from within
the structure then things work.  However it still bombs if the code is
all inside a structure.

Comments:
  Konrad says that the problem was in 88 as well.

Comments: [Zhong Shao, 10/6/92]
   The compiler bug: contmap enterv 123 has been there for a long long time.
   Though previously, it occurs as a compiler bug: MipsCM.select: bad dst.
   These  are caused by meaningless cps expressions such as
                 SELECT(INT 0,1,v,...) , APP(INT 0, ...)
   which are produced by the constant folding optimization on data constructors
   and exception constructors. A short but temporary fix is to let contmap.sml
   not check the validity of these expressions and let each target code 
   generator generate some code for SELECT(INT 0,1,v,...). Ideally this should
   be fixed by letting the SELECT in Lambda and CPS depend on the auxiliary 
   variable generated in each branch and switch statement, and controlling 
   the constant-folding on SELECT. 

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 653
Title: VECTOR signature isn't pervasive (unlike ARRAY)
Keywords: signatures, top level, pervasives
Submitter:	Cliff Krumvieda (cliff@cs.cornell.edu)
Date: 		9/30/92
Version: 	0.90
System: 	all
Severity: 	minor
Problem: 	VECTOR signature isn't pervasive (unlike ARRAY)
Code: 
Transcript: 
  Standard ML of New Jersey, Version 0.90 September 22, 1992
  val it = () : unit
  - signature A = ARRAY;
  signature A = 
    sig
      type 'a array
      exception Size
      exception Subscript
      val array : int * '1a -> '1a array
      val arrayoflist : '1a list -> '1a array
      val length : 'a array -> int
      val sub : 'a array * int -> 'a
      val tabulate : int * (int -> '1a) -> '1a array
      val update : 'a array * int * 'a -> unit
    end
  - signature V = VECTOR;
  std_in:3.15-3.20 Error: VECTOR undefined (parser)
  std_in:3.15-3.20 Error: unbound signature: VECTOR
Comments:
Fix:		add VECTOR to boot environment
Status: fixed in 0.91
----------------------------------------------------------------------
Number: 654
Title: System.Directory.cd fails on valid pathnames (same as 651)
Keywords: System, directory
Submitter:      Elsa L. Gunter, elsa@resaerch.att.com
Date:		10/1/92
Version:        90 (although I haven't tried earlier)
System:         Sparc, SunOS (although I haven't tried others)
Severity:       major
Problem:        strings from execute don't mix with System.Directory.cd
                (or not all strings are ccreated equal)

Code: The following can cause problems when loaded with use, but more
      reliably causes problems when entered interactively, or so I've
      found.

fun strip_newline (str) = substring (str, 0, size(str) - 1);

fun cwd () =
    strip_newline (input_line ((fn (x,_) => x) (execute ("/bin/pwd",[]))));

val src_dir = cwd ();
val tmp = "/base/elsa/working/hol92/hol90.v5/src";
val t = (tmp = src_dir);
val _ = System.Directory.cd src_dir;
val _ = System.Directory.cd tmp;
val _ = System.Directory.cd (src_dir ^ "/..");
val _ = System.Directory.cd src_dir;

Transcript:

tiree% sml
Standard ML of New Jersey, Version 0.90 September 22, 1992
val it = () : unit
- fun strip_newline (str) = substring (str, 0, size(str) - 1);
val strip_newline = fn : string -> string
- fun cwd () =
    strip_newline (input_line ((fn (x,_) => x) (execute ("/bin/pwd",[]))));
= val cwd = fn : unit -> string
- val src_dir = cwd ();
val src_dir = "/base/elsa/working/hol92/hol90.v5/src" : string
- val tmp = "/base/elsa/working/hol92/hol90.v5/src";
val tmp = "/base/elsa/working/hol92/hol90.v5/src" : string
- val t = (tmp = src_dir);
val t = true : bool
- val _ = System.Directory.cd src_dir;

uncaught exception NotDirectory
- val _ = System.Directory.cd tmp;
- val _ = System.Directory.cd (src_dir ^ "/..");
- val _ = System.Directory.cd src_dir;

uncaught exception NotDirectory
- 

Comments:
-- The problem is intermittent; the same code seems to behave
differently on the same machine under similar circumstances.
-- Strings that are entered by hand, or are built by sml processes,
such as concatenation seem not to cause the problem.  Only strings
created by execute (and input_line) seem to cause it.
-- I haven't been able to reproduce it just now, but it I recollect
that multiple executions of the same coomand (namely
System.Directory.cd src_dir; without src_dir being rebound in between)
could succeed for a while and then fail.

Fix: add "\000" to pathnames
Status: fixed in 0.91
----------------------------------------------------------------------
Number: 655
Title: Compiling Isabelle-92 generates a bus error
Keywords: sparc, bus error
Submitter:      Lal George
Date:		10/4/92
Version:        0.88, 0.91a (0.89, 0.90 expose the CoreLty3 bug)
System:         SPARC and MIPSEB
Severity:       critical
Problem:        Generates a bus error(coredump) during compilation.
Code:           
	
	I haven't tried to narrow the code down yet, however, at 
	Bell Labs the following is sufficient to expose the bug:

		cd /usr/local/sml/isabelle-92/92/Pure

	Under SML:

		app use ["NJ.ML","ROOT.ML"];

Transcript:

	<... lots of stuff deleted ...>

	structure Earley : PARSER
	structure TypeExt : TYPE_EXT
	structure SExtension : SEXTENSION
	structure Pretty : PRETTY
	structure Printer : PRINTER
	Bus error(coredump)

Code: [dbm, 10/10/92: following causes bus error in 91a]
  structure A = struct end;

  signature S =
  sig
    local open A in  (* this must be present *)
      val x : unit  (* must have second value beside f, either before or after *)
      val f: unit -> unit
    end
  end;

  structure B : S =  (* must be constrained by S *)
  struct
    val x = ()
    fun f() = ()
  end;

  val _ = B.f();  (* causes Bus error *)

Comment: [dbm] It's clear that the bug is called by the local spec form.

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 656
Title: Excessive dead code
Keywords: code generation, dead code
Submitter:      Lal George
Date:		10/5/92
Version:        0.90
System:         SPARC
Severity:       major
Problem:        Lot of dead code left around.
Code:           

      structure X = struct

	(* fold function "f" over the sublists of "(x::xs)" of size "n", starting
	   with value "r", and appending "p" to each sublist *)

	fun folds_onto([],_,r,p,f) = r
	  | folds_onto(x::xs,1,r,p,f) = folds_onto(xs,1,f(r,x::p),p,f) 
	  | folds_onto(x::xs,n,r,p,f) = folds_onto(xs,n,
						   folds_onto(xs,n-1,r,x::p,f),
						   p,f)

	val l = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]
	val n = 10

	fun doit() = folds_onto(l,n,0,[],fn (total,l) => total+length(l))
     end

Transcript:

	Toggling the Control.saveLvarNames, and CG.printit flags, a 
	partial output  from cpsopt is shown below: 
	(arrows point to dead code)

	...
         folds_onto12224(12238,n12239,r12240,p12241,f12242,12124) =
            if boxed(12238) [12135] then
               12238.0 -> x12136
               12238.1 -> xs12137
               if ineq((I)1,n12239) [12169] then
                  12150(12226) =
-->                  {xs12137,n12239,12226,p12241,f12242} -> 12152
                     folds_onto12224(xs12137,n12239,12226,p12241,f12242,12124)
                  -(n12239,(I)1) -> 12153
                  {x12136,p12241} -> 12154
-->               {xs12137,12153,r12240,12154,f12242} -> 12155
                  folds_onto12224(xs12137,12153,r12240,12154,f12242,12150)
               else
                  12164(12228) =
-->                  {xs12137,(I)1,12228,p12241,f12242} -> 12166
                     folds_onto12224(xs12137,(I)1,12228,p12241,f12242,12124)
                  {x12136,p12241} -> 12167
                  {r12240,12167} -> 12168
                  f12242(12168,12164)
            else
               12124(r12240)
         {(I)20,(I)0} -> 12174
         {(I)19,12174} -> 12175
         {(I)18,12175} -> 12176
	...

Comment:
	I know that several rounds of contract are done on this
	fragment, and the dead code exists after each round. For 
	some mysterious reason, code in cps/contract, that should 
	remove this, does not seem to work.

  Andrew Says:
    This is because System.Control.CG.reducemore is 15, which causes
    cpsopt to give up early when it sees diminishing returns.
    For documentation that this is a good idea, see Compiling with Continuations,
     figure 15.11, page 192.

Status: not a bug.
----------------------------------------------------------------------
Number: 657
Title: vector values not prettyprinted
Keywords: vectors, printing, top level
Date:		10/12/92
Version: 	0.91c
System: 	all
Severity: 	minor
Problem: 	new pretty printing code doesn't handle vectors
Code: 
Transcript: 

  Standard ML of New Jersey, Version 0.90 September 22, 1992
  val it = () : unit
  - #[1,2,3];
  val it = #[1,2,3] : int vector

  Standard ML of New Jersey, Version 0.91c, October 12, 1992
  val it = () : unit
  - #[1,2,3];
  val it = prim? : int vector
Status: fixed in 0.92
----------------------------------------------------------------------
Number: 658
Title: Compiler bug: PrintVal.switch: none of the datacons matched
Keywords: printing, datatypes
Submitter: John Reppy
Date: 10/13/92
Version: 0.91c
System: SPARC 2, SunOS 4.0.1
Severity: critical
Problem: 
  Compiler bug: PrintVal.switch: none of the datacons matched
  caused by Format.compileFormat
Transcript: 
  - Format.compileFormat "x = %d";
  Error: Compiler bug: PrintVal.switch: none of the datacons matched
Status: fixed in 0.91
----------------------------------------------------------------------
Number: 659
Title: uncaught exception SpillFreemap in closure profiling
Keywords: code generation, closure profiling
Submitter:      Zhong Shao 
Date:           10/12/92
Version:        from 0.86 - 0.90
System:         mips 
Severity:       minor
Problem:        uncaught exception SpillFreemap in closure profiling
Code:           
(* bug.sml *)
  structure S =
    struct
      val a = fn x => x
      val b = fn x => x
      val c = fn x => x
      val d = fn x => x
      val e = fn x => x
      val f = fn x => x
      val g = fn x => x
      val h = fn x => x
      val i = fn x => x
      val j = fn x => x
    end

Transcript:     
  haven% sml
  Standard ML of New Jersey, Version 0.90 September 22, 1992
  val it = () : unit
  - System.Control.CG.allocprof := true;
  val it = () : unit
  - use "bug.sml";
  [closing src/bug.sml]

  uncaught exception SpillFreemap
  -

Comments:
  in cps/spill.sml, the instrumenting code for profiling spill records
  are inserted at the wrong place. 
Status: fixed in 0.91
----------------------------------------------------------------------
Number: 660
Title: signals in background sml
Keywords: signals
Submitter: 	Doug McIlroy (doug@research.att.com)
Date: 		10/22/92
Version: 	0.90
System: 	all
Severity: 	major for non-interactive programs

Problem: 	the inherited signal handler state of the SML process
		is getting trashed.  This means that an SML program
		running in the background still receives signals, even
		though the shell has disabled them.

Fix:		The fix will take a bit of work, since the responsibility
		for signal handling is spread throughout the system.
		We will have to make the signal handler state (enabled,
		default, ignored) more visible at the System.Signals
		level, and the top-level loop and other initialization
		code will have to check for ignored signals when setting
		the default handlers.  (JHR)
Comment: [dbm] probably obsolete
Owner: John
Status: fixed in 109.21 [new runtime]
----------------------------------------------------------------------
Number: 661
Title: prettyprinter -- Compiler bug: PPTable.install_pp
Keywords: prettyprint
Submitter:      Lal George
Date:		10/28/92
Version:        0.91
System:         all
Severity:       minor
Problem:        install_pp incorrectly raises a compiler bug message
Code:           
	val _ = System.PrettyPrint.install_pp ["foo","bar"] Array.update
	
Transcript:

	 Error: unbound structure foo in path foo.bar
	Error: Compiler bug: PPTable.install_pp
Comments:

	The first error message is also printed with an additional 
	blank space. 
Fix:
	In file print/pptable and function install_pp, replace:
	     | _ => ErrorMsg.impossible "PPTable.install_pp"
	with
	     | _ => ErrorMsg.complain "install_pp: Malformed path"
	May as well do the same thing with fun make_path.
	[dbm] Used ErrorMsg.errorNoFile for this and make_path --
	no more calls of ErrorMsg.impossible in pptable.sml.
Status: fixed in 0.92 (dbm)
----------------------------------------------------------------------
Number: 662
Title: delayed interrupt on MIPS
Keywords: signals, mips
Submitter: Dave MacQueen
Date: 10/28/92
Version: 0.91
System: MIPS/RISCOS 4.52
Severity: minor
Problem: 
  Typing the interrupt character (e.g. ^C) doesn't interrupt sml until
  after a newline is typed.
Comments:
  This could be fixed, but the piping into sml would hang under csh.
  This is really a RISCos bug.
Status: not a bug (ours)
----------------------------------------------------------------------
Number: 663
Title: gc loop on illegal character
Keywords: garbage collection, top level
Submitter: Lal George
Date: 10/28/92
Version: 0.91
System: SPARC, MIPS
Severity: major
Problem: 
  Typing an illegal character (e.g. ^H) at top level causes an
  infinite gc loop after the illegal character message.
Fix: [Lal George]
  The fix is to generate ml.lex.sml with a version of lexgen.sml 
  that has the latest bug fixes. The one on /usr/local/sml/bin/sparc
  does fine.
Status: fixed in 0.92a
----------------------------------------------------------------------
Number: 664
Title: installing on Sony RISC NEWS
Keywords: Sony News, install
Submitter:      KONO Shinji <kono@csl.sony.co.jp>
Date:		11/4/92
Version:        0.75
System:         Sony RISC NEWS, NEWS-OS Release 4.1R
Severity:       minor
Problem:        Installation 
Code:           makeml -mips news
Transcript:     EXC_OV and cache clear system call are machine dependent
Comments:       I'm afraid this type of mahcine is not famous in U.S. But
		I'm sure it is used in Japan...
Fix:		Diffs are appended..
--------
Shinji Kono          kono@csl.sony.jp
Sony Computer Science Laboratory, Inc.


diff -c ./makeml /site/unicorn/export/src/Language/sml-0.75/src/makeml
*** ./makeml	Wed Nov  4 15:35:55 1992
--- /site/unicorn/export/src/Language/sml-0.75/src/makeml	Tue Sep  8 09:55:11 1992
***************
*** 129,135 ****
  	    ENDIAN=Big
  	    case $1 in
  		riscos) OPSYS=RISCos; CFL="$CFL -systype bsd43" ;;
- 		news)   OPSYS=BSD;;
  		mach)   OPSYS=MACH; DEFS="$DEFS -DBSD" ;;
  		*)
  		    echo "$CMD must specify opsys arg for MIPS (riscos or mach)"
--- 129,134 ----
*** runtime/MIPS.dep.c	Wed Nov  4 16:28:06 1992
--- /site/unicorn/export/src/Language/sml-0.75/src/runtime/MIPS.dep.c	Tue Sep  8 09:54:00 1992
***************
*** 5,18 ****
   * MIPS dependent code for SML/NJ runtime kernel.
   */
  
- #ifdef sony_news
- #include <machine/cpu.h>  /* for EXC_OV */
- #else
  #ifndef SGI
  #include <mips/cpu.h>  /* for EXC_OV */
  #else
  #include <sys/sbd.h>  /* for EXC_OV */
- #endif
  #endif
  #ifndef SGI
  #include <syscall.h>
--- 5,14 ----
diff -c runtime/exncode.c /site/unicorn/export/src/Language/sml-0.75/src/runtime/exncode.c
*** runtime/exncode.c	Wed Nov  4 16:27:33 1992
--- /site/unicorn/export/src/Language/sml-0.75/src/runtime/exncode.c	Tue Sep  8 09:54:03 1992
***************
*** 6,19 ****
   */
  
  #ifdef MIPS
- #ifdef sony_news
- #include <machine/cpu.h>   /* for EXC_OV */
- #else
  #ifndef SGI
  #include <mips/cpu.h>   /* for EXC_OV */
  #else
  #include <sys/sbd.h>   /* for EXC_OV */
- #endif
  #endif
  #endif
  #include <signal.h>
--- 6,15 ----
diff -c runtime/ml_os.h /site/unicorn/export/src/Language/sml-0.75/src/runtime/ml_os.h
*** runtime/ml_os.h	Wed Nov  4 16:47:12 1992
--- /site/unicorn/export/src/Language/sml-0.75/src/runtime/ml_os.h	Tue Sep  8 09:54:05 1992
***************
*** 94,106 ****
  /* cache-flushing stuff */
  
  #if defined(MIPS)
- #ifdef sony_news
- #include <machine/sysnews.h>
- #    define FlushICache(addr, size)	  \
-         sysnews(NEWS_CACHEFLUSH, addr, size, FLUSH_ICACHE)
- /* SYS_sysnews will be defined in syscall.h, in OS 4.1 */
- #undef SYS_sysnews
- #else
  #ifndef MACH
  #include <sys/sysmips.h>
  #endif
--- 94,99 ----
***************
*** 117,122 ****
--- 110,116 ----
  #    define FlushICache(addr, size)	  \
          (syscall(SYS_sysmips, MIPS_CACHEFLUSH, (addr), (size), ICACHE, 0))
  #  endif
+ #else
  #ifdef NeXT
  #  define FlushICache(addr, size)     asm ("trap #2")
  #else
***************
*** 123,129 ****
  #  define FlushICache(addr, size)
  #endif
  #endif
- #endif
  
  #if defined(MACH) && defined(MIPS)
  
--- 117,122 ----
***************
*** 139,145 ****
  #endif
  
  /* where to find syscall.h, used for getting the #define SYS_open */
! #if defined(VAX) || defined(NeXT) || defined(MORE) || defined(sony_news)
  #include <syscall.h>
  #else
  #ifndef SGI
--- 132,138 ----
  #endif
  
  /* where to find syscall.h, used for getting the #define SYS_open */
! #if defined(VAX) || defined(NeXT) || defined(MORE)
  #include <syscall.h>
  #else
  #ifndef SGI
Status: obsolete
----------------------------------------------------------------------
Number: 665
Title: Compiler bug: getSymbols on opening nonexistent structures.
Keywords: error recovery
Submitter: Pierre Cregut
Date: 11/5/92
Version: 0.91, 0.92a
Severity: minor
Problem: Compiler bug: getSymbols on opening nonexistent structures.
Transcript: 
Standard ML of New Jersey, Version 0.92a, November 2, 1992
val it = () : unit
- open A;
std_in:2.1-2.6 Error: unbound structure A
Error: Compiler bug: getSymbols
Fix: add ERROR_STR case to getSymbols function in elabstr.sml.
Status: fixed in 0.92 (dbm)
----------------------------------------------------------------------
Number: 666
Title: top-level printout on open declarations
Keywords: open, printing, top level
Submitter: John Reppy
Date: 11/6/92
Version: 0.91
Severity: minor
Problem: 
  When opening a structure, the bound datatypes don't get printed.
Transcript: 
  - structure Foo = struct datatype t = A | B val x = A end;
  structure Foo :
    sig
      datatype t
	con A : t
	con B : t
      val x : t
    end
  - open Foo;
  open Foo
  val x = A : t
  -
Comments:
  In fact, only dynamic components are printed, since only they are
  rebound in the top-level environment (to simplify stale-lvars cleanup).
Fix:
  Change printing of open declarations.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 667
Title: Compiler bug: getvars(STRdec)/fn opening a structure
Keywords: modules, functors, printing
Submitter:      Thomas Yan, tyan@cs.cornell.edu
Date:           11/10/92
Version:        0.91
Severity:       minor, but potentially very annoying
Problem:        ? pretty printing a structure created by functor application ?
Code:           functor A(type aa) = struct type a = aa list val a =[] end
                structure A = A(type aa = int)
                open A
Transcript:     Error: Compiler bug: getvars(STRdec)/fn
Fix: ignore special name "<Argument>" in elabDecl/makeDecl.
Status: fixed in 0.92 (dbm)
-----------------------------------------------------------------------
Number: 668
Title: missing info in syntax error messages
Keywords: error messages, syntax, parsing
Submitter: Lal George
Date: 11/13/92
Version: 0.92c
Severity: major
Problem: 
  Some information has been lost from syntax error messages.
Transcript: (bug103.sml)
  {999}

  -----------------------diff new old ----------------------
  diff tsml.tmp /usr/local/sml/testing/bugs/outputs/bug103.out
  2,3c2
  < std_in:8.5 Error: syntax error
  < 
  ---
  > std_in:8.5 Error: syntax error found at RBRACE
Comments:
  The "found at" part of the message is missing from the new mlyacc/base.sml
  supplied by Tarditi.
Fix:
  This was a non-error-correcting version of base.sml that was inadvertently
  left in the mlyacc directory sent by Tarditi.  The fix was to build and 
  install the error-correcting version of base.sml.
Status: fixed in 0.92c
----------------------------------------------------------------------
Number: 669
Title: redundant rule added in some matches
Keywords: matches
Submitter: Dave MacQueen
Date: 11/16/92
Version: 0.92c
Severity: major
Problem: 
  A rule is added to raise the match exception (and save a location
  message) in cases where it is redundant.

Code: 
Transcript: 
  - fun f(s,w) = f s w;
  std_in:0.0-0.0 Error: pattern and expression in val rec dec don't agree (circularity)
    pattern:    'Z -> 'Y -> 'X
    expression: 'Z * 'Y -> 'X
    in declaration:
      f =
	(fn (s,w) => <exp> <exp> w
	 | _ => (<exp> := <exp>; raise <exp>))   <==== redundent rule
Fix:	 
  Caused by switch to prettyprinter for absyn.  Left out call of trim
  to trim last default rule when printing match in CASEexp and FNexp.
Status: fixed in 0.92 (dbm)
----------------------------------------------------------------------
Number: 670
Title: missing indicators in redundant match warning messages
Keywords: matches, error messages
Submitter: Dave MacQueen
Date: 11/16/92
Version: 0.88 through 0.92c
Severity: major
Problem: 
  In version 0.87 and earlier an arrow "-->" was printed in front of
  redundant rules in the warning message for redundant matches.
Code: (in file bug670.sml)
  fun f (true,x) = 0
    | f (true,nil) = 1
    | f (false, x) = 2
    | f w = 3;
Transcript: 
  Standard ML of New Jersey, Version 0.87, July 31, 1992
  val it = () : unit
  - use "bug670.sml";
  bug670.sml:1.1-4.11 Warning: redundant patterns in match
	  (true,x) => ...
    -->   (true,nil) => ...
	  (false,x) => ...
    -->   w => ...
  val f = fn : bool * 'a list -> int

  Standard ML of New Jersey, Version 0.92b, November 11, 1992
  val it = () : unit
  - use "bug670.sml";
  [opening bug670.sml]
  bug670.sml:1.1-4.11 Warning: redundant patterns in match
	    (true,x) => ...
	    (true,nil) => ...
	    (false,x) => ...
	    w => ...

  val f = fn : bool * 'a list -> int
Comments:
  I think that 0.88 was the version that incorporated Bill Aitken's
  rewrite of the match compiler, so it is probably caused by that
  change.
Fix: added a rev around call of fixupUnused in doMatchCompile in
     translate/mc.sml.  fixupUnused was returning a list of ints
     sorted in the wrong order.
Status: fixed in 0.92 (dbm)
----------------------------------------------------------------------
Number: 671
Title: visibility of parameter in functor signature
Keywords: modules, functors, scope
Submitter:    Zhong Shao   (zsh@cs.princeton.edu)
Date:         11/17/92
Version:      0.91
System:       all 
Severity:     major
Problem:      unbound structure in functor signature definitions
Code:
(* case 1 *)
 funsig FSIG(B : sig type t end) = sig val f : B.t end

(* case 2 *)
 funsig FSIG(structure B : sig type t end) = sig val f : B.t end

(* case 3 *)
 funsig FSIG(B : sig type t end) = sig val f : t end

(* case 4 *)
 funsig FSIG(structure B : sig type t end) = sig val f : t end

Transcript:

 haven% sml
 Standard ML of New Jersey, Version 0.91, October 26, 1992
 val it = () : unit
 -  funsig FSIG(B : sig type t end) = sig val f : B.t end;
 std_in:2.47-2.49 Error: unbound structure B in path B.t

 -  funsig FSIG(structure B : sig type t end) = sig val f : B.t end;
 std_in:0.0-0.0 Error: unbound structure B in path B.t

 -  funsig FSIG(B : sig type t end) = sig val f : t end;
 funsig FSIG(B:<sig>) = sig val f : <Argument>.<Parameter>.t end

 -  funsig FSIG(structure B : sig type t end) = sig val f : t end;
 std_in:2.57 Error: unbound type constructor t

Comments:  

 The code for case 1 and 2 should be valid, as they are in 89. 
 The code for case 3 and 4 should be rejected (intuitively) 

Fix:
  Here is the fix for the bug in signatures of functors:
  tulipe-cregut->diff elabsig.sml elabsig.sml~
  539,540c539,540
  <           of (NONE,_) => Normalize.openX(name_X,sgnArg,symtotalParent)
  <            | (SOME _ ,_) => 
  ---
  >           of (SOME _,_) => Normalize.openX(name_X,sgnArg,symtotalParent)
  >            | (NONE,_) => 
  It is just a stupid inversion...
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 672
Title: start() in i386 Mach
Keywords: x86
Submitter:      Mark Leone (mleone@cs.cmu.edu)
Date:		11/18/92
Version:        0.91
System:         i386 Mach
Severity:       minor
Problem:        start() is now _start() in i386 Mach.
Comments:	I386.prim.s used to require an #ifdef for Mach to set startptr 
		to start(), not _start().  This is no longer necessary.
Fix:
*** I386.prim.s.orig    Wed Nov 18 13:25:23 1992
--- I386.prim.s Wed Nov 18 13:24:13 1992
***************
*** 651,658 ****
  /* this bogosity is for export.c */
        .globl  _startptr
  _startptr: 
- #if defined(I386) && defined(MACH)
-       .long   _start
- #else
        .long   start
- #endif
--- 651,654 ----
Status: fixed in 0.92
----------------------------------------------------------------------
Number: 673
Title: failure of type propagation with higher-order functors
Keywords: modules, functors, higher-order functors
Submitter: Dave MacQueen
Date: 11/20/92
Version: 0.92
Severity: major
Problem: 
  Type information is not propagated through application of
  a parameter functor.
Code:  (bug673.sml)
  signature MONOID = 
  sig
    type t
    val plus: t*t -> t
    val e: t
  end;

  (* functor signature declaration *)
  funsig PROD (structure M: MONOID
	       structure N: MONOID) = MONOID

  functor Square(structure X: MONOID
		 functor Prod: PROD): MONOID =
      Prod(structure M = X
	   structure N = X);

  functor Prod(structure M: MONOID
	       structure N: MONOID): MONOID =
  struct
    type t = M.t * N.t
    val e = (M.e, N.e)
    fun plus((m1,n1),(m2,n2))=(M.plus(m1,m2),N.plus(n1,n2))
  end;

  structure Int =
  struct
    type t = int
    val e = 0
    val plus = (op +): int*int -> int
  end;

  structure Int2 = Square(
    structure X = Int
    functor Prod = Prod);

  #1(Int2.e);
Transcript:
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - use "bug673.sml";
  [opening bug673.sml]
  signature MONOID =
    sig
      type t
      val plus : t * t -> t
      val e : t
    end
  funsig PROD(<Parameter>:<sig>) =
    sig
      type t
      val plus : t * t -> t
      val e : t
    end
  functor Square : <sig>
  functor Prod : <sig>
  structure Int :
    sig
      eqtype t
      val e : int
      val plus : int * int -> int
    end
  structure Int2 : MONOID
  bug673.sml:39.1-39.10 Error: operator and operand don't agree (type mismatch)
    operator domain: {1:'Y, '...Z}
    operand:         Int2.t
    in expression:
      (fn {1=1,...} => 1) (e)
  [closing bug673.sml]
  - 
Fix: [Cregut]
  diff elaborate/elabstr.sml elaborate/elabstr.sml~
  525,528c525,528
  < 		 fun computeSelf (StructStr _) = true
  < 		   | computeSelf (MarkStr(def,_,_)) = computeSelf def
  < 		   | computeSelf _ = false
  < 		 val self = computeSelf def
  ---
  > 		 val self = 
  > 		  (case def of VarStr _ => false 
  > 		             | MarkStr(VarStr _,_,_) => false
  > 			     | _ => true)

  Ok I think it fixes the problem: match thought that it could suppress its
  origin whereas it was a computed application to be done at each functor
  application. In the bogus version you could correct the problem 
  - by suppressing the signature MONOID
  - by putting an intermediate level of structure so that the optimisation
  of self was irrelevant (which is a kind of bug but we have already talked
  about it)
  (an intermediate level = functor Square(,,,) = struct structure result =
  Prod(...) end; )

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 674
Title: System.Env.filterEnv raises exception IntmapF
Keywords: environment, filterEnv
Submitter: Dave MacQueen
Date: 11/22/92
Version: 0.92
Severity: major
Problem: 
  System.Env.filterEnv raises exception IntmapF.
Transcript: 
- System.Env.filterEnv(!System.Env.pervasiveEnvRef,[System.Symbol.valSymbol "hd"]);

uncaught exception IntmapF
Comments: Probably related to bug 640.
Fix: fix lvarOfBinding in modules/moduleutil.sml
Status: fixed in 0.93a (dbm)
----------------------------------------------------------------------
Number: 675
Title: prettyprinter doesn't sense System.Print.linewidth
Keywords: printing, prettyprint
Submitter: Konrad Slind
Date: 11/23/92
Version: 0.92
Severity: major
Problem: 
  System.Print.linewidth doesn't seem to control the linewidth used by the
system prettyprinter. 
Transcript: 
  $ sml
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - System.Print.printLength := 10000;
  val it = () : unit
  - val L = ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa"];
  val L =
    ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd",
     "afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa",
     "adsfasd","afasdfa","adsfasd","afasdfa"] : string list
  - System.Print.linewidth := 20;
  val it = () : unit
  - L;
  val it =
    ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd",
     "afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa",
     "adsfasd","afasdfa","adsfasd","afasdfa"] : string list
  - System.Print.linewidth := 150;
  val it = () : unit
  - L;
  val it =
    ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd",
     "afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa",
     "adsfasd","afasdfa","adsfasd","afasdfa"] : string list
  - 
Comment [Slind, 7/20/93]
  Last fall, I reported a bug in System.Print.linewidth, namely that the
system prettyprinter wouldn't track changes to this variable. It seems
to be a bug arising out of bootstrapping. Now, I haven't found the bug,
but I do have a bit more information about it: changes to this variable
do get tracked in the environment used by "use_stream".

Example.

- val eval_string = System.Compile.use_stream o open_string;
val it = fn : string -> unit

- System.Print.linewidth;
val it = ref 79 : int ref

- System.Print.linewidth := 30;
val it = () : unit

(* Std. top level environment, value of "linewidth" ignored. *)
- [12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12];
val it = [12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12]
  : int list

(* Change gets tracked. *)
- eval_string "[12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12]";
val it =
  [12,12,12,12,12,12,12,12,12,
   12,12,12,12,12,12,12,12,12,
   12,12] : int list
val it = () : unit

Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 676
Title: Out of order record field evaluation.
Keywords: records, evaluation
Submitter: Andrew Appel
Date: 11/24/92
Version: 0.92
Severity: Critical
Problem: 
  Out of order record field evaluation.
Transcript: 
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - val r = ref 0;
  val r = ref 0 : int ref
  - fun g() = (inc r; !r);
  val g = fn : unit -> int
  - {last=g(),first=g()};
  val it = {first=1,last=2} : {first:int, last:int}
Status: fixed in 0.93 (Zhong Shao)
----------------------------------------------------------------------
Number: 677
Title: memory leak
Keywords: space leak
Submitter:      Kjeld H. Mortensen (kjeld@metasoft.com)
Date:           11/24/92
Version:        0.92
Systems:        Sparc server 330, SunOS 4.1.1,
                HP9000s400, HPUX 8.0
Severity:       Major
Problem:        Memory leaks (heap grown when not supposed to).
Code:           
Transcript:    
Comments:
I have made experiments with SML/NJ v0.92 in order to see if there were
any memory leaks. It seems to me that it is the case.

My standard experiment is the same as from bug report #500, which was fixed
by v0.82. The bug was present in v0.75 and now in v0.92, but not to the 
same degree. I've included a bug report in case you think it should be
added to the masterbugs list. 

It is very important for us that the compiler doesn't slow down over a
longer period of usage, as a result of memory leaks. So I've given the
bug a high priority.

Using the compiler over a long period of time where stuff is only evaluated
or values "overwritten", the heap size increases unnecessarely (see also
bug #500).


(v0.92)  ----------Mem Size----------    
          start      end    end-start  ratio  softmax   slow down
 Sparc   19968 kb  21096 kb  1128 kb     3      28 Mb     26 %
 HPs400  11224 kb  11900 kb   676 kb     3      32 Mb     16 %

The table shows memory usage (as show by 'ps') at the beginning and end
of the experiment, the difference between end and start, ratio and softmax
(from System.Control.Runtime), and how much slower the compiler is at
the end as compared with the beginning of the experiment. The session lasts
45 and 60 minutes for the HP and Sparc respectively.

I want to point out that the earlier version 0.82 doesn't have any
detectable memory leak and therefore no slow down.
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 678
Title: emacs tags broken
Keywords: emacs
Submitter:      Charlie Krasic (cckrasic@plg.uwaterloo.ca)
Date:           11/24/92
Version:        0.92
System:         Sun 670/MP (Sparc) w/SunOS 4.3 (?)
Severity:       minor
Problem:        emacs tags broken when trying to create TAGS file for SML/NJ
Code:           modified the file 'all' to contain directives to toggle
                indexing and markabsyn, then run smlc < all, then run
                sml-tags -r.  I tried both my old version of sml-tags and
                a newly built version of sml-tags.
Transcript:     no transcript.  Re-compiling the entire system creates the
                various .i.xxx tag files.  Running "sml-tags -r" gives:
	                uncaught exception getIntError
Comments:	This precedure works fine if I use a batch compiler based on 0.91
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 679
Title: "Compiler bug: addObject" while compiling the Edinburgh library
Keywords: modules, functors, abstype
Submitter: wkh@dce.austin.ibm.com (Ward K. Harold)
Date: 11/25/92
Version: 0.92  (works up through version 0.82, fails in version 0.83)
System: RS6000, AIX 3.2, MIPS, SPARC
Severity: major
Problem: 
  "Compiler bug: addObject" while compiling the Edinburgh library, version
  1.20 or 1.21.  Occurs when loading MonoSet.sml in the MonoSet functor.
Code: (* simplified version: bug679.sml *)
  functor F (X: sig end) = (* has to be a functor, not a structure *)
  struct
    abstype s = S
    with
      type t = unit  (* type definition necessary *)
    end
  end
Transcript: 
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - use "foo.sml";
  [opening foo.sml]
  Error: Compiler bug: addObject
  [closing foo.sml]
  - 
Fix: [Pierre Cregut]
  When I counted the number of components created in a structure that have a
  representation in the core, I forgot to count the components coming from the
  body of an abstype

  tulipe-cregut->diff elabstr.sml elabstr.sml~
  42,44c42,43
  <       | (AbstypeDec {abstycs,withtycs,body,...}, t) => 
  <          let val (strN,fctN,typN) = count (body,t)
  <          in (strN,fctN,typN+length abstycs+length withtycs) end
  ---
  >       | (AbstypeDec {abstycs,withtycs,...}, (strN,fctN,typN)) => 
  >          (strN,fctN,typN + length abstycs + length withtycs)

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 680
Title: Bad vertical alignment prettyprinting case expression.
Keywords: printing, prettyprint
Submitter: Dave MacQueen
Date: 11/20/92
Version: 0.92
Severity: minor
Problem: 
  Bad veritcal allignment prettyprinting case expression.
Transcript: 
  - if 2 then 3 else 4;
  std_in:0.0-0.0 Error: case object and rules don't agree (tycon mismatch)
    rule domain: bool
    object:      int
    in expression:
      (case 2
	of true => 3
       | false => 4)
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 681
Title: building on SGI Indigos with cc version 3.10
Keywords: install, runtime, mips, SGI
Submitter: asgeir@viking.asd.sgi.com (Asgeir Eiriksson), Fernando Pereira
Date: 12/2/92
Version: 0.92
System: SGI R3000 and R4000 Indigo
Severity: Major
Problem: 
  sml fails to build with /usr/bin/cc version 3.10 (the latest)
Transcript: 
	cc -O  -DMIPS -D_BSD_SIGNALS -D__STDC__ -Dsgi -DSGI  -o run run.o run_ml.o callgc.o gc.o export.o timers.o  ml_objects.o cfuns.o cstruct.o signal.o exncode.o malloc.o  mp.o sync.o prim.o allmo.o 
/usr/bin/ld:
This executable contains branch instruction(s) at end-of-page
makeml> echo ( exportML "sml"; output(std_out,System.version); output(std_out,(chr 10)); output(std_out, "")); | runtime/run -m 8192 -r 5 -h 2048 IntMipsBig

[Increasing heap to 2051k]
[Loading mo/CoreFunc.mo]
...
  
[closing boot/perv.sml]
[Loading boot/overloads.sml]
structure Overloads : ...
[closing boot/overloads.sml]
Go for it
- 
[Major collection... 15% used (550960/3548736), 350 msec]

[Decreasing heap to 2699k]

[Major collection... 100% used (552208/552208), 320 msec]
==> Inconsistent object for export: !(0)

uncaught exception Io "exportML "sml": Error 0"
-
Comments:
  This does not occur with the 2.10 version of cc.
  Reproducible on Fernando Pereira's Indigo.
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 682
Title: excess newlines in compiler warning message
Keywords: printing, error messages
Submitter:      Thomas Yan  tyan@cs.cornell.edu
Date:           12/2/92
Version:        .92
Severity:       minor
Problem:        extraneous blank lines printed during compilation
Code:           val [1,2,3] = [1,2,3]
Transcript:
    - val [1,2,3] = [1,2,3];
    std_in:55.1-55.21 Warning: binding not exhaustive
              1 :: 2 :: 3 :: nil = ...
    
    
    
    
    
    
    
    -
Comments: baffling the first time it appears
Fix: In print/ppdec.sml, make each declaration responsible for
  printing it's own terminating newline.
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 683
Title: Compiler bug: Extern: update_structure 2
Keywords: modules, signatures, error recovery
Submitter: Sanjiva Prasad <sanjiva@ecrc.de>
Date: 12/2/92
Version: 0.92
Severity: minor
Problem: 
 Elaborating an illegal signature decl leads to Compiler bug:
 Extern: update_structure 2.
Code:
  signature S =
  sig
    functor Foo(X: S) : S
  end
Transcript: 
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - signature S =
  = sig
  =   functor Foo(X: S) : S
  = end;
  std_in:4.18 Error: unbound signature: S
  std_in:4.23 Error: unbound signature: S
  Error: Compiler bug: Extern: update_structure 2
Fix: [Pierre Cregut]
  update_structure didn't consider the case where an error had already been
  encountered. I have added two cases: the structure is an error, the
  signature is an error. Only the second one is proved to be necessary but the
  first one is safe.

  tulipe-cregut->diff extern.sml extern.sml~
  102,103d101
  <    | ERROR_STR => ()
  <    | INSTANCE{sign as ERROR_SIG,...} => ()
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 684
Title: Compiler bug: checkList
Keywords: modules, functors, higher-order functors
Submitter: Sanjiva Prasad <sanjiva@ecrc.de>
Date: 12/2/92
Version: 0.92
Severity: major
Problem: 
  A functor definition causes "Compiler bug: checkList".
Transcript: 
  - signature S1 = sig end;
  signature S1 = sig  end
  - funsig FOO (X:S1) (Y:S1) = S1;
  funsig FOO(X:<sig>) = sig functor <functor> : <sig> end
  - structure A:S1 = struct end;
  structure A : S1
  - functor Bar (C:S1) = C;
  functor Bar : <sig>
  - functor Foo (X:S1) (Y:S1) = X;
  functor Foo : <sig>
  - functor Foo:FOO = Foo;
  functor Foo : <sig>
  - funsig FOO2 (X:S1) = S1;      
  funsig FOO2(X:<sig>) = sig  end
  - functor Dummy (W: sig functor F :FOO2) (functor Z:FOO2) = Z(A);     
  std_in:9.38 Error: syntax error found at RPAREN
  - functor Dummy (W: sig functor F :FOO2 end ) (functor Z:FOO2) = Z(A); 
  functor Dummy : <sig>
  - functor Bar1 = Dummy (Foo(A)) (functor Z = Bar);
  std_in:10.16-10.47 Error: unmatched structure spec: F
  std_in:10.16-10.47 Error: unbound functor: <functor> in path <hidden>.<functor>
  - functor Dummy (W: S1)  (functor Z:FOO2) = Z(A); 
  functor Dummy : <sig>
  - functor Bar1 = Dummy (Foo(A)) (functor Z = Bar);
  std_in:11.16-11.47 Error: unbound functor: <functor> in path <hidden>.<functor>
  - structure C:S1 = struct functor G=Bar end;
  structure C : S1
  - open C;
  open C
  - structure C:S1 = Foo(A);
  structure C : S1
  - open C;
  open C
  - funsig ARBIT (B:S1) (type t) = S1;
  funsig ARBIT(B:<sig>) = sig functor <functor> : <sig> end
  - 
  - 
  - functor Bar5 = Foo (Foo A);
  std_in:18.25 Error: syntax error found at ID
  - functor Bar5 = Foo (Foo (A) );
  Error: Compiler bug: checkList

Code: (* bug684.sml *)
  (* the following reproduces the bug in 0.92 *)
  signature S = sig end;
  funsig FOO (X:S) (Y:S) = S;
  functor Foo (X:S) (Y:S) = X;
  functor Foo: FOO = Foo;  (* with this deleted produces different strange error *)
  structure A:S = struct end;
  structure C:S = Foo(A);  (* with this deleted, no error *)
  functor Bar5 = Foo(Foo(A)); (* ===> Error: Compiler bug: checkList *)

Comments:
    Currently one must view all arguments to a functor as structures.
    In particular, if an argument to a H-O functor is itself a functor,
    it is viewed as being a functor component of a structure
    argument.  

    But suddenly here, I found some funny behaviour when trying to treat
    results of part-applying curried functors as structures.
    I've attached the session transcript.  The symptoms were repeated when
    I replayed the session script in toto.  But when I tried to
    redo things with some of the chaff (irrelevant definitions and evaluations)
    removed, things worked fine.  The Compiler bug checkList was a surprise. 

Status: fixed in 0.93 (probably same as 673)
----------------------------------------------------------------------
Number: 685
Title: loss of line numbers loading with System.Compile
Keywords: line numbers, top level
Submitter: Gene Rollins
Date: 12/3/92
Version: 0.92
Severity: minor
Problem: 
  Code loaded into the interactive system using System.Compile does
  not give accurate line numbers when using System.Compile rather than
  use.
Code: 
  structure c :sig val c :string -> unit end = struct

  open System.Env System.Compile

  fun withSource (sourceName:string)
	(action :source -> 'a -> 'b) (argument:'a) :'b =
    let val sourceStream = open_in sourceName
	val source = makeSource (sourceName, 1, sourceStream, false, 
				 {linewidth= !System.Print.linewidth,
				  flush=System.Print.flush,
				  consumer=System.Print.say})
	val result = action source argument
		       handle exn => (closeSource source; raise exn)
    in closeSource source; result end

  fun c (sourceName:string) :unit =
    let val env = layerEnv (!topLevelEnvRef, !pervasiveEnvRef)
	val se = staticPart env
	fun comp source () = compile (source, se)
	val compUnit = withSource sourceName comp ()
    in () end

  end


  ********** a.sml *******
  structure a = struct
    fun f [] = ()
  end
  ************************

  See the difference with:

  - c.c "a.sml";
  - use "a.sml";
Fix: In elaborate/frontend.sml, make parse smash linePos only for
  interactive source.
  Also fixed it so that compileAst can take an optional source parameter
  so linenumbers can be provided in error messages for elaborating and
  translating asts. (build/compile.sml, boot/system.sig)
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 686
Title: floating-point divide by zero is broken on SGI
Keywords: 
Submitter: 	D. A. Ladd (ladd@graceland.ih.att.com)
Date: 		11/30/92
Version: 	0.91, 0.92
System: 	SGI
Severity: 	major
Problem: 	floating-point divide by zero is broken
Code: 
	1.0 / 0.0;
Transcript: 
	Standard ML of New Jersey, Version 0.92, November 18, 1992
	val it = () : unit
	- 1.0 / 0.0;
	strange floating point error, 14
Comments:
	This works okay on other MIPS-based machines (e.g., hunny).
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 687
Title: src/Makefile is out of date.
Keywords: install, Makefile
Submitter: Fernando Pereira
Date: 12/4/92
Version: 0.92
Severity: major
Problem: src/Makefile is out of date.

First of all, the Makefile refers to ../tools/sourcegroup but the
distribution has SG2.2nj. With this fixed, various files seem to be
missing:

	cat ../tools/gnutags/export.sml | sml-export
Standard ML of New Jersey, Version 0.92, November 18, 1992
val it = () : unit
[opening ../tools/sourcegroup/src/StringXtra.sig]
[use failed: open_in "../tools/sourcegroup/src/StringXtra.sig": openf failed, No such file or directory]
uncaught exception (Loader): SystemCall

Then sml-conn fails to make because

	../tools/sourcegroup/sml-conn/export.sml

is missing. Finally, sourcegroups fail to build with

[opening date.sml]
[use failed: open_in "date.sml": openf failed, No such file or directory]
[closing ../tools/sourcegroup/save.sml]
uncaught exception (Loader): SystemCall

Comments: the files required to build smlsg and sml-conn are all there
so they can be built manually. (sml-conn/export.sml no longer exists).
Fix: get rid of src/Makefile

Status: fixed in 0.93 (check)
----------------------------------------------------------------------
Number: 688
Title: profiler doesn't compile
Keywords: profiler
Submitter: Fernando Pereira
Date: 12/5/92
Version: 0.92
Severity: major
Problem: 
  Building the profiling version of sml fails while compiling
  profile/profperv.sml when executing
    sml < profile/script
Transcript: 
  [opening profile/profperv.sml]
  val it = () : unit
  profile/profperv.sml:73.17-73.26 Error: operator is not a function
    operator: bytearray
    in expression:
      ba sub
  profile/profperv.sml:79.18-79.32 Error: operator and operand don't agree (tycon mismatch)
    operator domain: bytearray
    operand:         (bytearray * int -> int) -> int -> 'Z
    in expression:
      length ba
  profile/profperv.sml:83.16-83.33 Error: operator and operand don't agree (tycon mismatch)
    operator domain: bytearray
    operand:         (bytearray * int -> int) -> int -> 'Z
    in expression:
      length ba
  profile/profperv.sml:88.29-88.41 Error: operator is not a function
    operator: bytearray
    in expression:
      ba sub
  [closing profile/profperv.sml]
Fix: add "infix 9 sub" just after "open ByteArray", because infixes are
  no longer carried by structures (signatures?). [ByteArray shouldn't
  be signature constrained because of inlining!!!]
Status: fixed in 0.93a
----------------------------------------------------------------------
Number: 689
Title: Compiling lambda prolog fails with compiler bug "adjust_variable".
Keywords: 
Submitter: Fernando Pereira
Date: 12/5/92
Version: 0.92
Severity: Critical
Problem: 
  Compiling lambda prolog fails with compiler bug "adjust_variable".
Code: elp.tar.Z
Transcript: 
  sgiharrar:lp$ sml-export
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - use "export-elp.sml";
  .... lots of stuff ....
  [opening elp/elp_global_program.fun]
  elp/elp_global_program.fun:23.34-23.70 Error: operator and operand don't agree (type mismatch)
    operator domain: '2Z * '2Y
    operand:         '2Z * '2Y
    in expression:
      ref (imports,program)
  elp/elp_global_program.fun:23.7-24.26 Error: operator and operand don't agree (type mismatch)
    operator domain: string * (string list * Program.program) ref
    operand:         string * _
    in expression:
      ModuleState (module_name,ref (imports,program))
  elp/elp_global_program.fun:26.10-26.27 Error: operator and operand don't agree (type mismatch)
    operator domain: string * string
    operand:         string * string
    in expression:
      = (module_name,m1)
  elp/elp_global_program.fun:27.12-27.38 Error: operator and operand don't agree (type mismatch)
    operator domain: (string list * Program.program) ref
		     * (string list * Program.program)
    operand:         (string list * Program.program) ref
		     * (string list * Program.program)
    in expression:
      := (entry,(imports,program))
  Error: Compiler bug: adjust_variable
  [closing elp/elp_global_program.fun]

Status: fixed in 0.93 (probably related to bug 673 or 671)
----------------------------------------------------------------------
Number: 690
Title: maskSignals breaks interactive input
Keywords: signals, top level
Submitter:      Andrew Tolmach apt@cs.pdx.edu
Date:		12/8/92
Version:        0.92
System:         Sun4 SunOS, Sequent, probably others
Severity:       minor
Problem:        maskSignals breaks interactive input
Code:          
	
- System.Signals.maskSignals true;
- ^C

Transcript:  With above code, system goes into infinite loop.
Comments:  Any signal for which a handler is installed will do in place of
	CTRL/C.  The problem is in cfuns.c/ml_wait_for_in:

  restart:; /* on EINTR */
    if (msp->inSigHandler
    || ((! _setjmp (msp->SysCallEnv)) && 
(5)	(((msp->ioWaitFlag = 1), (msp->NumPendingSigs == 0))))) {
	... 
(1)	select()
	 ...
    }
    else {
(6)	backup_kont(msp);
	sigsetmask (0);  /* re-enable signals */
	return;
    }
   
    if (sts == -1) {
	if (errno == EINTR)
(4)	    backup_kont(msp);
	else
	    raise_syserror(msp, 0);
	return;
    }

and its interaction with signal.c/sig_handler:

    /* record the signal */
(2)   msp->NumPendingSigs++;
      msp->SigTbl[ml_sig]++;

(3)   if (!msp->maskSignals) {
	if (msp->ioWaitFlag) {
	  /* We were waiting for a blocking I/O operation when the signal occurred,
	   * so longjmp out of the operation (see io_wait() in "cfuns.c"). */
	    _longjmp (msp->SysCallEnv, 1);
	}
	else ...
      }


Suppose we've called maskSignals false, setting msp->maskSignals to 
true, have called ml_wait_for_in, and are sitting in the select call 
(line 1) when a signal occurs.  The following occurs:

1) The system invokes sig_handler, which increments NumPendingSigs 
(line 2) but doesn't longjmp out because of the test at line 3.

2) The select call returns EINTR, so ml_wait_for_in calls backup_kont 
(line 4) to set up the ML state to reenter C immediately.

3) When ml_wait_for_in is reentered, it refuses to recall select because
of the test on NumPendingSignals at line 5; instead, it calls backup_kont
again (line 6), and returns to C.  This step is then repeated forever.

Fix: One possiblity is to change the test in line 5 to:

(5)	(((msp->ioWaitFlag = 1), 
	  (msp->NumPendingSigs == 0 || msp->maskSignals))))) {


Or, the position of the test against maskSignals could be changed in
sigHandler, so that the longjmp is always activated?  In that case,
EINTR should never be returned, right?

Comment [jhr]:
  I've thought about this, and I think that the correct fix is
  to check for masked signals in ml_wait_for_in (also in ml_select).
  In particular. the code should be

      if (msp->inSigHandler || msp->maskSignals || ...)

  since being in a signal handler implies masked signals.

  I would point out that calling maskSignals prior to calling
  ml_in_wait is bogus, since the whole point of ml_in_wait is
  to provide a safe place to interrupt when waiting for input.

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 691
Title: Compiler bug: ModuleUtil: lookFormalBinding 1
Keywords: modules, functors, higher-order functors
Submitter: Pierre Cregut
Date: 12/8/92
Version: 0.92
Severity: Major
Problem: Compiler bug: ModuleUtil: lookFormalBinding 1
Code: 
  signature S1 = sig type a ; val intro : unit -> a end;
  functor F4 
    (structure X1 : S1)
    (structure X2 : sig val x : X1.a end) =
  struct end;
Comments:
  But I am afraid there are other changes to make. The bug comes from
  FULL_SIG found while elaborating the argument of an embedded functor.
  There are other places where FULL_SIG are created. I will try to eliminate
  all of them.
Fix:
  Here is a fix:
  tulipe-cregut->diff elabstr.sml elabstr.sml~
  352,355c352
  <                              binding =
  <                                STR_FORMAL{
  <                                  pos=0,
  <                                  spec=signatureOfStructure argument},
  ---
  >                              binding = STR_FORMAL{pos=0,spec=FULL_SIG},

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 692
Title: signal handling on 386 can dump core
Keywords: signals, x86
Submitter:      Andrew Tolmach apt@cs.pdx.edu
Date:		12/14/92
Version:        0.90+
System:         visible on Sequent; affects all 386 systems
Severity:       critical
Problem:        signal handling on 386 can dump core
Code:          
	
open System.Signals
fun alarmHandler(_,k) = k
val _ = setHandler(SIGALRM,SOME(alarmHandler))
open System.Timer
val setitimer = System.Unsafe.Cinterface.setitimer
fun h() = setitimer(0,TIME{sec=0,usec=10000} TIME{sec=0,usec=10000});
(* System can dump core at any time after h() is executed.
   The following sequence is quite reliable on Sequents: *)
val cd = System.Directory.cd;
fun r() = let fun f () = (cd "."; f()) in h(); f() end;
r();

Comments: 
The problem is that limitptr lives on the stack and is addressed
relative to %esp.  Unfortunately, various operations in the
386 implemention (notably saveregs, some fp operations, and
all pc-relative loads in generated code) temporarily push things onto the
stack, thus altering %esp.   But the adjust_limit routine,
which zeroes the limitptr, may be executed by command of the signal
handler *at any time* when inML == 1; thus the wrong piece of the
"ML stack frame" gets zeroed (in this case the exncont).

Fix:

Add a field MLframe to the ML state vector (for 386's only), pointing
to the base of the ML stack frame.  This field is initialized by 
restoreregs before setting inML = 1.  The signal handler uses this
pointer to access and zero the limit pointer directly, avoiding the
need for an adjust_limit routine.

[I've sent Lal a bundle containing these changes.]

Longer-term fix:

If the 386 implementation were cleaned up so that it no longer messed
with %esp, use of the MLframe pointer in the signal handler
could be replaced by scp->sp.

Status: fixed in 0.93
----------------------------------------------------------------------
Number: 693
Title: backspace (rubout char) under HPUX 8.0
Keywords: hppa, hpux, I/O
Submitter:      M.J.Morley <mjm@uk.ac.ed.dcs>
Date:           12/17/92
Version:        Version 75, November 11, 1991
System:         HP 380/9000 under HP-UX 8.0
Severity:       minor bur, major irritation in all ML applications
Problem:        Backspace incorrectly bound?
Comments:       This was not manifest under HP-UX 7.0 but when we
                recently switched to the HP-UX 8.0 the backspace
                `stopped working'. Characters are rubbed out but this
                effect is not echoed to the screen. The kit we use is
                the standard HP config. screen/mouse/KB -- running
                MIT's X11R4, in case that is significant.
Status: not a bug (ours)
----------------------------------------------------------------------
Number: 694
Title: System.Compile.execute provokes compiler bug ModuleComp.getImport
Keywords: modules, signatures, signature matching
Submitter:      Kjeld H. Mortensen (kjeld@metasoft.com)
Date:           12/21/92
Version:        0.92
System:         Sparc, SunOS 4.1.1
Severity:       major
Problem:        System.Compile.execute provokes ModuleComp.getImport
                compiler bug msg
Code:           
The file "test.sml" used in the following is just:
  signature FOO =
  sig
    val x : int
  end;

  structure foo =
  struct
    val x = y
  end;

Transcript:     
Standard ML of New Jersey, Version 0.92, November 18, 1992
val it = () : unit
- val y= 0;
val y = 0 : int
- val myenv= System.Env.concatEnv (!System.Env.topLevelEnvRef, !System.Env.pervasiveEnvRef);
val myenv = prim? : environment
- val mystatenv= System.Env.staticPart myenv;
val mystatenv = prim? : staticEnv
- val myppcons= {linewidth= 79, consumer= (fn (x:string) => print x), flush= (fn () => ())};
val myppcons = {consumer=fn,flush=fn,linewidth=79}
  : {consumer:string -> unit, flush:unit -> unit, linewidth:int}
- val mystream= open_in "test.sml";                      (* See 'Code' above *)
val mystream = - : instream
- val mysrc = System.Compile.makeSource ("test.sml", 1, mystream, false, myppcons);
val mysrc = prim? : source
- val myStatxCode= System.Compile.compile (mysrc, mystatenv);
val myStatxCode = ({boundLvars=[10162],staticEnv=prim?},prim?)
  : System.Compile.staticUnit * codeUnit
- val mynewenv= System.Compile.execute (myStatxCode, myenv);
Error: Compiler bug: ModuleComp.getImport

uncaught exception Compile

Comment: [dbm] Free value variables in compilation units are not
  supported in 0.93.  This problem will go away in 0.94.

Status: not a bug
----------------------------------------------------------------------
Number: 695
Title: segmentation fault involving System.Ast
Keywords: segmentation fault, crash
Submitter: Gene Rollins
Date: 12/22/92
Version: 0.92
System: Decstation, Mach
Severity: critical
Problem: segmentation fault
Code: 

  structure bug = struct

  structure A = System.Ast

  fun ok m = (print ("\n<OK "^m^">\n"); flush_out std_out)

  val p1 = "functor G = H"
  val p2 = "functor F () = struct end"

  fun try program =
    let val ppc = {linewidth = !System.Print.linewidth,
		   flush = System.Print.flush,
		   consumer = System.Print.say}
	val strm = open_string (program ^ "\n")
	val src = System.Compile.makeSource ("", 1, strm, false, ppc)
	val start = System.Env.staticPart (!System.Env.pervasiveEnvRef)
	val (ast, se) = System.Compile.parse (src, start)
    in
      do_dec ast handle exn => (close_in strm; raise exn);
      close_in strm
    end

  and do_dec (ast:A.dec) :unit =
   (case ast of
       (A.ValDec _) => ()
     | (A.ValrecDec _) => ()
     | (A.FunDec _) => ()
     | (A.TypeDec _) => ()
     | (A.DatatypeDec _) => ()
     | (A.AbstypeDec _) => ()
     | (A.ExceptionDec _) => ()
     | (A.StrDec _) => ()
     | (A.AbsDec _) => ()
     | (A.FctDec (arg:A.fctb list)) => app f_fctb arg
     | (A.SigDec _)   => ()
     | (A.FsigDec _) => ()
     | (A.LocalDec _) => ()
     | (A.SeqDec arg) => app do_dec arg
     | (A.OpenDec _) => ()
     | (A.OvldDec arg) => ()
     | (A.FixDec arg) => ()
     | (A.ImportDec arg) => ()
     | (A.MarkDec (arg,_,_)) => do_dec arg
   )
  and f_fctb (ast:A.fctb) :unit =
   (case ast of
       (A.Fctb {name:symbol, def:A.fctexp}) => f_fctexp def
     | (A.MarkFctb (arg,_,_)) => f_fctb arg
   )
  and f_fctexp (ast:A.fctexp) :unit =
    let val _ =  ok "0" in
      case ast of
	 (A.VarFct (path:A.path, constraint:A.fsigexp option)) =>
	   let val _ = ok "1"
	       val symbol'list = ((System.Unsafe.cast path) :symbol list)
	   in
	     case path of [] => ok "1a"
	      | (head::tail) => (ok "1b"; System.Symbol.name head; ok "1c")
	   end
       | (A.FctFct {params :(symbol option * A.sigexp) list, body :A.strexp,
		constraint :A.sigexp option}) => ok "2"
       | (A.MarkFct (arg,_,_)) => (ok "3"; f_fctexp arg)
    end

  end
 
Transcript: 
  - bug.try bug.p1;  (* ok *)
  - bug.try bug.p2;  (* causes segmentation fault *)
Comments:
  If you look at the output, it seems that in the function f_fctexp,
  the case on the ast should go on the FctFct branch for bug.p2, but it
  goes on the VarFct branch.

  When I try to bind the offending ast to a name at the top-level I get:
    Error: Compiler bug: PPVal.switch: none of the datacons matched
Fix: eternalized ast did not agree with internal ast on type fctexp.
Status: fixed in 0.93c (dbm)
----------------------------------------------------------------------
Number: 696
Title: Type system error in "includes" of signatures
Keywords: modules, signatures, include
Submitter:      Chet Murthy (murthy@margaux.inria.fr)
Date:           12/29/92
Version:        0.92
System:         sun4, sunos 4.1
Severity:       major
Problem:        Type system error in "includes" of signatures
Code:           see transcript
Transcript:     
I just found a bug in signature mechanism of 0.93.  It manifests
itself when I construct signatures by using "include".  I enclose a
short file which elicits the bug in the version of 0.93 which I
recuperated from research.att.com, around the end of november.

P.S.  The result of the bug is a bus error.
--------------cut here-------------------
structure A =
struct

type (''1a, '1b) t = ((''1a * '1b) list)

fun new() = nil
fun toList l = l
fun dom (l:(''a, 'b) t) = List.map #1 l

end

signature ASIG =
  sig
    type (''1a, '1b) t
    val new : unit -> (''1a, '1b) t
  end

signature BSIG =
  sig
    type (''1a, '1b) t
    val dom : (''1a, '1b) t -> ''1a list
  end
;
signature AB_SIG =
  sig
    include ASIG BSIG
  end
;
structure goo : AB_SIG = A;

let val _ = goo.dom (SOME "foo") in 23 end;

Fix [Cregut]:
tulipe-cregut->diff elabsig.sml elabsig.sml~
68c68
<    fun adjustBinding (basetype,basestr,basefct,baseslot,makeStamp,redef) =
---
>    fun adjustBinding (basetype,basestr,basefct,baseslot,makeStamp) =
108,112d107
<         and relocate pos =
<               let fun reloc [] = pos+basetype
<                     | reloc ((porig,pdest)::l) =
<                          if pos = porig then pdest else reloc l
<               in reloc redef end
125c120
<               FORMtyc{pos=relocate pos,
---
>               FORMtyc{pos=pos+basetype,
143c138
<                       RELtyc {name=name,pos=([],relocate offset)}
---
>                       RELtyc {name=name,pos=([],offset+basetype)}
181c176
<       val adjust = adjustBinding (!tycons,!strs,!fcts,!slots,makeStamp,redef)
---
>       val adjust = adjustBinding (!tycons,!strs,!fcts,!slots,makeStamp)

Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 697
Title: wrong Subscript exception in ByteArray
Keywords: ByteArray
Submitter:      Chet Murthy (murthy@margaux.inria.fr)
Date:		12/29/92
Version:        0.92
System:         Sun4, rel 4.1
Severity:       minor
Problem:        ByteArray.sub and ByteArray.update raise Array.Subscript
                and not ByteArray.Subscript (otherwise named Ord)
Code:           let val x = ByteArray.array(10,0) in
                    ByteArray.sub(x,11) end
Transcript:     
Comments:
Fix:            In translate/inlineops.sml - the change was two
one-liners, to make "sub" and "update" return CoreInfo.exnOrd, instead
of CoreInfo.exnSubscript in inlstore and inlbyteof.  I enclose the
patch at the end.

*** inlineops.sml.~1~	Wed Nov 18 00:06:10 1992
--- inlineops.sml	Sat Dec 26 18:18:20 1992
***************
*** 123,129 ****
                   COND(APP(PRIM(P.LESSU,predTy),
                            RECORD[vi,APP(PRIM(P.LENGTH,lengthTy),vs)]),
                        APP(PRIM(P.ORDOF,ordofty),RECORD[vs,vi]),
!                       RAISE(conToLexp(!CoreInfo.exnSubscript),INTty)))))
          end
   
  (* Bytearray store:
--- 123,129 ----
                   COND(APP(PRIM(P.LESSU,predTy),
                            RECORD[vi,APP(PRIM(P.LENGTH,lengthTy),vs)]),
                        APP(PRIM(P.ORDOF,ordofty),RECORD[vs,vi]),
!                       RAISE(conToLexp(!CoreInfo.exnOrd),INTty)))))
          end
   
  (* Bytearray store:
***************
*** 154,160 ****
                        COND(APP(PRIM(P.LESSU,predTy),RECORD[vc,INT 256]),
                             APP(PRIM(P.STORE,storety),RECORD[vs,vi,vc]),
                             RAISE(conToLexp(!CoreInfo.exnRange),INTty)),
!                       RAISE(conToLexp(!CoreInfo.exnSubscript),INTty))))))
          end
  
  (*  String ordof:
--- 154,160 ----
                        COND(APP(PRIM(P.LESSU,predTy),RECORD[vc,INT 256]),
                             APP(PRIM(P.STORE,storety),RECORD[vs,vi,vc]),
                             RAISE(conToLexp(!CoreInfo.exnRange),INTty)),
!                       RAISE(conToLexp(!CoreInfo.exnOrd),INTty))))))
          end
  
  (*  String ordof:

Status: fixed in 0.93c (dbm)
----------------------------------------------------------------------
Number: 698
Title: Uninformative nonexhaustive match warning messages.
Keywords: error messages, matches
Submitter: John Reppy
Date: 12/29/92
Version: 0.92
System: Sparcstation
Severity: major
Problem: Uninformative nonexhaustive match warning messages.

Transcript: 
  When compiling Isabelle/Pure:

  lexicon.ML:63.9-63.73 Warning: match nonexhaustive
	    <pat> => ...

  lexicon.ML:55.9-61.62 Warning: match nonexhaustive
	    <pat> => ...
	    <pat> => ...
	    <pat> => ...
Comments:
  Looks like printdepth is set to low, but doesn't happen at top level.

  [appel: Isabelle actively resets the print depth, and brings this problem
   upon itself.]

Status: not a bug
----------------------------------------------------------------------
Number: 699
Title: "Compiler bug: ModuleUtil: lookFormalBinding 1" (secondary)
Keywords: modules, error recovery
Submitter: John Reppy
Date: 12/31/92
Version: 0.93b
Severity: minor
Problem: 
  "Compiler bug: ModuleUtil: lookFormalBinding 1" generated as secondary
  error message after an unbound signature reference.
Code: (contents of file trace-cml.sml)
  functor TraceCML (
    structure CML : INTERNAL_CML
          and RunCML : RUN_CML
	  and CIO : CIO  (* <== should have been signature CONCUR_IO *)
    sharing CML = RunCML.CML = CIO.CML
  ) : TRACE_CML = struct

    structure CIO = CIO

  (* where to direct trace output to *)
    datatype trace_to
      = TraceToOut
      | TraceToErr
      | TraceToNull
      | TraceToFile of string
      | TraceToStream of CIO.outstream

  end; (* TraceCML *)
Code: (simplified)
  functor F(structure A : sig end
            structure B : SXX   (* undefined sig SXX *)
	    sharing A = B.C) =  (* undefined component B.C -- error msg *)
  struct end
Transcript: 
  [opening trace-cml.sml]
  trace-cml.sml:13.14-13.16 Error: unbound signature: CIO
  Error: Compiler bug: ModuleUtil: lookFormalBinding 1
  [closing trace-cml.sml]
Fix: added a case:

     | STRbind(STRvar{binding=STR_FORMAL{spec=ERROR_SIG,...},...}) =>
          raise ErrorStructure

in function lookFormalBinding in modules/moduleutil.sml.
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 700
Title: wrong printing with toplevel vector pattern
Keywords: printing, top level
Submitter: Dave MacQueen
Date: 1/3/93
Version: 0.93b
Severity: minor
Problem: 
  Top level does not print value bindings when a vector pattern is used.
Transcript: 
Standard ML of New Jersey, Version 0.93b, December 14, 1992
val it = () : unit
- val #[x,y,z] = #[1,2,3,];
std_in:2.1-2.23 Warning: binding not exhaustive
          #[x,y,z] = ...

-
- val [x,y] = [3,4];
std_in:0.0-0.0 Warning: binding not exhaustive
          x :: y :: nil = ...
val x = 3 : int
val y = 4 : int



-
Comment:
  Note also the extra newlines for the printing of the list bindings.
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 701
Title: wrong types printed for top-level exception declarations
Keywords: printing, types, exceptions, top level
Submitter:      Andrzej Filinski <andrzej@cs.cmu.edu>
Date:		1/12/93
Version:        0.92  (November 18, 1992)
System:         all
Severity:       minor
Problem:        wrong types printed for top-level exception declarations
Transcript:     
    Standard ML of New Jersey, Version 0.92, November 18, 1992
    val it = () : unit
    - exception E;
    exception E			[ok]
    - exception E of int;
    exception E			[same for all non-functional types]
    - exception E of int->bool;
    exception E of int		[only codomain reported for functional types]
Fix: changed print/ppdec.sml
Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 702
Title: realfloor is unimplemented
Keywords: floats, realfloor
Submitter:      Thomas Yan, tyan@cs.cornell.edu
Date:           1/12/93
Version:        .75, .92 (so presumably ever since .75)
Severity:       major
Problem:        realfloor is unimplemented
Comments:       hard to work around -- need to know/compute internal
                representation of floats
Suggestion: [appel]

local 
   val maxint = 4503599627370496.0 (* This is the IEEE double-precision
	      			      maxint; won't work accurately on VAX *)

   fun realround x = if x>=0.0 then x+maxint-maxint else x-maxint+maxint
   (* realround(x) returns x rounded to some nearby integer, almost always
      the nearest integer. *)
in fun realfloor x = let val y = realround x
		      in if y>x then y-1.0 else y
		     end
end

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 703
Title: betaexpand in cpsopt goes into infinite loop
Keywords: code generation, infinite loop
Submitter:      Greg Morrisett
Date:		1/13/93
Version:        0.92
System:         Mips Mach, Sparc Mach, (probably all)
Severity:       critical
Problem:        betaexpand in cpsopt goes into infinite loop
Code:		
  val rec f = fn true => f false | false => f true

Transcript:     
  Standard ML of New Jersey, Version 0.92, November 18, 1992
  val it = () : unit
  - val rec f = fn true => f false | false => f true;

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

  [Increasing heap to 2941k]

  [Increasing heap to 3941k]

  [Increasing heap to 7001k]
   95% used (2120604/2211028), 2078 msec]
  <killed>

Comments:	Don't be fooled by the fact that this code doesn't
		terminate.  The original code that I whittled down
		to this *did* terminate.  It was a slight modification
		of cps/contract.sml.  Let me know if you want the
		original code...

Comment: [Greg, 1/18/93]
I'm not so sure that the problem is just in betaexpand, now.  The
example code I gave you compiles if you turn betaexpand off, but my
real code only compiles if you turn off all of cpsopt.

Comment: (awa)
 Compilation of his original (large) program did not infinite loop!  It merely
  kept going for approximately 14^6 beta-expansions, which took a long
  time and a lot of space.  [understatement]

Fix: [temporary. awa, 1/19/93]
  System.Control.CG.unroll := false;
  [permanent, awa, 1/20/93]
  Add "andalso n < max" to UNROLL case in body of function should_expand
  in cps/expand.sml.
  Also, let max=2, not max=5 (which was excessive)

Status: fixed in 0.93c (awa)
----------------------------------------------------------------------
Number: 704
Title: System.Unsafe.SysIO.access raises exception instead of returning false
Keywords: 
Submitter: 	John Reppy (jhr@research.att.com)
Date: 		1/14/93
Version: 	0.93 (and earlier)
System: 	all
Severity: 	minor
Problem: 	System.Unsafe.SysIO.access raises an exception when its argument
		is inaccessable, instead of returning false.
Code: 
	System.Unsafe.SysIO.access ("some-file-that-does-not-exist", []);
Transcript: 
	Standard ML of New Jersey, Version 0.93a, December 9, 1992
	val it = () : unit
	- System.Unsafe.SysIO.access ("some-file-that-does-not-exist", []);

	uncaught exception SystemCall

Comments: 	In the long run, there should be a datatype for the return value
		of access, since it can fail for significantly different reasons
		(e.g., no such file, not a directory, looping path, ...).
Fix:		Change the code in cfuns.c to return false instead of raising
		SystemError
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 705
Title: sml emacs subprocess dies when file is "used"
Keywords: emacs
Submitter: David Ladd (ladd@research.att.com)
Date: 1/21/92
Version: 0.93a
System: SGI, R3000, IRIX 4.0.4
Severity: major
Problem: 
  The following file works fine if ``used'' from the shell prompt, but
  dies when ``used'' under emacs.
Code: (file bug705.sml)
  exception foo;
  fun foo'(x) = raise foo;
  foo'(4);
Transcript:
  Standard ML of New Jersey, Version 0.93a, December 9, 1992
  val it = () : unit
  - [opening /tmp/t]
  exception foo
  val foo' = fn : 'a -> 'b
  [closing /tmp/t]

  uncaught exception foo
  uncaught exception (Loader): SystemCall

  Process cmusml finished
Owner: 
Status: not reproducible
----------------------------------------------------------------------
Number: 706
Title: non-terminating structure compilation
Keywords: modules, signatures, signature matching, infinite loop
Submitter:      Knut Omang (Univ. of Oslo), knuto@ifi.uio.no
Date:		1/8/93
Version:        0.75
System:         ds & sun4 (the below run done on a Sun Sparcstation 2)
Severity:       major
Problem:        non-terminating structure compilation
Code:           
--------
structure Queue1 =
  struct
    
    type 'a T = 'a list;
    exception E;
    
    fun hd(x::q) = x
      | hd [] = raise E;
  end

signature QUEUE = 
  sig
    type 'a T
    exception E
    val hd : 'a T -> 'b T
  end;

structure Q1: QUEUE = Queue1;

Transcript:     
------------
Standard ML of New Jersey, Version 75, November 11, 1991
Arrays have changed; see Release Notes
val it = () : unit
- use "qm.sml";           
[opening qm.sml]
structure Queue1 : 
  sig
    eqtype 'a T
    exception E
    val hd : 'a list -> 'a
  end
signature QUEUE = 
  sig
    type 'a T
    exception E
    val hd : 'a T -> 'b T
  end

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

[Increasing heap to 2636k]

[Increasing heap to 5236k]
 97% used (1614112/1649172), 1240 msec]

[Increasing heap to 8012k]

[Major collection...
[Increasing heap to 11916k]
 95% used (4137248/4349188), 3120 msec]

[Increasing heap to 12752k]
^C[closing qm.sml]

Interrupt
- 

Comments: This program should probably terminate quickly with an error msg..
Status: fixed in 0.75
----------------------------------------------------------------------
Number: 707
Title: overloading in the profiler
Keywords: profiler, overloading
Submitter: Lal George
Date: 1/21/93
Version: 0.93b
Severity: major
Problem: 
  Operators do not have their normal overloaded properties in the profiler.
Transcript: 
  - kisubi:$ smlp
  Standard ML of New Jersey, Version 0.93b, December 14, 1992[PROFILING]
  val it = () : unit
  - fun f x = x + 1;
  std_in:8.11-8.15 Error: operator and operand don't agree (tycon mismatch)
    operator domain: real * real
    operand:         real * int
    in expression:
      + (x,1)
Status: fixed in 0.93c (lal)
----------------------------------------------------------------------
Number: 708
Title: array too large
Keywords: array, bounds
Submitter: Carl Gunter
Date: 1/25/93
Version: 0.93b
System: Sparcstation
Severity: major
Problem: 
  Allocating very large array leads to strange behavior.
Transcript: 
  bolete% sml
  Standard ML of New Jersey, Version 0.93b, December 14, 1992
  val it = () : unit
  - open Array;
  ...
  - val A = array(100, true);
  val A = [|true,true,true,true,true,true,true,true,true,true,true,true,...|]
    : bool array
  - sub(A,5);
  val it = true : bool

  But this is different:

  bolete% sml
  Standard ML of New Jersey, Version 0.93b, December 14, 1992
  val it = () : unit
  - open Array;
  ...
  - val A = array(1073741823, true);
  val A = [||] : bool array
  - sub(A,5);
  val it = false : bool
  - sub(A, 13098);

  ... emacs window freezes ...

Comment:  the size is too large to fit in the 26 bits reserved in the
descriptor; the assembly language was not checking this.
Fix:  Change the ML code in perv.sml to check for size before calling
 assembly language.

Status: fixed in 0.93c
----------------------------------------------------------------------
Number: 709
Title: bad indentation
Keywords: printing, prettyprint, top level
Submitter: Dave MacQueen
Date: 1/26/92
Version: 0.93c
System: Mips Magnum, RISCos 4.52
Severity: minor
Problem: 
  System printout after opening a structure (System.Compile) has
  bad indentation.
Transcript: 
Standard ML of New Jersey, Version 0.93b, December 14, 1992
val it = () : unit
- open System.Compile;
open Compile
structure PP : sig type ppconsumer end
structure IO :
  sig
    type instream
    type outstream
  end
structure Ast : sig type dec end
exception Compile = Compile
  val makeSource = fn
    : string * int * instream * bool * System.PrettyPrint.ppconsumer -> source
  val closeSource = fn : source -> unit
  val changeLvars = fn : staticUnit -> staticUnit
  val elaborate = fn : source * staticEnv -> staticUnit
  val parse = fn : source * staticEnv -> Ast.dec * staticEnv
  val compile = fn : source * staticEnv -> staticUnit * codeUnit
  val compileAst = fn : Ast.dec * staticEnv * source option -> compUnit
  val execute = fn : (staticUnit * codeUnit) * environment -> environment
  val eval_stream = fn : instream * environment -> environment
  val use = fn : string -> unit
  val use_stream = fn : instream -> unit
  - 
- 
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 710
Title: 0.0/0.0 generates strange float exception (on a NeXT)
Keywords: 
Submitter:      Joel F. Klein, Joel.Klein@Rose-Hulman.EDU
Date:		1/28/93
Version:        0.75
System:         NeXTstation <hardware and OS version>
Severity:       minor
Problem:        0.0/0.0 generates strange float exception (on a NeXT)
Code:           0.0/0.0
Transcript:   

	mercutio 9:50pm > sml
	Standard ML of New Jersey, Version 75, November 11, 1991
	Arrays have changed; see Release Notes
	val it = () : unit
	- 0.0/0.0;
	strange floating point error, 0xd0
	mercutio 9:52pm > 

Comments: This is a known and "fixed" bug, but NeXTs don't know that.
Comments: [Joel Klein, 1/20/93]
I have additional information on bug report 710.  I left out which operating
system the NeXT was running.  This appears to be important, because the
"normal" NeXTs around here have a different response to the same input. Here's
the summary:

NeXT running NeXTstep 3.0:
  0.0/0.0 generates "strange float error"

NeXT running NeXTstep 2.0:
  0.0/0.0 returns 0.0

Example transscript of latter:
- 0.0/0.0;
val it = 0.0 : real
[Appel:]
SML/NJ 0.92 gives strange floating point error 0xd on NeXT 3.0.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 711
Title: SystemCall exceptions
Keywords: SystemCall
Submitter: Benli Pierce
Date: 9/30/92
Version: 0.90
System: sparc
Severity: major
Problem: 
I've encountered one strange behavior while playing around with SML
0.90 on a sparc.  Calls to System.system sometimes raise SystemCall
exceptions -- not in a fresh sml-sg image, but after a while, when a
few things have been compiled.

I thought it must be a problem with running out of virtual memory, but
I was able to get the same behavior after killing off several big
processes. 

Comments: (David Shepherd, des@inmos.co.uk, 4/6/93)
			Basically just some further info on open bug 711.
			This seems to be linked to the amount of swap space
			available. System calls work fine in sml on my machine
			but fail when used in hol90. However, running on another
			sparcstation with much more swap space then it works
			fine again. For hol work this is pretty serious as it
			is normal to do a system call to delete a theory file
			before running the code to rebuild in in proof scripts!
			Hope (a) this info is helpful, (b) this bug gets fixed
			soon!
Fix:			Get some more swap space :-(
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 712
Title: Compiler bug: Modules.distributeT:f DD146
Keywords: modules, functors, local spec
Submitter:      Tyng-Ruey Chuang, chuang@cs.nyu.edu
Date:           10/27/92
Version:        0.75
System:         Sun Sparc, O.S. version 4.1.1
Severity:       not major
Problem:        Compiler-error when local specification is used with
                type sharing equation in a signature declaration.
Code:           Note: named as "bug.sml" in Transcript.


  (*----------------------------------------------------------------------------*)
  (* Signature "FLIP" and its associated functor "Flip" *)
  
  signature FLIP =
  sig
      datatype Side = LHS | RHS
  end
  
  functor Flip () : FLIP =
  struct
      datatype Side = LHS | RHS   (* LHS for left-hand-side and
                                     RHS for right-hand-side *)
  end
  
  (*----------------------------------------------------------------------------*)
  (* Signature "FLOP" and its associated functor "Flop".
     Signature "FLOP" is identical(?) to "FLIP" though their names are different.
     Functor "Flop" should generate a structure identical to its input
     structure. *)
  
  signature FLOP =
  sig
  local
      structure flip : FLIP
  in
      datatype Side = LHS | RHS
      sharing type Side = flip.Side
  end
  end
  
  functor Flop (flip : FLIP) : FLOP =
  struct
  local
      structure flip = flip
  in
      open flip
  end
  end
  
  (*----------------------------------------------------------------------------*)
  (* A test to see if the following structures are identical(?). *)
  
  structure flip = Flip ()
  structure flop = Flop (flip)
  
  val identical = flip.LHS = flop.LHS


Transcript:

  Script started on Tue Oct 27 17:16:00 1992
  spunky% sml
  Standard ML of New Jersey, Version 75, November 11, 1991
  Arrays have changed; see Release Notes
  val it = () : unit
  - use "bug.sml";
  [opening bug.sml]
  bug.sml:24.5-24.26 Warning: LOCAL specs are only partially implemented
  Error: Compiler bug: Modules.distributeT:f DD146
  [closing bug.sml]
  - ^D
  spunky% ^D
  script done on Tue Oct 27 17:16:18 1992

Comments: The bug goes away if either local specifications in signatures
          are removed or sharing equation is removed.

For example:

  (*----------------------------------------------------------------------------*)
  (* Signature "FLIP" and its associated functor "Flip" *)
  
  signature FLIP =
  sig
      datatype Side = LHS | RHS
  end
  
  functor Flip () : FLIP =
  struct
      datatype Side = LHS | RHS   (* LHS for left-hand-side and
                                     RHS for right-hand-side *)
  end
  
  (*----------------------------------------------------------------------------*)
  (* Signature "FLOP" and its associated functor "Flop".
     Signature "FLOP" is identical(?) to "FLIP" though their names are different.
     Functor "Flop" should generate a structure identical to its input
     structure. *)
  
  signature FLOP =
  sig
      structure flip : FLIP                    (* NO local declaration here. *)
  
      datatype Side = LHS | RHS
      sharing type Side = flip.Side
  end
  
  
  functor Flop (flip : FLIP) : FLOP =
  struct
      structure flip = flip                    (* NO local declaration here. *)
  
      open flip
  end
  
  (*----------------------------------------------------------------------------*)
  (* A test to see if the following structures are identical(?). *)
  
  structure flip = Flip ()
  structure flop = Flop (flip)
  
  val identical = flip.LHS = flop.LHS

OR

(*----------------------------------------------------------------------------*)
(* Signature "FLIP" and its associated functor "Flip" *)

signature FLIP =
sig
    datatype Side = LHS | RHS
end

functor Flip () : FLIP =
struct
    datatype Side = LHS | RHS   (* LHS for left-hand-side and
                                   RHS for right-hand-side *)
end

(*----------------------------------------------------------------------------*)
(* Signature "FLOP" and its associated functor "Flop".
   Signature "FLOP" is identical(?) to "FLIP" though their names are different.
   Functor "Flop" should generate a structure identical to its input
   structure. *)

signature FLOP =
sig
    datatype Side = LHS | RHS
end

functor Flop (flip : FLIP) : FLOP =
struct
    open flip
end

(*----------------------------------------------------------------------------*)
(* A test to see if the following structures are identical(?). *)

structure flip = Flip ()
structure flop = Flop (flip)

val identical = flip.LHS = flop.LHS
Status: not a bug
----------------------------------------------------------------------
Number: 713
Title: sourcegroups crashes in a non-deterministic fashion.
Keywords: Sourcegroup
Submitter:      Lal George
Date:		10/28/92
Version:        0.91
System:         RS6000
Severity:       major
Problem:        sourcegroups crashes in a non-deterministic fashion.
Code:           
	Compile sourcegroups version 2.2.
	(This was brought to my attention by cliff@cs.cornell.edu)

Transcript:     

	[/usr/u/plg/SMLofNJ/91/tools/sourcegroup] bashful% sml-91
	Standard ML of New Jersey, Version 0.91, October 26, 1992
	val it = () : unit
	- use "build.sml";
	[opening build.sml]
	val print'sigs = 2 : int
	val it = () : unit
	[opening load-all.sml]
	[opening local/System/interrupt.sig]
	signature INTERRUPT = ...
	[closing local/System/interrupt.sig]
	val it = () : unit
	[opening local/System/interrupt.sml]
	structure Interrupt : INTERRUPT
	[closing local/System/interrupt.sml]
	val it = () : unit
	[opening local/System/ioStream.sig]
	signature IO_STREAM = ...
	[closing local/System/ioStream.sig]
	val it = () : unit
	[opening local/System/ioStream.sml]
	structure IO_Stream : IO_STREAM
	[closing local/System/ioStream.sml]
	val it = () : unit
	[opening tools/sepcomp.sml]

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

	[Increasing heap to 2979k]
	 33% used (729592/2187412), 200 msec]

	[Increasing heap to 3643k]
	signature SEPCOMP = ...
	structure SepComp : SEPCOMP
	[closing tools/sepcomp.sml]
	val it = () : unit
	[opening tools/compile.sml]
	signature COMPILE = ...
	structure Compile : COMPILE
	[closing tools/compile.sml]
	val it = () : unit
	val it = () : unit
	val load = fn : string -> unit
	[reading base.sml]

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

	[Increasing heap to 4051k]
	 32% used (955024/2984028), 310 msec]

	[Increasing heap to 4743k]

	[Major collection... 17% used (697240/3897980), 230 msec]
	[closing base.sml]
	val it = () : unit
	[reading local/System/pathname.sig]
	[closing local/System/pathname.sig]
	val it = () : unit
	[reading local/System/ioStream.sig]
	[closing local/System/ioStream.sig]
	Illegal instruction
======================================================================

Fix: 	The bug is caused by the lack of cache flushing after code
	generation. Add the line System.Unsafe.CInterface.flush_cache <string>
	wherever appropriate.
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 714
Title: failure of ByteArray.update
Keywords: ByteArray
Submitter: Fred Sullivan (sullivan@cs.rose-hulman.edu)
Date: 11/2/92
Version: 0.75
System: NeXT and Sun 3/SunOS
Severity: major
Problem: 
  ByteArry.update seems to fail in the following circumstances:

  1.  System.Control.interp is false.
  2.  update is called at top level.
Transcript: 
  Standard ML of New Jersey, Version 75, November 11, 1991
  Arrays have changed; see Release Notes
  val it = () : unit
  - open ByteArray;
  open ByteArray
  - val a = array(5, 65); 
  val a = - : bytearray
  - extract (a, 0, 5);
  val it = "AAAAA" : string
  - update (a, 3, 66);
  val it = () : unit
  - extract (a, 0, 5);
  val it = "AAAAA" : string
  - update (a, 0, 67);
  val it = () : unit
  -  extract (a, 0, 5);
  val it = "\000AAAA" : string
  - 

  If update is not called at top level, it seems to work:

  - fun foo (a, m, n) = update (a, m, n);
  val foo = fn : bytearray * int * int -> unit
  - foo(a, 0, 67);
  val it = () : unit
  - extract (a, 0, 5);
  val it = "CAAAA" : string
  - 
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 715
Title: chdir often doesn't work on strings of length 0 mod 4
Keywords: System, directory
Submitter:      Andrew Tolmach (apt@cs.pdx.edu)
Date:		11/6/92
Version:        0.90 (and perhaps earlier versions)
System:         all
Severity:       minor
Problem:        chdir often doesn't work on strings of length 0 mod 4
Code:           
System.Unsafe.CInterface.chdir "abcd";    (* this directory does exist *)

Transcript:     

% sml
Standard ML of New Jersey, Version 0.90 September 22, 1992
val it = () : unit
- System.Unsafe.CInterface.chdir "abcd";   (* this directory does exist *)

uncaught exception SysError
- 
Comments: Caused by failure to call c_string on argument to chdir in 
boot/perv.sml.  String seen by C may have arbitrary garbage after it.
Fix:  Replace

  val chdir : string -> unit = c_function "chdir"

by 

  val chdir : string -> unit = c_function "chdir" o c_string

in boot/perv.sml.
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 716
Title: overflow on real operation crashes sml on sparc
Keywords: float, overflow, sparc
Submitter:      Masahiro YASUGI < yasugi@is.s.u-tokyo.ac.jp >
Date:		11/27/92
Version:        Standard ML of New Jersey, Version 75, November 11, 1991
System:         Sun4/SunOS Release 4.1.1-JLE1.1.1RevB
Severity:       rare
Problem:        An overflow on real number in sequential execution causes
		a crash of sml.
Code:
		fun bug r = ( r * r; r:real );
		bug 1.0E160;
	or
		fun bug r = ( r /0.0; r );
		bug 1.0;
Transcript:
		% sml
		Standard ML of New Jersey, Version 75, November 11, 1991
		Arrays have changed; see Release Notes
		val it = () : unit
		- fun bug r = ( r /0.0 ; r :real );
		val bug = fn : real -> real
		- bug 1.0;
		Segmentation fault
		%
Comments:	It seems to be a lower-level problem.
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 717
Title: records always evaluated in alphabetical order
Keywords: records, evaluation
Submitter:      Thomas Yan, tyan@cs.cornell.edu
Date:           12/10/92
Version:        0.92
Severity:       major
Problem:        records always evaluated in alphabetical order
Code:           val _ = {b= print "1", a = print "2"}
Transcript:     - val _ = {b= print "1", a = print "2"};
                21
                -
Comments:       aren't records supposed to be evaluated in the order they
                appear in program text?
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 718
Title: accepts type incorrect program, crashes
Keywords: types, type checking, crash
Submitter: Norman Neff    neff@trenton.edu
Date:    	1/26/93
Version:        0.75
System:         Sun SPARC 1+     Sun OS 4.1.1
Severity:       critical
Problem:        compiler accepts type-incorrect program, execution nonterminates
Code:           <example code that reproduces the problem>

(* binary arithmetic *)
val max'digits=100;
    
structure Bins (*:
    sig
    exception add'oflow
    exception doub'oflow
    exception expadd'oflow
    exception btr'oflow
    exception btd'oflow
    val add'2 : ByteArray.bytearray * ByteArray.bytearray -> ByteArray.bytearray
    val subtract'2 : ByteArray.bytearray * ByteArray.bytearray -> ByteArray.bytearray
    val binary'to'int : ByteArray.bytearray -> int
    val is'zero : ByteArray.bytearray -> bool
    val binary'to'real : ByteArray.bytearray -> real
    val int'to'binary : int -> ByteArray.bytearray
    val real'to'binary : real -> ByteArray.bytearray
    val expadd : int * ByteArray.bytearray -> ByteArray.bytearray
    val double : ByteArray.bytearray -> ByteArray.bytearray
    val less'2 : ByteArray.bytearray * ByteArray.bytearray -> bool
    val lesseq'2 : ByteArray.bytearray * ByteArray.bytearray -> bool
    val print'2 : ByteArray.bytearray -> unit
    val zero : unit -> ByteArray.bytearray
    infix add'2 subtract'2 less'2 lesseq'2
  end *)=
let
    open ByteArray;
  in
  struct 
       exception expadd'oflow
       exception add'oflow
       exception doub'oflow
       exception rtb'oflow
       infix add'2 less'2 lesseq'2 subtract'2 quot'rem div'2
       fun print'2 n=revapp print n
       fun zero {}= array(max'digits,0);
       fun expadd(exponent,number)=
         (* destructively add 2**exponent to number *)  
           let
	       fun up({},pos,carry)=
		   if carry=0 then {}
		   else if pos >= max'digits then raise expadd'oflow
			else if (number sub pos)=0 then 
			    up(update(number,pos,1),pos+1,0)
			     else up(update(number,pos,0),pos+1,1)
	       val dummy=  up({},exponent,1)
	   in
	       number
           end;
       fun add(n1,n2,carry'expect)=
	   let val ans=zero{};
	       fun col({},i,carry)=if (i < max'digits) then
		   case ((n1 sub i)+(n2 sub i)+carry) of
		       0 => col({},i + 1, 0)
		     | 1 => col(update(ans,i,1),i + 1, 0)
		     | 2 => col(update(ans,i,0),i + 1, 1)
		     | 3 => col(update(ans,i,1),i + 1, 1)
				   else if carry=carry'expect then ans
					else raise add'oflow
	   in
	       col({},0,0)
	   end
       fun n1 add'2 n2 = add(n1,n2,0)
       fun succ n=let val ans=n add'2 (zero{});
		  in
		      expadd(0,ans)
		  end
       val ONE=succ (zero{});
       fun double n= let val ans=zero{};
			 fun col({},i)=
		     if ((i >= max'digits) andalso (n sub (i-1))=1) then
			 raise doub'oflow
		     else if (i < max'digits) then
			 col(update(ans,i,n sub (i - 1)),i + 1)
			  else ans
		     in
			 col({},1)
		     end
       fun twos'complement n=let
           val one'comp=zero{}
	   fun col({},i)=if (i < max'digits) then
	       col(update(one'comp,i,1-(n sub i)),i+1)
			 else one'comp
			     in
				 expadd(0,col({},0) )
			     end
       fun is'zero n=let fun f (a, b) =((a=0) andalso b)
		     in
			 fold  f  n true
		     end
       fun n1 subtract'2 n2=if  (is'zero n2) then (n1 add'2 zero{})
			    else add(n1,twos'complement n2,1)
       local fun cp(n1,n2,ms)=if ms<0 then true
               else if (n1 sub ms)<(n2 sub ms) then true
               else if (n1 sub ms)>(n2 sub ms) then false
               else cp(n1,n2,ms - 1)
           in
               fun op lesseq'2(n1,n2)=cp(n1,n2,max'digits-1)
	       fun op less'2(n1,n2)=not (cp(n2,n1,max'digits-1))
       end
       fun a quot'rem b=if (a less'2 b) then (zero{},a)
		     else let val (q,r)= a quot'rem (double b)
			  in
			      if (r less'2 b) then (double q,r)
			      else ((double q) add'2 ONE,
				    r subtract'2 b)
			  end
       fun a div'2 b=let val (q,r)=(a quot'rem b)
		     in
			 q
		     end
       exception rtb'oflow
       fun int'to'binary 0 = zero{}
	 | int'to'binary x =
	   if ((x mod 2)=0) then double (int'to'binary (x div 2))
	   else succ (double (int'to'binary (x div 2)))
       fun real'to'binary 0.0=zero()
	 | real'to'binary x=
	   let val lx =(ln x)/(ln 2.0)
	       val sigbits=30.0 (*supported by both int & float *)
	       val shift=ceiling(lx-sigbits)
	       fun sh2 0 binbase=binbase add'2 (zero{})
		 | sh2 n binbase=double(sh2 (n-1) binbase)
	       fun exp2 lx=
		   if (lx < sigbits)
		       then  int'to'binary(floor
			      (exp (lx * (ln 2.0)) + 0.5) )
		   else (sh2 shift (exp2 (lx-  shift)))
 (* BUG : should be                      (lx - (real shift))    *)
	   in
	      ( exp2 lx) handle doub'oflow => raise rtb'oflow 
	   end
       val TWO=succ ONE
	   exception btd'oflow
       fun binary'to'int n=
	   if is'zero(n) then 0
	   else if is'zero(n subtract'2 ONE) then 1
		else let val (q,r)=n quot'rem TWO
		     in
			 (if is'zero(r) then 2*(binary'to'int q)
			  else 1 + 2*(binary'to'int q)) handle
			      Overflow =>raise btd'oflow
		     end
		 exception btr'oflow
       fun binary'to'real n=
	   if is'zero(n) then 0.0
	   else if is'zero(n subtract'2 ONE) then 1.0
		else let val (q,r)=n quot'rem TWO
		     in
			 (if is'zero(r) then 2.0*(binary'to'real q)
			  else 1.0 + 2.0*(binary'to'real q)) handle
			      Overflow =>raise btr'oflow 
		     end	   
  end
end
open Bins;

val d=real'to'binary 1E12;
    

Transcript:     <transcript of session illustrating problem>
NOTE: Emacs, Inferior Smld 


Standard ML of New Jersey, Version 75, November 11, 1991
Arrays have changed; see Release Notes
val it = () : unit
- emacsInit (); cd "/home/snuffy/faculty/neff/geom/";
val it = () : unit
val it = () : unit
- use "bug.sml";
[opening bug.sml]
val max'digits = 100 : int
bug.sml:53.6-57.43 Warning: match not exhaustive
        0 => ...
        1 => ...
        2 => ...
        3 => ...
structure Bins : 
  sig
    exception add'oflow
    exception btd'oflow
    exception btr'oflow
    exception doub'oflow
    exception expadd'oflow
    exception rtb'oflow
    val ONE : ?.Dummy.A.bytearray
    val TWO : ?.Dummy.A.bytearray
    val add : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray * int -> ?.Dummy.A.bytearray
    val add'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val binary'to'int : ?.Dummy.A.bytearray -> int
    val binary'to'real : ?.Dummy.A.bytearray -> real
    val div'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val double : ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val expadd : int * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val int'to'binary : int -> ?.Dummy.A.bytearray
    val is'zero : ?.Dummy.A.bytearray -> bool
    val less'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> bool
    val lesseq'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> bool
    val print'2 : ?.Dummy.A.bytearray -> unit
    val quot'rem : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray * ?.Dummy.A.bytearray
    val real'to'binary : real -> ?.Dummy.A.bytearray
    val subtract'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val succ : ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val twos'complement : ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray
    val zero : unit -> ?.Dummy.A.bytearray
    infix add'2
    infix div'2
    infix less'2
    infix lesseq'2
    infix quot'rem
    infix subtract'2
  end
open Bins

NOTE: After several minutes of non-response, interrupt produced:  

Process Inferior smld bus error


Comments: I suspect that part of the problem is ceiling, which shows
type   real->'a   rather than what is in the specs
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 719
Title: weakness zero polymorphism allowed in structures
Keywords: types, weak types, polymorphism
Submitter: Andrew Wright (wright@cs.rice.edu)
Date: 1/26/93
Version: 0.93
Severity: Critical (type checking error)
Problem: 
In playing around with version 92, I noticed that the following
code type checks, assigning f the type '0Z -> '0Z.
This code is rejected by version 75.
Code: 
  structure Foo = struct
   val f = ! (ref (fn x => x))
  end
Comments:
  Is this a bug?  Or are you intending to extend SML to allow this
  structure to match the signature:

  signature FOO = sig
   val f : int -> int
  end
  [dbm] It's a bug.
Fix: change line 1014 of elaborate/elabstr.sml, replacing "isTop kind"
     with "true".
Status: fixed in 0.93
----------------------------------------------------------------------
Number: 720
Title: when opening a structure at top-level, types are not printed
Keywords: open, top level, printing
Submitter: 	John Reppy (jhr@research.att.com)
Date: 		1/29/93
Version: 	0.92 (and pre-release 0.93)
System: 	any
Severity: 	minor
Problem: 	when opening a structure at top-level, types are not printed
Transcript: 
  Standard ML of New Jersey, Version 0.93, February 1, 1993
  val it = () : unit
  - structure Foo = struct datatype t = T of int val x = T 0 end;
  structure Foo :
    sig
      datatype t
        con T : int -> t
      val x : t
    end
  - open Foo;
  open Foo
  val x = T 0 : t
  -
Comments: [dbm] Currently only the dynamic elements of a structure
  are printed when the structure is opened at top level.  This is a side effect
  of the fact that all dynamic components are being rebound in the toplevel
  environment.  This is the same as bug 666.
Fix: perform special printing for open, suppressing the printing due
  to the rebinding of dynamic components.
Owner: dbm
Status: fixed in 109.31 [dbm, 7/15/97]
----------------------------------------------------------------------
Number: 721
Title: Local weakness 0 typing rejected.
Keywords: types, weak types
Submitter: Mark Lillibridge (mdl@cs.cmu.edu)
Date: 2/1/93
Version: 0.93
Severity: critical
Problem: 
  Local weakness 0 typing rejected.
Code: 
  local val f = !(ref(fn x =>x)) in val y = 3 end;
Transcript: 
  - local val f = !(ref(fn x =>x)) in val y = 3 end;
  std_in:2.7-2.30 Error: nongeneric weak type variable
    f : '0Z -> '0Z
Comments:
  On the other hand, the following code should be rejected, because
  context across structure boundaries is not allowed.

    local structure Foo = struct val f = !(ref(fn x=> x)) end
    in val y = 3 end;

  See also bug 719.

Status: fixed in 1.02
----------------------------------------------------------------------
Number: 722
Title: core dump (illegal instruction) on Sun 3, NeXT loading smlnj-lib
Keywords: illegal instruction, crash
Submitter: Tom Kirk, Dave MacQueen
Date: 2/6/93
Version: 0.93
System: NeXT 3.0, Sun 3/SunOS 4.1.1
Severity: critical
Problem: 
  Core dumps while loading the smlnj library.
Transcript: (in the smlnj-lib directory)
  iota$ sml
  Standard ML of New Jersey, Version 0.93, February 1, 1993
  val it = () : unit
  - use "load-all";
  ...
  [Increasing heap to 6702k]
  structure Format : FORMAT
  [opening string-util-sig.sml]
  signature STRING_UTIL =
    sig
      exception NotFound
      val index : string -> string * int -> int
      ...
    end
  [opening string-util.sml]

  [Major collection... 18% used (1014324/5486980), 3920 msec]
  Illegal instruction
  iota$
Comments:
  Bug is repeatable.  Happens just after opening string-util.sml every
  time.
Status: fixed in 0.93 (Lal George)
----------------------------------------------------------------------
Number: 723
Title: obsolete components of System.Print and System.Control
Keywords: obsolete components
Submitter: Dave MacQueen
Date: 2/6/93
Version: 0.93
Severity: Minor
Problem: 
  The obsolete component System.Print.pathnames has not been deleted.
Comments:
  System.Control.Print is also redundant now.
Fix: delete these components from system.sig and perv.sml.
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 724
Title: minor prettyprinting bug
Keywords: printing, prettyprint
Submitter: John Reppy
Date: 2/7/93
Version: 0.93
Severity: minor
Problem: 
  Consider the following output from the pretty printer:

  structure PolyHashTable :
    sig
      datatype ('a,'b) bucket_t
	con B : int * 'a * 'b * ('a,'b)bucket_t -> ('a,'b)bucket_t
	con NIL : ('a,'b)bucket_t
   ...

  The "('a,'b)" has a space following it in the datatype line, but not
  in type expressions.
Status: fixed in 0.93 (dbm)
----------------------------------------------------------------------
Number: 725
Title: fragility of quote/antiquote implementation
Keywords: 
Submitter: Andrew Appel
Date: 2/2/93
Version: 0.93
Severity: major
Problem: 
  One can redefine the QUOTE constructor, and this imposter will then
  be used in the expansion of quotations.
Code: 
Transcript: 
  Standard ML of New Jersey, Version 0.93, February 1, 1993
  val it = () : unit
  - System.Control.quotation:=true;
  val it = () : unit
  -  datatype 'a frag = QUOTE of string | ANTIQUOTE of 'a | NOTHING;
  datatype  'a frag
    con ANTIQUOTE : 'a -> 'a frag
    con NOTHING : 'a frag
    con QUOTE : string -> 'a frag
    -
  - val j = `hello`;
  val j = [QUOTE "hello"] : 'a frag list
  - fun f NOTHING = "none" | f (QUOTE s) = s;
  std_in:6.1-6.40 Warning: match nonexhaustive
	    NOTHING => ...
	    QUOTE s => ...

  val f = fn : 'a frag -> string
  - map f j
  = ;
  val it = ["hello"] : string list
Fix: make sure the expansion uses the 'real' QUOTE constructor.  Don't
     just pick it up from the current top-level environment.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 726
Title: non-polymorphic function in scope of recursive def (not a bug)
Keywords: type checking
Submitter: Tim Sheard (sheard@cse.ogi.edu, 503-690-1439)
Date: 2/11/93
Version: 0.93
Severity: major
Problem: 
There seems to be a bug in the type checker for sml version 0.93
run on a sparc station. Consider the two declarations below, When I attempt 
to compile them the second one causes a type error. 
Code: input file  "/projects/pacsoft/tools/crml/bugs/smlreport"

  datatype 'a test
    = C1test of (string * 'a test) list
    | C2test of (('a test) list) * 'a;

  val map_test = 
   let fun map_list a_f [] = []
	 | map_list a_f (x1::x2) = (a_f x1)::(map_list a_f x2)
       and map_test a_f (C1test x1) =
            C1test (map_list (fn (y1,y2) => (y1,map_test a_f y2)) x1)
	 | map_test a_f (C2test (x1,x2)) =
	     C2test (map_list (map_test a_f) x1,a_f x2)
  in  map_test end;

Transcript: 
  Standard ML of New Jersey, Version 0.93, February 1, 1993
  val it = () : unit
  -
  - use "/projects/pacsoft/tools/crml/bugs/smlreport";
  [opening /projects/pacsoft/tools/crml/bugs/smlreport]
  datatype  'a test
    con C1test : (string * 'a test) list -> 'a test
    con C2test : 'a test list * 'a -> 'a test
    /projects/pacsoft/tools/crml/bugs/smlreport:13.49-13.83 Error: operator and operand don't agree (tycon mismatch)
    operator domain: string * 'Z test -> string * 'Y test
    operand:         'Z test -> 'Y test
    in expression:
      map_list (map_test a_f)
  [closing /projects/pacsoft/tools/crml/bugs/smlreport]
  -

yet if I type the following, without mutual recursion:

  - val map_test = 
  =  let fun map_list a_f [] = []
  =        | map_list a_f (x1::x2) = (a_f x1)::(map_list a_f x2)
  =      fun map_test a_f (C1test x1) =
	      C1test (map_list (fn (y1,y2) => (y1,map_test a_f y2)) x1)
  =        | map_test a_f (C2test (x1,x2)) =
	      C2test (map_list (map_test a_f) x1,a_f x2)
  =  in map_test end;
  val map_test = fn : ('a -> 'b) -> 'a test -> 'b test
  - 

  it compiles ok. In this example I don't need mutual recursion but for more
  complicated ones I do. I tried to reproduce the error with the smallest example
  I could find.
Comments: [dbm]
SML doesn't allow you to use a function polymorphically in its
own (mutually) recursive definition.  It would be possible to relax
this restriction (Milner-Mycroft type system), but then typing is
undecideable (Kfoury & Tiuryn).  One could find a pragmatic way around
this that would generally work fine (CAML (Light?) does), but it
doesn't seem to be a critical need in practice, at least in our
experience.
Status: not a bug, but a fact of life
----------------------------------------------------------------------
Number: 727
Title: printing sharing constraints in signature
Keywords: modules, signatures, sharing, printing
Submitter: Dave MacQueen
Date: 2/11/93
Version: 0.93
Severity: minor
Problem: 
Code: (based on $sml/testing/modules/tests/test64.sml)
functor F (X : sig end) = X;

structure A =
  struct type t = int
  end;

structure B = F (A);

signature S =
  sig structure C : sig type t end
      sharing C = B
  end;

Transcript: 
- use "bug727.sml";
[opening bug727.sml]
functor F : <sig>
structure A : sig eqtype t end

structure B : sig  end
signature S =
  sig
    structure C : ...
    sharing C = ?.B.<Parameter>    (* bogus printout of B *)
  end
val it = () : unit
- 
Comments:
  The problem is that the internal path of structure B is reversed:
  "<Parameter>.B" instead of "B.<Parameter>".
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 728
Title: opening a structure with substructure of same name at top level
Keywords: modules, open, top level, scoping
Submitter: Dave MacQueen, John Reppy
Date: 2/15/93
Version: 0.93
Severity: minor?
Problem: 
  Opening a structure at top level when the structure has a substructure
  of the same name may cause an error
Code: 
  structure A :
    sig
      structure A : sig end
      structure B : sig end
    end =
  struct
    structure A = struct end
    structure B = struct end
  end;

  open A;  (* at top level *)

Transcript: 

  Standard ML of New Jersey, Version 0.93, February 12, 1993
  val it = () : unit
  - use "bug728.sml";
  [opening bug728.sml]
  structure A :
    sig
      structure A : ...
      structure B : ...
    end
  bug728.sml:11.1-11.6 Error: unbound structure: B in path A.B
  -

Fix: In elaborate/elabstr.sml, locally rebind the new structure
to a special name and use this special name as the intermediary
in rebinding the components.  E.g. in the above example, the
redeclarations  produced by "open A" take the form

  local structure %str% = A
  in structure A = %str%.A
     structure B = %str%.B
  end

instead of the erroneous

  structure A = A.A
  structure B = A.B  (* no A.B found *)

Status: fixed in 0.93  (except didn't make into Mac version *)
----------------------------------------------------------------------
Number: 729
Title: include causes type sharing violation
Keywords: modules, signatures, include, sharing
Submitter: 		Alexander Horz (GMD; horz@gmd.de)
Date: 			8/3/93
System(s) and Version:	smlsg, noshare
SML/NJ Version: 	0.93
Machine: 		sparc, sunos
Severity: 		**** critical ****
Problem: 		

*serious* problem with "include" in functor declarations: 

after successfully compiling

	signature TERM = sig ... end

and

        functor Term (...) : TERM = struct ... end

there is no problem in compiling

        structure Terms2 : TERM = Term( ... )

However, when replcaing the second piece of code by

     	functor Term(...) :sig include TERM val comp ... end = struct ... end

the compiler produces a mysterios error message (see, below) instead
of successfully compiling 

        structure Terms2 : TERM = Term( ... )
 
I cut the original code down to a sufficiently small length. The error
producing code is split into three files: file "TERM.sml" contains all
the signatures, file "Term.sml" the Term functor, and file example
contains the code for the example application of Term that produces
the error message, presented at the end.

Code: (bug729.sml: a short version. bug729a.sml contains original version)

signature ELEMENT =
sig
  type t
  val put : unit  (* necessary *)
end;

signature TERM =
sig
  structure S : sig 
	          include ELEMENT
		end
  type subst
  sharing type subst = S.t
end;

functor Term () : sig include TERM end = (* ": TERM" works ok *)
struct
  structure S =
  struct
    datatype t = C   (* must be datatype -- "type t = unit" works ok *)
    val put = ()
  end

  type subst = S.t
end;

structure Terms : TERM = Term();  (* signature ": TERM" necessary *)


Transcript: (in 103d)

- use "bug729.sml";
[opening b.sml]
signature ELEMENT =
  sig
    type t
    val put : unit
  end
signature TERM =
  sig
    structure S : ...
    type subst
    sharing type S.t = subst 
  end
functor Term : <sig>
b.sml:30.11-30.31 Error: type sharing violation
  S.t # subst
- 

Status: fixed in 105
----------------------------------------------------------------------
Number: 730
Title: reappearance of bug 705 on RS/6000
Keywords: rs6000, emacs
Submitter:          Cliff Krumvieda (cliff@cs.cornell.edu)
Date:               2/19/93
System and Version: Compiler
SML/NJ Version:     0.93
Machine:            IBM RS/6000, AIX 3.2
Severity:           Major (IMHO)
Problem: 
  Bug number 705:
    sml emacs subprocess dies when file is "used" (on some SGI machines)
  seems to have migrated to the IBM RS/6000.  It wasn't present in
  0.92.

Transcript:
======================================================================
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- use "bleg";

Quit (no coredump)

Process Inferior cml finished
======================================================================
Owner: 
Status: open
----------------------------------------------------------------------
Number: 731
Title: exportML seems to be incorrectly searching paths
Keywords: exportML, paths
Submitter:          Cliff Krumvieda (cliff@cs.cornell.edu)
Date:               2/19/93
System and Version: Compiler
SML/NJ Version:     0.93
Machine:            IBM RS/6000, AIX 3.2
Severity:           Minor

Problem: 
  exportML seems to be incorrectly searching paths.  I have no
  idea why it is doing so or even why it is searching paths in
  the first place.

Transcript(s):
====================================================================== 
[~plg/bin/rs6000] bashful% which ml-93
./ml-93
[~plg/bin/rs6000] bashful% ml-93
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- exportML "/usr/u/cliff/temp2/temp";

[Major collection... 99% used (558432/563108), 200 msec]

[Major collection... 99% used (560200/560368), 170 msec]
chaseLinks: Could not find executable in path!
export: getaoutname failed

uncaught exception Io "exportML "/usr/u/cliff/temp2/temp": No such file or directory"
- 
======================================================================
[~plg/bin/rs6000] bashful% which sml-93
/home/plg/bin/sml-93
[~plg/bin/rs6000] bashful% sml-93
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- exportML "/usr/u/cliff/temp2/temp";

[Major collection... 99% used (558432/563096), 190 msec]

[Major collection... 99% used (560188/560356), 160 msec]
val it = false : bool
- 
======================================================================

Comments:
  /home/plg/bin/sml-93 is a link to ~plg/bin/rs6000/sml-93.
  Note that both sml-93 and ml-93 are on my search path, but ml-93
  is only in ./ml-93.  This problem doesn't exist on our Suns, but 
  it did exist in 0.92 (I just hadn't noticed it before).
Owner: John
Status: fixed in 109.21 [new runtime]
----------------------------------------------------------------------
Number: 732
Title: Info.search does nothing but raise an exception
Keywords: Info, environment
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           2/19/93
Version:        0.93
Problem:        Info.search does nothing but raise an exception
Code:           Info.search "info"
Transcript:     
    - Info.search "info";
    <Argument> unbound
    
    uncaught exception Info
the problem involves sourcegroup.  Info works fine if loaded by itself; if
loaded after sourcegroup, then there is a problem:
    
    agnar% sml
    Standard ML of New Jersey, Version 0.93, February 15, 1993
    SML/NJ Library, Version 0.1, February 1, 1993
    SourceGroup 3.0
    val it = () : unit
    - Info.search "";
    
    signature ABSYN
    signature ANALYZE
    (* etc. *)
    functor AbSynFun
    functor AnalyzeFun
    (* etc. *)
    structure AbSyn
    structure AbSyn.<Argument>
    <Argument> unbound
    
    uncaught exception Info
    - 
Also, from Eric Madelaine <Eric.Madelaine@sophia.inria.fr>:
Transcript: (in sml-sg)
- Info.info["INFO"];
signature INFO =
  sig
    exception Info
    val info : string list -> unit
    val search : string -> unit
  end

- Info.search"make";
<Argument> unbound

uncaught exception Info
-
Fix: (from Thomas Yan)
  here is a workaround (?fix): go on in spite of the "error".
  in the definition for search, add the line marked by (* *)

	    if typ = "structure" then 
              let val (subEnv,_) = strToEnv' [nom] env
	      in search (nom::path,subEnv) (catalogEnv (staticPart subEnv)) end
  (* *)	      handle Info => print "going on in spite of error...\n"
	    else ();

Owner: Dave
Status: obsolete [Info has to be reimplemented]
----------------------------------------------------------------------
Number: 733
Title: ml crashes -- (?) interaction between gc and system calls
Keywords: crash
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           2/22/93
Version:        0.93
System:         hppa
Severity:       major
Problem:        ml crashes -- (?) interaction between gc and system calls
Code:           see /dist/ml/incoming/tyan-bug.tar
Transcript:     
        handel% sml < load.sml
        Standard ML of New Jersey, Version 0.93, February 15, 1993
        SML/NJ Library, Version 0.1, February 1, 1993
        Concurrent ML -- version 0.9.8 -- February 1, 1993
        SourceGroup 3.0
        val it = () : unit
        - [opening timeit.sml]
        structure Timing (* etc. *)
        [opening test.sml] (* etc. *)
        val it = () : unit
        =
        [Major collection... 89% used (7571036/8482908), 2150 msec]
        
        [Increasing heap to 22186k]
        
        [Major collection... 99% used (7629928/7647148), 2283 msec]
        
        [Increasing heap to 22370k]
        Segmentation fault (core dumped)
Comments:       while trying to isolate the problem, i noticed it appeared
                sporadically, and was most likely to occur when starting with a
                small heap, e.g. using an executable from exportFn, and not,
                say, after a compilation/run that had already expanded the
                heap.  to run the example, just use "load.sml".
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 734
Title: bug in profiler
Keywords: profiler
Submitter: 		Lal George
Date: 			3/3/93
System(s) and Version:	tools/prof
SML/NJ Version: 	0.93
Severity: 		major
Problem: 		

   I compiled a lot of code under the profiler and found that working
   programs were going into an infinite loop. Specifically, Intmap.rmv
   would increase the number of elements in the hash-table!

Comment:

  The profile_script contains the following:

  structure Ref = 
  struct 
     open Ref
     fun inc i = i := !i + 1
     fun dec i = i := !i + 1
  end
Status: fixed in 0.94 (later versions of) 0.93
----------------------------------------------------------------------
Number: 735
Title: bad type error message
Keywords: types, type checking, error messages
Submitter:              Anne Rogers (amr@princeton.edu)
Date:                   3/5/93
System(s) and Version:  Compiler (0.93)
SML/NJ Version:         0.93
Machine:                any
Severity:               minor
Problem:                poor type error message
Code:
   abstype 'a set = SET of 'a list
   with
      val empty : 'a set = SET nil
       fun member (x: 'a, SET l: 'a set, equal : 'a * 'a-> bool):bool =
       case l
       of nil => false
        | y ::m => if equal(x, y) then true else member(x, SET m)
   end;
Transcript:
  std_in:33.5-36.60 Error: pattern and expression in val rec dec don't
agree (tycon mismatch)
    pattern:    'aU * 'aU set -> bool
    expression: 'aU * 'aU set * ('aU * 'aU -> bool) -> bool
    in declaration:
      member =
        (fn (<pat> : 'aU,<pat> : 'aU set,<pat> : 'aU * 'aU -> bool) =>
            ((case l
               of <pat> => <exp>
                | <pat> => <exp>): bool))

Comments:
  The types given for the pattern and expression seem to be backwards.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 736
Title: declaration printing with OR pattern
Keywords: patterns, OR, printing
Submitter: Dave MacQueen
Date: 3/13/93
Version: 0.94
Severity: major
Problem: 
  Binding created by OR pattern is not printed.
Transcript: 
- val ([x]|_::x::_) = [1];
std_in:5.1-5.23 Warning: binding not exhaustive
          (:: (x,nil) | :: (_,:: (<pat>,<pat>))) = ...
- 
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 737
Title: Compiler bug: Instantiate:explore_tclass.5
Keywords: modules, signatures, instantiation
Submitter: 		Alan Smaill, smaill@lfcs.ed.ac.uk 
Date: 			3/22/93
SML/NJ Version:         0.93
Machine: 		sparc/unix 
Severity: 		critical
Problem: 		compiler error 
Code:

  signature S0 =
  sig
    type t
  end;

  signature S1 =
  sig
    structure A : S0
  end;

  functor F (X: S0) : S0 =   (* result signature necessary *)
  struct
    open X (* necessary, "type t = X.t" won't do *)  
  end;

  structure B = F(struct type t = unit end);
      (* must be defined by functor application *)

  functor G(structure Y: S1 sharing Y.A = B) = struct end;

Transcript: 		
  - use "bug737.sml";
  [opening a.sml]
  signature S0 = sig type t end
  signature S1 = sig structure A : ... end
  functor F : <sig>
  structure B : S0
  Error: Compiler bug: Instantiate:explore_tclass.5
Comments:		compiles OK under 0.75
Fix: (Pierre Cregut)
In sigmatch.sml comment out
(*	  val _ =
	    if self then (
	      case oldEnv
	      of SOME (env,sigenv,strs) => 
		   (* The meaning of this hack is the following:
		      If the structure is a self but belongs to a functor
		      then it may contain a useless and big INSTANCE used
		      as an intermediate structure for open.
		      This function destroys such instances and replace them
		      by a dummy structure. *)
		   let fun clrOpen n = (
			 case Array.sub(strs,n) 
		         of INSTANCE{path as _ :: _, ...} =>
			      if Symbol.eq(name_O,last path) then 
				(Array.update(strs,n,ERROR_STR);clrOpen (n+1))
			      else clrOpen (n+1)
			  | _ =>  clrOpen (n+1)) handle Array.Subscript => ()
		       val thinenv = ref Env.empty
		       (* Note: it would be nice if Env.map gave also the
			  symbol to the argument function *)
		       val _ = 
			 Env.app 
			   (fn (name,_) =>
			      thinenv := Env.bind(name,Env.look(!env,name),
						      !thinenv)
			      handle Env.Unbound => ())
			   sigenv
		   in env := Env.consolidate(!thinenv) ;  clrOpen 0 end
	       | NONE => ())
	    else ()	*)
--------------------------------

It is more than a hack, it is a bug. In normal cases nothing happens,
but if you use the result of such an object to make a sharing constraint,
then the origin on which the hack has been done, will become the target
of the study...

... and one will discover that there are dummy structures instead of real
ones. So if there is a type exported, here t, this one will need the structure
to find its definition (it is an OPENFORMtyc created in elabstr.sml by
the function openStruct) and, as there is nothing, unexpected errors occurs.

Well the conclusion is that a usefull optimization is now impossible :-(

Pierre

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 738
Title: Compiler Error : [SparcCM.fetchindexl]
Keywords: code generation
Submitter:      Ju:rgen Buntrock
Date:		 3/22/93
Version:        0.93
System:         SPARCstation 2   (4/75)
		SunOS Release 4.1.2
		64Mbyte Ram
Severity:       critical
Problem:        Compiler Error : [SparcCM.fetchindexl] 
Comments:	The Compiler calls some times fetchindexl
		with (ImmedLab lab, Direct dst, Immed i)
Fix:
	output from diff -c :


*** ../src.org/sparc/sparc.sml  Wed Jan 27 20:41:53 1993
--- sparc/sparc.sml     Tue Feb 23 23:36:02 1993
***************
*** 496,501 ****
--- 496,504 ----
            emit_ld (r, REGrand tmpR1, dst);
            freeTmpReg tmpR1
          end
+       | fetchindexl (ImmedLab lab, Direct dst, Immed i) =
+             loadAddr (lab, 2*(i-1), dst)
+ 
        | fetchindexl _ = ErrorMsg.impossible "[SparcCM.fetchindexl]"
  
    (*storeindexl (x, y, z) stores a word:  mem[y+2*(z-1)] <- x *)

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 739
Title: Need nonblocking IO
Keywords: I/O, nonblocking
Submitter:      Ju:rgen Buntrock
Date:		 3/22/93
Version:        0.93
System:         SPARCstation 2   (4/75)
		SunOS Release 4.1.2
		64Mbyte Ram
Severity:       major
Problem:        I need non blocking IO. There is a usefull
		function in cfuns.c :
		ml_writei : (int * bytearray * int * int) -> unit
		but I need the number of Bytes written!
Fix:
		I have wriiten a function
		ml_writeiraw : (int * bytearray * int * int) -> int

	output from diff -c :
diff -c runtime/cfuns.c.org runtime/cfuns.c
*** runtime/cfuns.c.org Wed Jan 27 20:41:17 1993
--- runtime/cfuns.c     Mon Mar 22 18:05:10 1993
***************
*** 567,573 ****
--- 567,593 ----
  
  } /* end of ml_writei */
  
+ /* ml_writeiraw : (int * bytearray * int * int) -> unit
+  * Write data from the given bytearray to the specified file, starting at the
+  * given offset.  This routine is not guaranteed to write all the bytes.
+  */
+ void ml_writeiraw (msp, arg)
+     MLState_ptr     msp;
+     register ML_val_t arg;
+ {
+     int             sts;
  
+     int             fd = REC_SELINT(arg, 0);
+     char            *buf = (char *)REC_SELPTR(arg, 1);
+     char            *start = buf + REC_SELINT(arg, 2);
+     int             nbytes = REC_SELINT(arg, 3);
+ 
+     sts = write (fd, start, nbytes);
+     CHK_RETURN(msp, sts);
+ 
+ } /* end of ml_writeiraw */
+ 
+ 
  #ifndef HAS_WRITEV
  struct iovec {
      char          *iov_base;
***************
*** 1802,1807 ****
--- 1825,1831 ----
        FUNCTION (ml_readi,         "readi"),
        FUNCTION (ml_write,         "write"),
        FUNCTION (ml_writei,        "writei"),
+       FUNCTION (ml_writeiraw,     "writeiraw"),
        FUNCTION (ml_writev,        "writev"),
        FUNCTION (ml_lseek,         "lseek"),
        FUNCTION (ml_send_obd,      "send_obd"),

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 740
Title: stat_file returns wrong time for symbolic links
Keywords: stat_file, cfuns
Submitter:      Ju:rgen Buntrock
Date:		 3/22/93
Version:        0.93
System:         SPARCstation 2   (4/75)
		SunOS Release 4.1.2
		64Mbyte Ram
Severity:       major
Problem:	stat_file (in cfuns.c) returns the wrong time
		in case of an symbolic link. This happens
		while using sourcegroup.
Fix:
	output from diff -c :
diff -c runtime/cfuns.c.org runtime/cfuns.c
***************
*** 909,915 ****
--- 929,938 ----
      int                   sts;
  
      if (OBJ_isBOXED(f))
+       /*
        sts = lstat((char *)PTR_MLtoC(f), buf);
+       */
+       sts = stat((char *)PTR_MLtoC(f), buf);
      else
        sts = fstat(INT_MLtoC(f), buf);

Owner: John
Status: fixed in 109.21 [new basis]
----------------------------------------------------------------------
Number: 741
Title: bug in readi (cfuns.c)
Keywords: readi, cfuns
Submitter:      Ju:rgen Buntrock
Date:		 3/22/93
Version:        0.93
System:         SPARCstation 2   (4/75)
		SunOS Release 4.1.2
		64Mbyte Ram
Severity:       major
Problem:	bug in readi (cfuns.c)
Fix:
*** runtime/cfuns.c.org Wed Jan 27 20:41:17 1993
--- runtime/cfuns.c     Fri Mar  5 01:46:00 1993
***************
*** 493,499 ****
      int                   nbytes = REC_SELINT(arg, 3);
      int                   n;
  
!     DO_SYSCALL (read (fd, buf, nbytes), n);
      CHK_RETURN(msp, n);
  
  } /* end of ml_readi */
--- 493,499 ----
      int                   nbytes = REC_SELINT(arg, 3);
      int                   n;
  
!     DO_SYSCALL (read (fd, start, nbytes), n);
      CHK_RETURN(msp, n);
  
  } /* end of ml_readi */

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 742
Title: ZMAGIC prefered to NMAGIC
Keywords: runtime, export
Submitter:      Ju:rgen Buntrock
Date:		 3/22/93
Version:        0.93
System:         SPARCstation 2   (4/75)
		SunOS Release 4.1.2
		64Mbyte Ram
Severity:       major
Problem:	Only on suns export.c uses NMAGIC,
		but ZMAGIC is better.
Comments:	The cpp-macro N_TXTADDR which is defined in
		/usr/include/maschine/a.out.h
		uses _N_BASEADDR :
#define _N_BASEADDR(x) \
        (((x).a_magic == ZMAGIC) && ((x).a_entry < N_PAGSIZ(x)) ? \
            0 : N_PAGSIZ(x))
		This depends on a_entry!
Fix:
		Set E.a_entry before textstart = N_TXTADDR(E);
output from diff -c :

*** runtime/export.c.org        Wed Jan 27 20:41:24 1993
--- runtime/export.c    Tue Feb 23 21:16:05 1993
***************
*** 165,171 ****
  #endif
  #else
  #if defined(sun3) || (defined(SPARC) && !defined(MACH))
!     E.a_magic = NMAGIC;
  #else
  #  if defined(NS32)
      E.a_magic = NS32GMAGIC;
--- 165,171 ----
  #endif
  #else
  #if defined(sun3) || (defined(SPARC) && !defined(MACH))
!     E.a_magic = ZMAGIC;
  #else
  #  if defined(NS32)
      E.a_magic = NS32GMAGIC;
***************
*** 190,195 ****
--- 190,198 ----
      E.a_machtype = M_SPARC;
  #endif
  
+     /* by jubu : */
+     E.a_entry = startptr;
+     /* */
      textstart = N_TXTADDR(E);
  #ifdef HPUX
      E.a_text = (int) CEIL((ETEXT+textstart),getpagesize())-textstart;
***************
*** 251,257 ****
--- 254,268 ----
  # if defined(DYNIX)
       bulletproofWrite(filid,textstart+sizeof(E),E.a_text-sizeof(E)-N_ADDRADJ(E))
  # else
+ # if defined(SUNOS)
+      if(E.a_magic = ZMAGIC){
+       bulletproofWrite(filid,textstart+sizeof(E),E.a_text-sizeof(E));
+      } else {
+       bulletproofWrite(filid,textstart,E.a_text);
+      }
+ # else
       bulletproofWrite(filid,textstart,E.a_text);
+ # endif
  # endif
  #endif !defined(SPARC) || !defined(MACH) && !defined(BSD386)
      bulletproofWrite(filid,datastart,E.a_data);

==========================================
*** makeml.org  Wed Jan 27 20:39:19 1993
--- makeml      Tue Feb 23 21:41:36 1993
***************
*** 421,427 ****
        case $OPSYS in
        SUNOS|MACH)
            DEFS="$DEFS -DBSD -Dsun3"
!           CFL="-n $F68881"
        ;;
        MORE)
            OPSYS=BSD
--- 421,427 ----
        case $OPSYS in
        SUNOS|MACH)
            DEFS="$DEFS -DBSD -Dsun3"
!           CFL="-Bstatic $F68881"
        ;;
        MORE)
            OPSYS=BSD
***************
*** 447,453 ****
        DEFS="$DEFS -DBSD -Dsun4"
        if [ $OPSYS = SUNOS ]
        then
!               CFL="-n"
        fi
        MO=${MO-"../mo.sparc"}
        MODULE="$MODULEKIND"Sparc"$DEBUG"
--- 447,453 ----
        DEFS="$DEFS -DBSD -Dsun4"
        if [ $OPSYS = SUNOS ]
        then
!               CFL="-Bstatic"
        fi
        MO=${MO-"../mo.sparc"}
        MODULE="$MODULEKIND"Sparc"$DEBUG"

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 743
Title: bus error on Sparc
Keywords: bus error, crash, sparc
Submitter:      jont@uk.co.harlqn
Date:		23/03/93
Version:        SML of NJ version 0.93
System:         Sun 4/330 with SunOS 4.1.1
Severity:       major
Problem:        Bus error
Transcript:
SIGBUS 10: bus error
stopped at      0x37b150:       ld      [%l0 + 0x8], %l1
<l0=X
                1
Comments:
This doesn't happen with the same code running under 0.75. I can send
more information, but I need to know what you want. Sending a core
file would I doubt be much use.
Owner: 
Status: not reproducible
----------------------------------------------------------------------
Number: 744
Title: exportFn doesn't export pretty-print code
Keywords: exportFn, prettyprint
Submitter:      Howard Trickey.  howard@research.att.com
Date:		3/23/93
Version:        .93, and .94a
Severity:       major (for Indian Hill application)
Problem:        exportFn doesn't export pretty-print code
		even when it is used
Code:

structure A = 
struct

datatype ctype = IntType | UintType | BooleanType | StringType 

end

signature APP =
sig
	open System.PrettyPrint
	open A

	val pp_ctype : ppstream -> ctype -> unit
	val print_ctype : ctype -> unit
end

structure App : APP =
struct

open System.PrettyPrint
open A

fun pp_ctype pps cty = (
	begin_block pps INCONSISTENT 0;
	case cty of
		  IntType => add_string pps "int"
		| UintType => add_string pps "uint"
		| BooleanType => add_string pps "boolean"
		| StringType => add_string pps "string"
		;
	end_block pps
	)

fun print_std_out ppf =
	fn x =>
	    let
		val pps = mk_ppstream {linewidth = 60,
				flush = fn () => flush_out std_out,
				consumer = outputc std_out}
	    in
		(ppf pps x; add_string pps "\n"; flush_ppstream pps)
	    end

val print_ctype = print_std_out pp_ctype

end

fun try (args : string list, env : string list) =
	let
		val t = A.IntType
	in
		App.print_ctype t
	end

Transcript:
% sml
Standard ML of New Jersey, Version 0.93, February 1, 1993
val it = () : unit
- use "bug.sml";
[opening bug.sml]
structure A :
  sig
    datatype ctype
      con BooleanType : ctype
      con IntType : ctype
      con StringType : ctype
      con UintType : ctype
  end
signature APP =
  sig
    val pp_ctype : System.PrettyPrint.ppstream -> A.ctype -> unit
    val print_ctype : A.ctype -> unit
  end
structure App : APP
val try = fn : string list * string list -> unit
  [closing bug.sml]
val it = () : unit
- exportFn ("try", try);

% try

[Increasing heap to 160k]
uncaught exception UNDEFINED
Fix: Hooks.clear should not smash prettyprinter hooks.  This problem
goes away(?) with 0.95.
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 745
Title: Prettyprinter produces bad output when printing records
Keywords: printing, prettyprint, records
Submitter: Peter F. Patel-Schneider (pfps@research.att.com)
Date: 3/11/93
Version: 0.93
Severity: minor
Problem: 
  Prettyprinter produces bad output when printing records.
Transcript: 
  val it =
    CONCEPT
      {all_rules=[],input=And [],key=ref (),local_rules=[],name="THING",
       nd=Ndescription
	    {incoherent=false,one_of=NONE,primitives=[],range=NONE,rrs=[],sas=[],
	     tests=[]},primitive=Defined} : concept

  It should be something like:

  val it =
    CONCEPT
      {all_rules=[],input=And [],key=ref (),local_rules=[],name="THING",
       nd=Ndescription
	    {incoherent=false,one_of=NONE,primitives=[],range=NONE,rrs=[],sas=[],
	     tests=[]},
       primitive=Defined} : concept
Comments:
  The examples I have seen are all of this bug, which appears to be that the
  pretty printer does not take into account whether a field stretched over a
  line, so that what should be

  {a=a,b=b,
   c=ccccccccccccccc
     cccccc,
   d=d,e=e}

  comes out as

  {a=a,b=b,
   c=ccccccccccccccc
     cccccc,d=d,e=e}

  By the way, I think that you should not retreat to

  {a=a,
   b=b,
   c=ccccccccccccccc
     cccccc,
   d=d,
   e=e}

Owner: 
Status: open
----------------------------------------------------------------------
Number: 746
Title: Compiler bug: PPVal.decon - constant datacon in decon
Keywords: printing, datatypes, top level
Submitter:  Anindya Banerjee (banerjee@cis.ksu.edu)
Date:       3/15/93
System(s) and Version:  Compiler
SML/NJ Version:         0.93
Machine:                Sparc station / Unix
Severity:               minor
Problem:                See below
Code:                 
datatype foo  =  bar of unit
   |             baz of int
              ;

datatype zip  = biz of unit;
    
Transcript: 
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- use "test.sml";
[opening test.sml]
datatype  foo
  con bar : unit -> foo
  con baz : int -> foo
datatype  zip
  con biz : unit -> zip
val it = () : unit
- bar ();
Error: Compiler bug: PPVal.decon - constant datacon in decon <----***---
- baz 3;
val it = baz 3 : foo
- biz ();
val it = biz () : zip

Tests: bug746.{1,2,3}.sml
Status: fixed in 0.97a  (same as bug 759)
----------------------------------------------------------------------
Number: 747
Title: core dump on HPPA
Keywords: crash, hppa
Submitter: Torben Mogensen (torbenm@diku.dk)
Date: 3/17/93
Version: 0.93
System: HP 9000/700 (snake)
Severity: critical
Problem: 
The following program causes core-dumps when run in SML/NJ 0.93 on a
HP "snake" workstation, but runs fine in the SPARC version. 
Code: 
  datatype Lam = VAR of int | AP of Lam * Lam | ABS of Lam

  datatype Env = ENV of (Lam * Env) list

  fun lookup (ENV en, n) = nth (en, n)

  fun krivine (VAR n,       env, s) = let val (e',env') = lookup (env, n) in
					krivine (e', env', s)
				      end
   |  krivine (AP (e1, e2), env, s) = krivine (e1, env, (e2,env)::s)
   |  krivine (ABS e,       env, s) = pop (s,e,env)

  and pop ([],e,env)      = true
   |  pop (v::s,e,ENV en) = krivine (e, ENV (v::en), s)

  fun krivine0 e = krivine (e, (ENV []), [])

  val church3   = ABS (ABS (AP (VAR 1, AP (VAR 1, AP (VAR 1, VAR 0)))))
  val lamid     = ABS (VAR 0)
  val church27  = AP (church3, church3)
  val churchbig = AP (church3, church27)
  val testexp1  = AP (AP (church27, lamid), lamid)
  val testexp2  = AP (AP (churchbig, lamid), lamid)

  local type time = System.Timer.time
	val timeofday : unit -> time = 
	    System.Unsafe.CInterface.c_function "timeofday"
   in 
  fun timeit f x = 
    let open System.Timer
	val t = start_timer()
	val rt = timeofday()
	val z = f x
	val rt' = sub_time(timeofday(),rt)
	val t' = check_timer t
	val ts = check_timer_sys t
	val tg = check_timer_gc t
     in (z,implode["non-gc user time: ",makestring t', " gc time: ", makestring tg, 
		" system time: ",makestring ts,",  real time: ",
		makestring rt',"\n"])
    end
  end

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 748
Title: Top level "local" declarations cause a space leak
Keywords: space leak
Submitter: 		Richard O'Neill <oneill@cs.sfu.ca>
Date: 			3/23/93
SML/NJ Version: 	0.93 (with SML/NJ Library 0.1')
Machine: 		NeXTstation, OS3.0
Severity: 		Major
Problem: 		Top level "local" declarations cause a space leak.
Code:

One would imagine that the two code sequences given below were more-or-less
equivalent if typed at the top level. However, in the second of the two,
the space taken by the locally declared objects are never reclaimed.

Code sequence 1:
  let
    open Array
    val arr = tabulate (32 * 1024, fn x => x)
  in
    sub (arr, 1024)
  end ;

Code sequence 2:
  local
    open Array
    val arr = tabulate (32 * 1024, fn x => x)
  in
    val it = sub (arr, 1024)
  end ;
  

Transcript:

next_mach% sml-lib
Standard ML of New Jersey, Version 0.93, February 15, 1993
    with SML/NJ Library, Version 0.1+, March 4, 1993
val it = () : unit
- (* We'll use calls to the garbage collector to show the heap growing. *)
- val gc = System.Unsafe.CInterface.gc
val gc = fn : int -> unit
- (* First, we'll show that code sequence 1 is leak-free. *)
-
- let open Array  val arr = tabulate (32 * 1024, fn x => x)
= in  sub (arr, 1024)  end ;
val it = 1024 : int
- gc 1;

[Major collection... 66% used (994440/1501008), 796 msec]
val it = () : unit
- let open Array  val arr = tabulate (32 * 1024, fn x => x)
= in  sub (arr, 1024)  end ;
val it = 1024 : int
- gc 1;

[Major collection... 66% used (994464/1501272), 734 msec]
val it = () : unit
- let open Array  val arr = tabulate (32 * 1024, fn x => x)
= in  sub (arr, 1024)  end ;
val it = 1024 : int
- gc 1;

[Major collection... 66% used (994476/1501252), 749 msec]
val it = () : unit
- (* First case clearly doesn't cause any space leak. *)
- 

- (* Second, we'll show that code sequence 2 has leak problems. *)
-
- local open Array  val arr = tabulate (32 * 1024, fn x => x)
= in    val it = sub (arr, 1024)  end ;
val it = 1024 : int
- gc 1;

[Major collection... 75% used (1125548/1493424), 843 msec]

[Increasing heap to 5504k]
val it = () : unit
- local open Array  val arr = tabulate (32 * 1024, fn x => x)
= in    val it = sub (arr, 1024)  end ;
val it = 1024 : int
- gc 1;

[Major collection... 79% used (1253796/1580392), 906 msec]

[Increasing heap to 6144k]
val it = () : unit
- local open Array  val arr = tabulate (32 * 1024, fn x => x)
= in    val it = sub (arr, 1024)  end ;
val it = 1024 : int
- gc 1;

[Major collection... 83% used (1384872/1666728), 953 msec]

[Increasing heap to 6784k]
val it = () : unit
- (* That heap just keeps on grow'in. :( *)
- ^D
next_mach%

Comments: (Andrew)
The bug report submitted by O'Neill, about local declarations causing
a space leak, seems to be fixed in 0.95.  I suspect we had staleLvars
problems in 0.93, and we rewrote that stuff in 0.94.

Status: fixed in 0.95
----------------------------------------------------------------------
Number: 749
Title: nonequality type identified as equality type
Keywords: types, equality
Submitter: Andrew Koenig (research!ark)
Date: 3/24/93
Version: 0.93
Severity: major
Problem: 
Code: 
	  signature EQTYPE  =
	      sig
		  type T
		  val eq : T * T -> bool
	      end

	  structure S: EQTYPE = struct
		  type T = int -> int
		  fun eq _ = false
	  end

  No problem so far.  Note that EQTYPE.T is not actually required to be
  an eqtype, because eq could be anything.  Now:

	  functor ProductEqTypeFUN ( structure t1 : EQTYPE and t2 : EQTYPE ) 
				  : EQTYPE =
	      struct
		  type T = t1.T * t2.T
		  val eq = op=
	      end

  SML-NJ accepts this without complaint, even though t1.T and t2.T are not
  required to be eqtypes.  Thus I can now say:

	  structure SS = ProductEqTypeFUN (structure t1 = S  structure t2 = S)

	  fun f x = x + 1
	  fun g x = x - 1

  and now SS.eq((f, f), (f, f)) yields true and SS.eq((f, f), (g, g)) yields false.

Owner: dbm
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 750
Title: printing in src/build/index.sml
Keywords: index
Submitter: Brian Milnes <milnes@SLY.FOX.CS.CMU.EDU> and Gene Rollins
Date: 3/25/93
Version: 0.93
Severity: minor
Problem: 
>From revision 93 src/build/index.sml

      | printDec(FCTdec fbs) =
	  let fun printFctExp (FCTfct{def,...}) = printStrexp def
		| printFctExp (VARfct{def=FCTvar{name=fname',...},...}) =
                    print_entry(Symbol.name fname', fn()=> print "functor ")
		| printFctExp (LETfct(dec,fct)) = (
		    printDec dec;
		    printFctExp fct)
	   in (app (fn (FCTB{fctvar=FCTvar{name=fname,...}, def}) =>
                     (print_entry(Symbol.name fname, fn()=> print "functor ");
                      printFctExp def))
               fbs)
	  end

the print "functor " should be a say "functor ".

Status: fixed in 1.02
----------------------------------------------------------------------
Number: 751
Title: prettyprinting with or-patterns
Keywords: printing, prettyprint, patterns, OR
Submitter: John Reppy
Date: 3/25/93
Version: 0.93
Severity: minor
Problem: 
  Pretty-printing of top-level variables bound in or-patterns is
  broken.
Code: 
Transcript: 
  In Bill's version (0.94a + bug fix):

    Standard ML of New Jersey, Version 0.94a, February 19, 1993
    val it = () : unit
    - val (a|a) = 1;
    val a = 1 : int
    - val ((a,b)|(a,b)) = (1,2);
    val a = 1 : int
    val b = 2 : int
    - val ([x]|_::x::_) = [1];
    std_in:4.1-4.23 Warning: binding not exhaustive
	      (x :: nil | _ :: x :: _) = ...
    val x = 1 : int
    -

  In 0.94 (binding is working, but nothing is printed):

    Standard ML of New Jersey, Version 0.94x, February 26, 1993
    val it = () : unit
    - val (a|a) = 1;
    val a = 1 : int
    - val ((a,b)|(a,b)) = (1,2);
    - a;
    val it = 1 : int
    - val ([x]|_::x::_) = [1];
    std_in:5.1-5.23 Warning: binding not exhaustive
	      (:: (x,nil) | :: (_,:: (<pat>,<pat>))) = ...
    - x;
    val it = 1 : int
    -
Comments:
  It looks like the bug fixes were installed in 0.94, so something else must have
  broken.  The diff's between Bill's version and 0.94b are:

  diff -r src/print/ppdec.sml 94-bill/src/print/ppdec.sml
  52a53
  >                      | ORpat(p1, _) => ppBind p1

  diff -r src/translate/mc.sml 94-bill/src/translate/mc.sml
  81c81
  <           [pat1, pat2]
  ---
  >           (orExpand pat1)@(orExpand pat2)
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 752
Title: Maxint problem
Keywords: arithmetic, integers, literals, bounds
Submitter: florent@research.att.com (Florent Guillaume)
Date: 3/26/93
Version: 0.93, 0.94
System: sparc?
Severity: major
Problem: 
  Maxint problem
Transcript: 
  ihnp4 $ sml
  Standard ML of New Jersey, Version 0.94a, February 19, 1993
  val it = () : unit
  - val x = 0x3fffffff;
  val x = 1073741823 : int
  - val y = ~x;
  val y = ~1073741823 : int
  - x-y;
  val it = ~2 : int
  - 
Comments:
  The problem is in generic.sml.  When doing a sub of two integers, there is
  no test for overflow (for a mysterious reason).  The problem doesn't show
  on mips, which tests for overflow on every operation, but it shows on
  sparc.

  This means that no program running on sparc relies on the exception
  raised by sub...
Fix:
More precisely, in /usr/local/sml/93/src/cps/generic.sml
the line 1185 should be changed from
                   (M.sub(gpregbind w, gpregbind v, x'');
to
		   (M.subt(gpregbind w, gpregbind v, x'');

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 753
Title: pretty printer prints syntactically incorrect text
Keywords: printing, prettyprint, error recovery
Submitter: John Reppy
Date: 3/27/93
Version: 0.93
Severity: minor
Problem: 
  The pretty printer prints a syntactically incorrect text in some error
  messages.
Code: 
Transcript: 
  lexer.sml:66.15-66.65 Error: operator and operand don't agree (tycon mismatch)
    operator domain: {kind:ViewBuffer.token_kind, space:int ref, text:string}
    operand:         {kind:ViewBuffer.token_kind, space:int, text:'Z}
    in expression:
      token ({space=! space,kind=Symbol,text=s})
Comments:
  The text should be

      token ({space= !space,kind=Symbol,text=s})

  since the sequence ``=!'' is a symbolic identifier.
Owner: 
Status: open
----------------------------------------------------------------------
Number: 754
Title: compiling eXene with newconreps generates uncaught Nth exception
Keywords: eXene, conreps
Submitter: 		John Reppy (jhr@research.att.com)
Date: 			3/27/93
System(s) and Version:	Compiler, version 0.93
SML/NJ Version: 	0.93
Machine: 		All
Severity: 		major
Problem: 		Attempting to compile eXene with newconreps enabled
			produces an uncaught exception Nth in cpsopt.
Code:
Transcript:
  ...
  structure ScrollLayout : SCROLL_LAYOUT
  [opening composite/widget-set.sml]
  parse, 291 lines, 0.360000s
  semantics, 0.670000s
  translate, 0.110000s
  codeopt, 0.050000s
  convert, 0.050000s

  uncaught exception Nth
  -
Comments:
  I think that the bug is occuring in makeSELECT in contract.sml.
  I turned on debugging (System.Control.CG.misc1), and it
  prints a "d" just before the exception.  There are two calls
  to nth in Contract; the one in makeSELECT has a click "d"
  just before it (the other has a click "g").

	  - John

  Transcript:
    ...
    Contract: ggggggggeeeeggggfddd
    uncaught exception Nth
    -
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 755
Title: Compiler bug: DebugError:Static.locOfEvent bad APPev marking
Keywords: 
Submitter: 		Bart Massey <bart@cs.uoregon.edu>
Date: 			3/28/93
System(s) and Version:	Compiler/Debugger
SML/NJ Version: 	0.93
Machine: 		Sun 4 SunOS 4.1.3
Severity: 		major
Problem: 		smld error compiling source
Code:
			Available on request -- about 200 lines
			It's difficult to trim, as I have no idea
			where to start.
Transcript:
			I "usedbg" a bunch of sources into
			smld, then
			
	- usedbg "runaway-searchops.sml";
	Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking
	-
			Note (for what it's worth) that the code
			compiles OK with "use", but dies at
			runtime with an uncaught exception
			(this is what I was trying to debug :-).
			
Comments:
			First time I tried to use the debugger.
			Bummin' :-).
Fix:
As suspected, this bad APPev marking bug was due to a problem with marking
of derived forms, in this case selectors (#).  The fix is a small patch to
elaborate/elabutil.sml:

pleiades% diff ../../93/src/elaborate/elabutil.sml elaborate
99a100,102
>    If no member of list is marked, mark the default case with loc of 0
>      in order to keep debugger instrumenter happy; this case should never
>      be executed anyway.
105c108
<              r :: (f (SOME left) rest)
---
>              r :: (f left rest)
107,109c110,111
<       | f (SOME loc) nil = [rule (fn exp => MARKexp(exp,loc,loc))]
<       | f NONE nil = [rule (fn exp => exp)]
<   in f NONE
---
>       | f loc nil = [rule (fn exp => MARKexp(exp,loc,loc))]
>   in f 0

Status: fixed in 1.03f
----------------------------------------------------------------------
Number: 756
Title: compiler loops
Keywords: type checking, infinite loop
Submitter: 		Bart Massey <bart@cs.uoregon.edu>
Date: 			3/28/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		Sun 4 SunOS 4.1.3
Severity: 		minor
Problem: 		compiler spins (in elaboration phase?)
Code:			val rec f = fn x => g x and g = fn x => f x;
Transcript:
			The above declaration, when typed at the
			interactive environment, appears to
			cause the compiler to infinite-loop.

Comments:		Don't ask why anyone would type this.
Fix: (Appel)
  Andrew sez "I fixed this bug in 0.96a.  It was in the Eta phase. 
  And aren't there some nice juicy eta-redexes in the example!"
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 757
Title: ml_connect_inet isn't implemented for AIX
Keywords: aix, ml_connect_inet
Submitter:          Cliff Krumvieda, cliff@cs.cornell.edu
Date:               4/12/93
System and Version: Runtime system, 0.93
SML/NJ Version:     0.93
Machine:            IBM RS/6000, AIX 3.2
Severity:           Major
Problem:            ml_connect_inet isn't implemented for AIX
Code:               See runtime/cfuns.c
Transcript:         None needed
Comments:           I had a distributed systems expert (Robert
                    Cooper) look at ml_connect_inet, and he suggested
                    the following (trivial) fix.  It seems to work.
Fix:      
======================================================================
*** cfuns.c-dist        Tue Feb  9 11:37:22 1993
--- cfuns.c     Mon Apr 12 09:27:38 1993
***************
*** 463,469 ****
      struct sockaddr_in saddr;
      int                   fd, s, i, sts;

! #if defined(SUNOS) || (defined(BSD) && defined(MIPS)) || defined(NeXT) || defined(AUX) || defined(HPPA)
      DO_SYSCALL (socket(PF_INET, SOCK_STREAM, 0), fd);
      if (fd != -1) {
        saddr.sin_family = AF_INET;
--- 463,469 ----
      struct sockaddr_in saddr;
      int                   fd, s, i, sts;

! #if defined(SUNOS) || (defined(BSD) && defined(MIPS)) || defined(NeXT) || defined(AUX) || defined(HPPA) || defined(AIX)
      DO_SYSCALL (socket(PF_INET, SOCK_STREAM, 0), fd);
      if (fd != -1) {
        saddr.sin_family = AF_INET;

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 758
Title: newconreps confusion
Keywords: newconreps
Submitter:              Nevin Heintze (nch@cs.cmu.edu)
Date:                   3/31/93
System(s) and Version:  Compiler
SML/NJ Version:         0.93
Machine:                machine independent (have experienced problem on
			                     pmax/mach, hp/hpux, ...)
Severity:               minor/major (if you run into it, you can waste
			a lot of time working out what is going on!)

Problem:                The parity of the newconreps flag gets messed up
			when recompiling the compiler.

Code/Transcript:
The problem occurs when you make a new version of the compiler from
scratch (using makeml/smlc/upto.all) e.g. 

   makeml -hppa hpux8 -batch
   smlc < all
   mv upto.all upto.all1
   upto.all1 < all
   mv *.mo ../mo.hppa
   makeml -hppa hpux8

The binary generated is such that the abstract syntax interface has an
inconsistent representation.  For example,

  fun f str =
    let val consumer = (fn str => output(std_out, str))
	val ppcon = {consumer = consumer, linewidth=80,
		     flush = System.Print.flush}
	val strm = open_string str
	val sce = System.Compile.makeSource("string", 1, strm, false, ppcon)
	val env = System.Env.staticPart (!System.Env.pervasiveEnvRef)
	val (ast, _) = System.Compile.parse(sce, env)
    in
	ast
    end;

  f "val x = 1";

generates the error:

  "Error: Compiler bug: PPVal.switch: none of the datacons matched".

This error is generated during the printing of the result of f "val x = 1".
No error is generated from val _ = f "val x = 1".

The problem seems to be related to the newconreps flag.  The default
value of this flag is "false" and the flag is toggled to "true" during
the compilation of the compiler (see line 5 of all).  However, in
upto.all, newconreps is initially "true", and so line 5 of the file
"all" serves to toggle it to "false", and so the upto.all compiles the
compiler with newconreps = "false", and this leads to an inconsistency.

Comments: Thanks to David Tarditi and Greg Morrisett for helping
to track this down.  I ran into the bug because I was modifying the
pervasives for the purpose of implementing a program analysis algorithm
(using set based analysis techniques).

Fix: Toggle the newconreps flag back to false at the end of all (so that
the flag is initially false in upto.all), just before dumping core.
That is, the last few lines of all should read:

     ~summary
     
     ^globalhandle
     ^newconreps
     ^dumpCore
     >upto.all
Status: fixed in 0.96   (completely new batch compilation system)
----------------------------------------------------------------------
Number: 759
Title: A data constructor of type unit may fail to prettyprint.
Keywords: printing, prettyprint, datatypes, data constructor
Submitter:		Jeff Lewis (jlewis@cse.ogi.edu)
Date:			3/31/93
System:			Compiler
SML/NJ Version:		0.93
Machine:		Sun 4, SunOS 4.1.2
Severity:		minor, but annoying
Problem:

A data constructor of type unit may fail to prettyprint.

Transcript:

Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- datatype foo = Foo of unit | Bar of int * foo;
datatype  foo
  con Bar : int * foo -> foo
  con Foo : unit -> foo
- Foo;
val it = fn : unit -> foo
- Foo();
Error: Compiler bug: PPVal.decon - constant datacon in decon

Comments:

Yes, I do have a good reason for declaring the datatype that way ;-)

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 760
Title: inexhaustive match in cps/cpsprint.sml
Keywords: matches
Submitter: Lal George
Date: 4/1/93
Version: 0.95
Severity: minor
Problem: 
  There is an inexhaustive match in cps/cpsprint.sml that could be
  fixed in 0.95 or the next version. Below is the diff.
Fix:
================================================================
76c76,77
< 
---
>   | pureName P.fnegd = "fnegd"
>   | pureName P.fabsd = "fabsd"
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 761
Title: failure under A/UX 3.0
Keywords: a/ux
Submitter:              Espen Svennevik (esvennevik@cix.compulink.co.uk)
Date:                   4/3/93
System(s) and Version:  <e.g., Compiler, Library, CML, eXene, ...>
SML/NJ Version:         0.93
Machine:                Macintosh Quadra 700 running A/UX v3.0
Severity:               critical
Problem:                core dumps on simplest sml program
Code:                    
                                # sml
                                Standard ML of New Jersey, Version
0.93, February 15, 1993
                                val it = () : unit
                                - fun f x = x;
                                Memory fault - core dumped
                                #
Comments:               I have compiled njml with GCC v2.1, GCC
v2.3.1 and with the host compiler. The errors have been indentical. Smli
compiles, and runs ok, with GCC v2.3.1.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 762
Title: elaboration of equality test loops
Keywords: equality, infinite loop
Submitter:              Andrzej Filinski <andrzej@cs.cmu.edu>
Date:                   4/3/93
System(s) and Version:  Compiler, 0.93 (February 15, 1993)
Machine:                all
Severity:               major
Problem:                Elaboration of equality test loops on monomorphic
			instances of recursively-defined type constructors.
Transcript:		- datatype 'a foo = FOO of 'a foo foo;
			datatype  'a foo
			  con FOO : 'a foo foo -> 'a foo
			- fn (x:int foo) => x=x;  (* hangs *)
Comments: 		"fn (x:''a foo) => x=x" works.
Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 763
Title: error message doesn't give the *right* number of arguments
Keywords: type checking, error messages
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           4/7/93
Version:        0.93
Severity:       minor
Problem:        error message doesn't give the *right* number of arguments
Code:           []:list
Transcript:     - []:list;
		std_in:0.0-0.0 Error: type constructor list has the wrong number of arguments: 0
Comments:	ideally, the message would also give the *right* number of
		arguments.
Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 764
Title: Maxint problem + crash
Keywords: arithmetic, integers, literals, bounds, Maxint
Submitter:	florent@research.att.com (Florent Guillaume)
Date:		3/19/93
Version:	0.94a, probably all
System:		all
Severity:	major
Problem:	Maxint problem + crash
Transcript:
	Standard ML of New Jersey, Version 0.94a, February 19, 1993
	val it = () : unit
	- val x = 0;
	val x = 0 : int
	- 0x1fffffff - x;
	
	uncaught exception Overflow
	- 1+1; (* or anything else *)
	Illegal instruction (core dumped)

Comments:
	The fix bellow should take care of the overflow problem, but I have
  no idea why an illegal instruction was generated.
	The problem is the following : in cps/generic.sml, when emitting
  code for (k - x), there is a (k+k+2) generated, which is not handled
  by cps/convert.sml.

	The recurring problems with big integers will only be solved when
  we have an integer type that can handle 2^32 (or even 2^64 for alphas)
  (currently, the hack in cps/convert.sml is really horrible, and not adequate
  for cross compiling between architectures with different sizes of integers).

Fix:
  In cps/convert.sml (line 617 for 0.95),
  replace
	   | Lambda.INT i => ((i+i; c(INT i))
  with
	   | Lambda.INT i => ((i+i+2; c(INT i))

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 765
Title: syntax inaccuracy (signature named "*")
Keywords: syntax, parsing
Submitter: Cregut Pierre <cregut@ecrc.de>
Date: 4/19/93
Version: 0.93
Severity: minor
Problem: 
Some signature expression only recognise ID instead of full ident (including
* and = so I can't match a structure against signature * . What a mess !!)
Code: 
Transcript: 
Comments:
Fix:
Here is the change for true SML purists !

< sign	: ident			(MarkSig(VarSig (sigSymbol ident),identleft,identright))
---
> sign	: ID			(MarkSig(VarSig (sigSymbol ID),IDleft,IDright))
618c618
< 	| COLON ident		(SOME(VarFsig (fsigSymbol ident)))
---
> 	| COLON ID		(SOME(VarFsig (fsigSymbol ID)))
628c628
< fsig	: COLON ident	(VarFsig (fsigSymbol ident))
---
> fsig	: COLON ID	(VarFsig (fsigSymbol ID))

Beware line numbers are probably wrong because I have modified the grammar
for my own purposes.
Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 766
Title: capture/escape space leak is back!
Keywords: space leak, continuations
Submitter: 		John H. Reppy
Date: 			4/14/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		Sparc (probably others)
Severity: 		major
Problem:
The space leak in capture/escape has reappeared (bug #633).
I ran my test on versions 0.75-0.88, and here is a summary of
the results:

  version    space leak?
    75		no
    76		no
    77		yes
    78		yes
    79		yes
    80		yes
    81		no
    82		no
    83		no
    84		yes
    85		yes
    86		yes
    87		yes
    88		yes
    89		yes
    90		no
    91		no
    92		no
    93		no
    94		yes

As a reminder, the simple example of this problem is the function
select in CML.

Code:
  local
    open System.Unsafe.PolyCont
  in
    fun select x = capture (fn k => let
          val return = escape k
          in
            return (x ())
          end)
  end;

  (* which is called in the following loop: *)

  fun loop () = select loop

Transcript:

Running a modified version of this that forces GCs:

  Standard ML of New Jersey, Version 0.94x, February 26, 1993
  val it = () : unit
  - [opening xxx]
  val select = fn : (unit -> 'a) -> 'a
  structure XX : sig val f : unit -> unit end
  val it = () : unit
  
  [Major collection... 99% used (4426300/4451764), 1550 msec]
  
  [Increasing heap to 12977k]
  
  [Major collection... 98% used (4428356/4480768), 1710 msec]
  
  [Increasing heap to 13129k]
  
  [Major collection... 98% used (4480384/4532448), 1780 msec]
  
  [Increasing heap to 13281k]
  
  [Major collection... 98% used (4532384/4584448), 1830 msec]
  
  [Increasing heap to 13433k]
  
  [Major collection... 98% used (4584384/4636448), 1910 msec]
  
  [Increasing heap to 13585k]
  
  [Major collection... 98% used (4636384/4688448), 1960 msec]

  [Increasing heap to 13737k]
  val it = () : unit
  -

Status: fixed in 0.96
----------------------------------------------------------------------
Number: 767
Title: OR patterns in val bindings broken
Keywords: patterns, OR
Submitter: Appel
Date: 4/22/93
Version: 0.95
System: all
Severity: minor (unless you like OR patterns)
Problem: OR patterns don't work in val bindings
		(but they work in matches (fn, fun, case)).
Code: 

	val (a|a) = 6

Transcript: 

  Standard ML of New Jersey, Version 0.95y, March 26, 1993
  - val (a|a) = 6;
  - a;
  std_in:3.1 Error: unbound variable or constructor: a

Comments:
  Some problem in elaboration.

Fix:  Ask Zhong.
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 768
Title: OR patterns and inline primops don't mix well
Keywords: patterns, OR, inline, primops
Submitter: Appel
Date: 4/22/93
Version: 0.94
System: all
Severity: minor (unless you like OR patterns)
Problem: When the right hand side of a val binding is an
	inline primop, and the left hand side is an OR pattern,
	an impossible error occurs.
Code: 

	val (a|a) = Array.sub;

Transcript: 

  Standard ML of New Jersey, Version 0.95y, March 26, 1993
  - val (a|a) = Array.sub;
  Error: Compiler bug: elabVB

Comments:
	No one would do this; I detected the bug by reading the code.

Fix:
	Instead of   impossible "elabVB"    in elabcore.sml,
	just put "pat".  This will lose the inline property but
	it will get the job done in this very rare case. 
	
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 769
Title: Compiler bug: DebugError:Static.locOfEvent bad APPev marking
Keywords: modules, functors, debugger
Submitter: Brian Milnes <milnes@SLY.FOX.CS.CMU.EDU>
Date: 4/27/93
Version: 0.93 (smld)
Severity: major
Problem: 
  Compiler bug caused by usedb.
Code: (in file foo.sml)
    functor Queue () =
     struct
      type 'a queue = 'a list * 'a list
      fun add_to_queue (v, (a, b)): 'a queue = (a, v :: b)

    end
Transcript: 
  usedbg "foo.sml";
  Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking
Fix: Tolmach has sent fix?
Status: fixed in 1.03f
----------------------------------------------------------------------
Number: 770
Title: profiling broken in 0.93 on yacc
Keywords: profiler
Submitter:    Zhong Shao   (zsh@cs.princeton.edu)
Date:         5/6/93
Version:      0.93
System:       mipsb/riscos
Severity:     minor
Problem:      profiling broken in 0.93 on yacc
Code:
              First, use sml93 to generate a "smlp";

              use "yacc.sml"
              Profile.reset();
              Main.doit();

Transcript:
              .....................
              - Profile.reset();
              val it = () : unit
              - Main.doit();
              DATA/ml.grm, line 63: Error:  eof encountered in action beginning here !
              DATA/ml.grm, line 63: Error:  eof encountered in action beginning here !
              DATA/ml.grm, line 733: Error: syntax error found at EOF

              uncaught exception ParseError

Comments:     ml.grm is a correct grammar specification. Obviously the 
              instrumenting code inserted by the profiler changed the
              original semantics of the source programs. 
	      [Lal George] This may be related to bug 734.

Fix:          check the build/prof.sml carefully.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 771
Title: Low order digits of Pi are wrong
Keywords: float, pi
Submitter: 		La Monte H. Yarroll <piggy@baqaqi.chi.il.us>
Date: 			5/13/93
System(s) and Version:	SML/NJ 0.93 compiler
SML/NJ Version: 	0.93
Machine: 		SparcStation, SunOS 4.1.3
Severity: 		minor
Problem: 		Low order digits of Pi are wrong.
Code:
>From src/boot/math.sml in the compiler sources:
val PIo4   =  7.8539816339744827900E~1
val PIo2   =  1.5707963267948965580E0
val PI3o4  =  2.3561944901923448370E0
val PI     =  3.1415926535897931160E0
val PI2    =  6.2831853071795862320E0

This line is probably inacurate too:
val oneOver2Pi = 0.15915494309189533576888376337251486

Transcript:		NA
Comments:
This is only accurate to the 15th decimal place, even though 19 places
are quoted.

I can't easily check oneOver2Pi beyond 15 decimal places--but it is
correct that far.  It may be worth a quick recalculate, if you can do
it easily.

I happen to remember Pi to 17 decimal places, so I noticed the
discrepency.  I checked (and augmented) my memory against a poster in
our stairwell :-).

Fix:

val PIo4   =  7.853981633974483096E~1
val PIo2   =  1.5707963267948966192E0
val PI3o4  =  2.3561944901923449288E0
val PI     =  3.1415926535897932385E0
val PI2    =  6.2831853071795864769E0

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 772
Title: Numeric selection with index > 9
Keywords: records
Submitter: Soren Christensen (schristensen@daimi.aau.dk)
Date: 5/13/93
Version: 0.93
Severity: major
Problem: 
  #<n> selector doesn't work when n is an integer > 9
Code: 
  type U = int*int*int*real*int*string*int*int*unit*int*int*bool;

  fun p1 (x:U) = (#1 x);
  fun p2 (x:U) = (#2 x);
  fun p3 (x:U) = (#3 x);
  fun p4 (x:U) = (#4 x);
  fun p5 (x:U) = (#5 x);
  fun p6 (x:U) = (#6 x);
  fun p7 (x:U) = (#7 x);
  fun p8 (x:U) = (#8 x);
  fun p9 (x:U) = (#9 x);
  fun p10 (x:U) = (#10 x);
  fun p11 (x:U) = (#11 x);
  fun p12 (x:U) = (#12 x);

Transcript: 
  (* p10, p11, and p12 fails with:

  std_in:65.17-65.23 Error: operator and operand don't agree (record labels)
    operator domain: {10:'Y, '...Z}
    operand:         U
    in expression:
      (fn {10=10,...} => 10) x

  *)

  Btw, the error message for #0 is quite strange:

  fun p1 (x:U) = (#0 x);

  std_in:66.18 Error: syntax error found at INT0

Status: fixed in 0.97a
----------------------------------------------------------------------
Number: 773
Title: Compiler bug after unbound structure symbol
Keywords: error recovery
Submitter: Andrew Appel
Date: 5/13/93
Version: 0.95
Severity: minor
Problem: 
Code: 
Transcript: 
  Standard ML of New Jersey, Version 0.95y, March 26, 1993
  - structure I=J;
  std_in:2.13 Error: unbound structure: J
  Error: Compiler bug: Stamps.stampToPersstamp
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 774
Title: aliased exceptions are pattern-matched in the wrong order
Keywords: exceptions, scoping, matches
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			5/15/93
System(s) and Version:	
SML/NJ Version: 	0.93
Machine: 		Sun4, SunOS 4.1.3 (though the bug is probably generic)
Severity: 		major
Problem: 		aliased exceptions are pattern-matched in the wrong order
Transcript: 		

  - (raise Vector.Size) handle Vector.Size => 1 | Array.Size => 2 | _ => 3;
  val it = 2 : int	(* huh? I expected `1' here *)
  - (raise Array.Size) handle Vector.Size => 1 | Array.Size => 2 | _ => 3;
  val it = 2 : int	(* should also be `1' *)

 Here's another example due to Michael Vium and Sten Schmidt at TU Denmark:
  
  Standard ML of New Jersey, Version 1.05, July 21, 1994 [new runtime]
  - exception A;
  - exception B = A;
  - val one = case A of B => 1 | A => 2;
  val one = 2 : int

Comment: [Andrew Appel]
  [This] is a problem in translate/mc.sml.
  Here's the problem:  Suppose you have a functor definition

  functor F(exception A exception B val f: unit->string) =
  struct 
    fun g() = f() handle A => "A" | B => "B"
  end

  Now, the compiler CANNOT know at compile time whether A and B are the
  same exception.  Thus, in the match compiler can't know what to do,
  and must resort to a very simple, one-at-a-time test of all the
  possibilities.

  The old match compiler (pre-Aitken) got this wrong.  It tested the
  name (symbol) of the exceptions, and if these were equal it assumed
  the exceptions were the same; and if not equal, it assumed different.
  This is potentially incorrect in each case.

  The new match compiler is evidently getting this wrong in a different way,
  as shown by:

  exception A
  exception B=A

  (raise A) handle A => "A" | B => "B"

  the result of evaluating this is "B"; it should be "A".

  I think what is happening is that mc.sml is assuming that
  A and B are different, and (therefore) it is permitted to test for
  B before testing for A.

  What you must do is assume that two exception constructors (whose type
  is the same but which are otherwise different) are NEITHER equal nor
  unequal.

  Can this be fixed without undue difficulty?

  ----------------
  [Peter Sestoft] Probably the match compiler optimizes exception matches too
  eagerly.  An exception match must be implemented as a linear sequence
  of comparisons of `exception names' (string refs in SML/NJ).

Owner: 
Status: open
----------------------------------------------------------------------
Number: 775
Title: calls of print in build/index.sml should be say
Keywords: index, printing
Submitter: Gene Rollins (rollins+@POP.CS.CMU.EDU)
Date: 5/17/93
Version: 0.93
Severity: minor
Problem: 
  The file build/index.sml has two calls to print that should be changed to
  calls to say.  Please change this in 0.95.  thanks....gene
Fix:
    161c161
    <                     print_entry(Symbol.name fname', fn()=> print "functor ")
    ---
    >                     print_entry(Symbol.name fname', fn()=> say "functor ")
    166c166
    <                      (print_entry(Symbol.name fname, fn()=> print "functor ");
    ---
    >                      (print_entry(Symbol.name fname, fn()=> say "functor ");
Status: fixed in 0.96
----------------------------------------------------------------------
Number: 776
Title: cannot compile under gcc 2.3.3
Keywords: runtime, install
Submitter: 		Stephen Sullivan.   sullivan@mathcom.com
Date: 			5/8/93
System(s) and Version:	SPARC 2, Sunos 4.1.1, gcc 2.3.3
SML/NJ Version: 	0.93
Machine: 		SPARC 2, Sunos 4.1.1, gcc 2.3.3
Severity: 		minor, but will be critical under Solaris 2
Problem: 		cannot compile under gcc 2.3.3; must use cc.
Comments:
When I set  USE_GCC="TRUE"  in src/makeml, the
makeml script uses gcc but then gets a
"malloc 3" error and dies.  When I use makeml as is,
makeml uses cc and works OK.

But soon I am converting to Solaris 2,
on which there is no cc: I'll have to use
gcc.  How can I get this working with gcc?

[jhr]

The problem is that gcc is producing initialization code for C++,
which calls malloc, and malloc doesn't coexist with the current
runtime system.  We should have a new runtime system in place by the
end of the summer, which does not interfere with malloc, and compiles
under gcc.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 777
Title: building on I386 under 386bsd
Keywords: install, eXene, 386bsd
Submitter: Olaf Wagner (wagner@luthien.in-berlin.de)
Date: 5/16/93
Version: 0.93
System: I386/386bsd
Severity: major
Problem: 
  trying to run the eXene X window toolkit under 386bsd, I discovered that
  in file runtime/cfuns.c the function ml_connect_inet has been ifdef'd
  out for all BSD systems except those running on MIPS architectures.
Fix:
  In order to get eXene running on 386bsd, one simply has to add a
  `|| defined(i386bsd)', but probably this should be defined for other
  BSD systems, too. At least on 386bsd the socket calls work without
  further modifications.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 778
Title: smld can't load SourceGroup
Keywords: Sourcegroup
Submitter: 		La Monte H. Yarroll <piggy@baqaqi.chi.il.us>
Date: 			5/26/93
System(s) and Version:	SML/NJ 0.93 compiler (debugger), SourceGroup 3.0
SML/NJ Version: 	0.93
Machine: 		SparcStation, SunOS 4.1.3
Severity: 		minor
Problem: 		smld can't load SourceGroup.
Transcript:

$ smld
Standard ML of New Jersey, Version 0.93, February 15, 1993
val it = () : unit
- use "sourcegroup/export.sml";
[opening sourcegroup/export.sml]
[opening ../tools/sourcegroup/load.sml]
val print'sigs = 2 : int
val it = () : unit
[opening ../tools/sourcegroup/local/System/getwd.sml]
./tools/sourcegroup/local/System/getwd.sml:31.26-31.50 Error: operator and operand don't agree (tycon mismatch)
  operator domain: string
  operand:         string * string list
  in expression:
    execute (program,args)
- ^D
$ 
Comments:
  I built smld with "./mlmake -noshare -debug".

  The symbol "execute" under smld is just completely different from the
  same symbol in a plain sml-noshare.
Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 779
Title: val rec syntax overly restrictive
Keywords: syntax, parsing, val rec
Submitter: 		Jeff Lewis (jlewis@cse.ogi.edu)
Date: 			5/26/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		irrelevant
Severity: 		pretty darn minor ;-)
Problem: 		val rec syntax overly restrictive
Code:
The following should be accepted, but isn't:

    val rec foo = (fn x => x): int -> int

The problem is in the grammar, parse/ml.grm line 435:

    rvb: opid constraint EQUAL FN match ( ... )
       | rvb AND rvb ( ... )

This grammar allows no possibility of a type constraint on the expression
following the EQUAL.  However, on page 9 of The Definition, section 2.9:
Syntactic Restrictions, under the fourth bullet, it states that the expr
on the right of the EQUAL may be type constrained.

Transcript:

- val rec foo = (fn x => x): int -> int;
std_in:2.15 Error: syntax error found at LPAREN

Owner: Andrew
Status: open
----------------------------------------------------------------------
Number: 780
Title: nested subtraction doesn't check for overflow
Keywords: arithmetic, integerts, overflow
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			5/31/93
SML/NJ Version: 	0.93
Machine: 		SPARCstation ELC, SunOS 4.1.3
Severity: 		major
Problem: 		nested subtraction doesn't check for overflow
Code:
Transcript:

- ~1073741825;
val it = 1073741823 : int
- ~1073741820 - (ord "5" - ord "0");
val it = 1073741823 : int
- ~1073741820 - 5;

uncaught exception Overflow

Comments:

The expression (~1073741820 - (ord "5" - ord "0")) is (roughly) what
makeInt (in src/ml.lex) evaluates in its last iteration over the
input string "1073741825". The failure to detect overflow here causes
it to silently accept (some) out-of-range constants.

Status: fixed in 1.01
----------------------------------------------------------------------
Number: 781
Title: FP overflow exception kills sml
Keywords: floats, overflow, crash
Submitter: Nick Haines
Date: 6/1/93
Version: 0.93
System: mipsl, mach specific
Severity: major
Problem: FP overflow exception kills sml 0.93.
Code: 
Transcript: 
  But FP overflow dies:

  > - val x = ref 1.0;
  > val x = ref 1.0 : real ref
  > - fun f () = (print (!x); print "\n"; x := (!x * 123.1E17); f ());
  > val f = fn : unit -> 'a
  > - f ();
  > 1.0
  > 1.231E19
  > 1.515361E38
  > 1.865409391E57
  > 2.296318960321E76
  > 2.82676864015515E95
  > 3.479752196031E114
  > 4.28357495331415E133
  > 5.27308076752972E152
  > 6.49116242482908E171
  > 7.9906209449646E190
  > 9.83645438325143E209
  > 1.21086753457825E229
  > 1.49057793506583E248
  > 1.83490143806603E267
  > 2.25876367025929E286
  > 2.78053807808918E305
  > 
  > uncaught exception Overflow
  > - bogus signal not in ML: (8, 0xb)
Comments:
Fix:
  The change affects two files, MIPS.prim.s and exncode.c. It simply
  adds a call to a one-instruction assembly-language function during the
  signal handler.

  First this addition to the end of MIPS.prim.s:

  *** 622,624 ****
  --- 622,638 ----
    /* this bogosity is for export.c */
	  .globl	startptr
    startptr: .word    __start
  + 
  + /* re_enable_fp:
  +  * When working in Mach on Decstations, floating-point exceptions send
  +  * SIGFPE not just once but over and over for ever, which breaks SML.
  +  * If we call this in the signal handler, it won't. Nick Haines 23-Apr-93
  + */
  + 
  + 	.globl	re_enable_fp
  + 	.ent	re_enable_fp
  + 
  + re_enable_fp:
  + 	mfc1	$atmp1, $f0
  + 	j	$31
  + 

  And then these inserts to exncode.c:

  *** 8,13 ****
  --- 8,18 ----
    #ifdef MIPS
    #ifdef sony_news
    #include <machine/cpu.h>   /* for EXC_OV */
  + 
  + #ifdef MACH
  + extern void re_enable_fp(void);
  + #endif
  + 
    #else
    #ifndef SGI
    #include <mips/cpu.h>   /* for EXC_OV */
  ***************
  *** 96,101 ****
  --- 101,111 ----
	struct sigcontext *scp;
	int		sig, code;
    {
  + 
  + #if defined(MIPS) && defined(MACH)
  +   re_enable_fp();
  + #endif
  + 
	switch (sig) {
    #ifdef THINK_C
	case SIGTRAP:

Owner: 
Status: not reproducible
----------------------------------------------------------------------
Number: 782
Title: mllex actions with YYBEGIN
Keywords: mllex
Submitter: 		Ryszard Kubiak, 
                        Institute of Computer Science of 
                        the Polish Academy of Sciences,
                        Gdansk, Poland, 
                        panrk@halina.univ.gda.pl
Date: 			6/2/93
Apparently-To: sml-bugs@research.att.com

System(s) and Version:	mlyacc and mllex
SML/NJ Version: 	0.93 of Feb 15
Machine: 		Sparc ELC, SunOS, OpenWin
Severity: 		minor but major for me
Problem: 		mllex does not generate tokens if the action is
                         accompanied by YYBEGIN
Comments:		please inform me if it is really a bug 
                        (the documentation is vague about
                        the semantics of semantic actions, so
                        one may only rely on their common sense)
                        and if there is a way of overcoming it

Code:
This  yacc's code reads and copies the tokens generated by the lex 
code below:

---

%%

%name tcalc

%arg (dev) : outstream

%pos int

%term  NL | SWITCH | TXT of string | EOF

%nonterm Start | Input 

%eop EOF         

%%
		                
Start : Input            (close_out dev)

Input : (* empty *)      ()
      | Input TXT        (output (dev, "TXT " ^ TXT ^ "\n"))
      | Input NL         (output (dev, "NL" ^ "\n"))
      | Input SWITCH     (output (dev, "SWITCH"))
                                   
---

This lex's code operates on two start states. The "#" character
switches between them. The SWITCH token is intended to be passed to
the parser. In my application it is vital that the parser gets an
extra token to separate different parts of the grammar processed.
Without this SWITCH my grammar is hopelessly out of LALR(1) class.  

---

structure Tokens = Tokens   					     

type pos = interface.pos

type svalue = Tokens.svalue
type ('a,'b) token = ('a,'b) Tokens.token
type lexresult = (svalue,pos) token

val line = ref 0

val eof = fn () => Tokens.EOF(!line,!line)

%%
%header (functor tcalcLexFun(structure Tokens : tcalc_TOKENS));

%S EXPR;

%%
<INITIAL>"#"        => (Tokens.SWITCH(!line,!line); YYBEGIN EXPR; lex());
<INITIAL>[^#\n]*    => (Tokens.TXT(yytext,!line,!line));
<INITIAL>\n         => (Tokens.NL(!line,!line));            
<EXPR>"#"           => (Tokens.SWITCH(!line,!line); YYBEGIN INITIAL; lex());
<EXPR>[^#\n]*       => (Tokens.TXT(yytext,!line,!line));
<EXPR>\n            => (lex());

---

This is a simple njml loader to load the above code if stored 
in "tcalcy" and "tcalcl" files, respectively. You may need to 
customize the paths. The funtion p invokes the parser on two 
files. For example, if the input file contains 

aaaa
#
4444

then p generates 

TXT aaaa
NL
TXT 4444

Note that SWITCH is missing.

---

use "/home/njml/tools/mlyacc/base.sml";

use "tcalcy.sig";
use "tcalcl.sml";
use "tcalcy.sml";

structure tcalcLrVals = tcalcLrValsFun(structure Token = LrParser.Token);
structure tcalcLex = tcalcLexFun(structure Tokens = tcalcLrVals.Tokens);
structure tcalcParser = Join(structure ParserData = tcalcLrVals.ParserData
                             structure Lex=tcalcLex
                             structure LrParser = LrParser);


fun print_error (s,_,_) = output(std_out, "Error in " ^ s ^ "\n");

fun p inp_name out_name =
  let 
   val inp_file = open_in  ("/home/rysiek/calc/testy/" ^ inp_name)
   val out_file = open_out ("/home/rysiek/calc/testy/" ^ out_name)
   val lexer = tcalcParser.makeLexer (fn i => input(inp_file,i))
    in tcalcParser.parse (15, lexer, print_error, out_file)
   end; 

Status: not a bug
----------------------------------------------------------------------
Number: 783
Title: smld incompatible with sourcegroup
Keywords: debugger
Submitter: Chris Ramming
Date: 6/3/93
Version: 0.93
Severity: major
Problem: 
  Debugging ml, "smld", seems to be incompatible with sourcegroup.

  To reproduce the problem using sml93, first build the debugging version of
  ml (makeml -debug) named by convention "smld";  then using "smld", attempt
  to load sourcegroup by whatever method, for instance by 'use "load-all.sml"'.
  The load will fail almost immediately in file "date.sml" with a complaint
  about an operator/operand disagreement in expression 'execute(program,args)'.

Owner: 
Status: obsolete
----------------------------------------------------------------------
Number: 784
Title: unnatural type error messages
Keywords: types, type checking, error messages
Submitter: Tim Freeman <tsf@cs.cmu.edu>
Date: 6/4/93
Version: 0.93
Severity: minor
Problem: 
  Type checker doesn't take programmer at his word.
Code: 
Transcript: 
  In version 0.93, this dialogue can happen:

  - fun foo (x:int) = (foo true; foo 1);
  std_in:0.0-0.0 Error: operator and operand don't agree (tycon mismatch)
    operator domain: bool
    operand:         int
    in expression:
      foo 1
  std_in:0.0-0.0 Error: pattern and expression in val rec dec don't agree (tycon mismatch)
    pattern:    bool -> 'Z
    expression: int -> _
    in declaration:
      foo = (fn x : int => (foo true; foo 1))
  - 
Comments:
  I think the compiler should regard my explicit declaration of type int
  for x as correct, and complain about code that does not fit with it,
  instead of the other way around.  In this example, at some point it
  should complain that true does not have type int.  In the real example
  I'm dealing with now, there are many recursive calls to the function,
  and I am finding it difficult to discover which one has the wrong
  type, since the complier reports instead that some subset of the
  *correct* clauses are incorrect, and then it reports that all the
  explicit declarations I've put in are incorrect.

Owner: 
Status: open (though not strictly speaking a bug)
----------------------------------------------------------------------
Number: 785
Title: makestring (on real numbers) gives wrong output
Keywords: makestring, floats
Submitter:    Zhong Shao   (zsh@cs.princeton.edu)
Date:         6/8/93
Version:      0.96 
System:       mipsel/ultrix (perhaps on all machines)
Severity:     critical
Problem:      makestring (on real numbers) gives wrong output
Code:
              makestring 0.0003;
              makestring 0.000786;
              makestring 0.0786;

Transcript:

              - makestring 0.0003;
              val it = "0.003" : string

              - makestring 0.000786;
              val it = "0.786" : string

              - makestring 0.0786;
              val it = "0.786" : string

              - cos 1.57;
              val it = 0.796326710733202 : real
              (*** the correct output is the 0.00079... ***)


Comments:     This bug also affects all the real functions such as "cos",
              "sin" etc, because the output of these function applications
              will be printed out in ppval.sml via "makestring".

              The correct output should append the exponent at the end.

              Please look at the "real" function in boot/makestring.sml 
              Version 0.93 handles this correctly.

Status: fixed in 1.02
----------------------------------------------------------------------
Number: 786
Title: overflow on ~1073741824
Keywords: arithmetic, integers, overflow, literals
Submitter:    Zhong Shao   (zsh@cs.princeton.edu)
Date:         6/8/93
Version:      0.96 
System:       mipsel/ultrix (perhaps on all machines)
Severity:     critical
Problem:      overflow on ~1073741824
Code:         
              val x = ~1073741824;


Transcript:
            
              - val x = ~1073741824;
              
              uncaught exception Overflow

Comments:     works in version 0.93. Possible caused by the new "makestring"
              function on integers.

              This number is the minimum integer that is used to implement 
              the "mod" function etc.

Status: fixed in 1.02
----------------------------------------------------------------------
Number: 787
Title: redundant source files
Keywords: config
Submitter: Pierre Cregut
Date: 6/10/93
Version: 0.93
Severity: minor (code cleanup suggestion)
Problem: 
Similarities between util/sortedlist.sml and translate/mcset.sml
suggest that one of these is redundant.
Remarks:  mcset.sml removed from all-files in 1.02, removed from directory 
	  in 1.03e
Status: fixed in 1.03e
----------------------------------------------------------------------
Number: 788
Title: "open" reports an error (it should always work)
Keywords: modules, open
Submitter: 		Stefan Kahrs	smk@dcs.ed.ac.uk
Date: 			6/14/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		Sun4
Severity: 		minor
Problem:		"open" reports an error (it should always work)
Code:			
  signature s=sig type a; val nil:a; val :: :int*a->a end;
  structure a:s = struct datatype a = nil | :: of int*a end;
  open a;

Transcript:
 (Error message after the last declaration:)
  std_in:8.1-8.6 Error: pattern and expression in val dec don't agree (tycon mismatch)
    pattern:    'Z list
    expression: a.a
    in declaration:
      nil = nil
  std_in:8.1-8.6 Error: data constructor :: used without argument in pattern

Comments:		
  There are no patterns in the example, so the
  error message does not even make sense.

  I actually wrote this stuff to see what
  happens with a "derived form" like [1,2,3] after
  redefining :: and nil to
  some non-constructor operations. Thus I needed
  to un-constructor the two which is only
  possible with signatures and open.

  See also bug 847.

Owner: dbm, Zhong
Status: fixed in 109.27 [dbm, 4/4/97]
----------------------------------------------------------------------
Number: 789
Title: ML-style comment confuses preprocessor
Keywords: comments, runtime, cfuns
Submitter: David Ladd (ladd@graceland.ih.att.com)
Date: 6/30/93
Version: 0.97
System: SGI
Severity: minor
Problem: 
  runtime/cfuns.c, line 1754: 
	ML-style comment confuses preprocessor
	(character constants need to be balanced, even in #ifdef'ed
	out code)
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 790
Title: System.Unsafe.SysIO.readi is wrong
Keywords: readi, I/O
Submitter:          Cliff Krumvieda, cliff@cs.cornell.edu
Date:               6/30/93
System and Version: Runtime system, 0.93
SML/NJ Version:     0.93
Machine:            All but Macs
Severity:           Major
Problem:            System.Unsafe.SysIO.readi is wrong
Code:               See runtime/cfuns.c
Transcript:         None needed
Comments:           The code is obviously wrong.  It looks like the
                    programmer who did the Mac (THINK_C) port found
                    the problem but didn't propogate the fix for everyone
                    else.
Fix:
======================================================================
***************
*** 646,656 ****
      int                   nbytes = REC_SELINT(arg, 3);
      int                   n;

! #ifdef THINK_C
!     DO_SYSCALL (read (fd, start, nbytes), n);  /* right!? */
! #else
!     DO_SYSCALL (read (fd, buf, nbytes), n);
! #endif
      CHK_RETURN(msp, n);

  } /* end of ml_readi */
--- 646,653 ----
      int                   nbytes = REC_SELINT(arg, 3);
      int                   n;

!     DO_SYSCALL (read (fd, start, nbytes), n);
!
      CHK_RETURN(msp, n);

  } /* end of ml_readi */
======================================================================
Status: fixed in 0.97a (also bug #741)
----------------------------------------------------------------------
Number: 791
Title: sourcegroups generates an illegal instruction
Keywords: Sourcegroup
Submitter:      Lal George
Date:		7/1/93
Version:        0.93
System:         SGI Challenger, IRIX 5.0
Severity:       major
Problem:        sourcegroups generates an illegal instruction.
Transcript:     

    (1)[17:49]mafia:/home/cpg/bin/sgi$ sml-sg
    Illegal instruction (core dumped)
    (1)[17:49]mafia:/home/cpg/bin/sgi$ ll
    total 18660
    -rw-r--r--    1 cpg        25612 Jun 30 16:46 core
    -rwxr-xr-x    1 cpg      4149248 Jun 30 13:09 sml
    -rwxr-xr-x    1 cpg      5357568 Jun 30 16:39 sml-sg
    (1)[17:49]mafia:/home/cpg/bin/sgi$ file core
    core:           IRIX core dump of 'sml-sg'
    (1)[17:49]mafia:/home/cpg/bin/sgi$

Comments:
    This was brought to my attention by Carlos Puchol cpg@research.att.com

    The compiler will not build under IRIX 5.0, however, the sml image
    created under IRIX 4.0.5F runs fine and will load and export sml-sg.
    The exported image generates an illegal instruction! This even happens
    when sml-sg is built under IRIX 4.0.5F.
Status: not important --- obsolete
----------------------------------------------------------------------
Number: 792
Title: "withtype" scoping is wrong
Keywords: syntax, withtype, scoping
Submitter: 		Stefan Kahrs	smk@dcs.ed.ac.uk
Date: 			7/5/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		Sun4
Severity: 		minor
Problem:		"withtype" scoping is wrong.

Code:			abstype a = B
			withtype t = int
			with type t = bool
			end
			val x : t = 4;

Transscript:		type a
			type  t = int
			type  t = bool
			val x = 4 : t

Comments:		The type constructor t should be bound to
			bool, not to int.
Status: fixed in 1.02
----------------------------------------------------------------------
Number: 793
Title: open of unbound structure causes duplicate error messages
Keywords: error messages, open, error recovery
Submitter: 		John Reppy (jhr@research.att.com)
Date: 			7/11/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.93
Machine: 		any
Severity: 		minor
Problem: 		open of unbound structure causes duplicate error messages
Code:			open Foo;
Transcript:
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  - open Foo;
  std_in:2.1-2.8 Error: unbound structure: Foo
  std_in:2.1-2.8 Error: unbound structure: Foo
  -
In 109.19m, also generates a compiler bug:
  - tuse "bugs/bug793.sml";
  [opening bugs/bug793.sml]
  bugs/bug793.sml:4.1-4.9 Error: unbound structure: Foo
  bugs/bug793.sml:4.1-4.9 Error: unbound structure: Foo
  Error: Compiler bug: ModuleUtil: strId

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       elaborate/elabmod.sml:890.8
	       elaborate/elabmod.sml:1104.7
	       util/stats.sml:168.40
	       test/evalloop.sml:127.37
	       test/evalloop.sml:202.20-202.23

Test: bug793.sml
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 794
Title: exception Substring when printing real numbers
Keywords: printing, floats
Submitter: 		Lal George
Date: 			7/15/93
SML/NJ Version: 	0.97
Machine: 		all
Severity: 		major
Problem: 		exception Substring when printing real numbers.
Transcript:

  kisubi:$ $s/97/bin/sparc/sml
  Standard ML of New Jersey, Version 0.97, 11 June 1993
  - 0.3;

  uncaught exception Substring

Comments:

  As far as I can tell this occurs for real numbers between 0.0 and 1.0.

Status: fixed in 1.02
----------------------------------------------------------------------
Number: 795
Title: Compiler bug: elabDecl:open:FctBodyStr
Keywords: modules, functors
Submitter: Lawrence C Paulson <Larry.Paulson@cl.cam.ac.uk>
Date: 7/20/93
Version: 0.93
Severity: major
Problem: Compiler bug: elabDecl:open:FctBodyStr caused by functor definition
  with let form of structure expression on rhs.
Code:
  functor Fun (Str: sig end) =
  let open Str
  in
    struct end
  end;

Transcript: 
  albatross: sml
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  . . .

  Error: Compiler bug: elabDecl:open:FctBodyStr
  -
Status: fixed in 1.05 (using Cregut's fix from 8/11/93)
----------------------------------------------------------------------
Number: 796
Title: partially applied functor in functor body
Keywords: modules, functors, higher-order functors
Submitter:		Chris Colby, colby+@cmu.edu
Date:			7/21/93
System(s) and Version:	Compiler
SML/NJ Version:		0.93
Machine:		pmax Mach
Severity:		major
Problem:		The body of a functor cannot conain a
			partially-applied curried functor.

Code:			signature S = sig type t end
			functor F (A:S) (B:S) = struct type t = int end
			functor G () =
			  struct functor H = F (struct type t = int end) end

Transcript: (0.93)
  uncaught exception Subscript
Transcript: (106)
  Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime]
  - use "bug796.sml";
  [opening bug796.sml]
  signature S = sig type t end
  functor F : <sig>
  addStr1: pos = 1, |strArray| = 1
  Error: Compiler bug: addStr1
  - 
Comments:		Replacing "functor G ()" with "structure X" 
			successfully compiles.  This is what leads me
			to believe that it is indeed a bug and not me.
			My sincere apologies otherwise.
Status: fixed in 107 (dbm)
----------------------------------------------------------------------
Number: 797
Title: error in example "fol" in mlyacc
Keywords: mlyacc, example
Date: 8/2/93
System(s) and Version:	Solaris, 1.0.1
SML/NJ Version: 	0.93 of Feb 15
Machine: 		Sparc ELC, SunOS, OpenWin
Severity: minor
Problem: lines not counted at lexing time  - example 'fol' 
  in 'mlyacc' subdirs
Fix: replace 'next_line()' for 'next_line' in line 25, file 'fol.lex'
Owner: 
Status: fixed in 109.27
----------------------------------------------------------------------
Number: 798
Title: incorrect sharing violation error
Keywords: modules, signatures, include, sharing
Submitter: 		John Reppy (jhr@research.att.com)
Date: 			8/2/93
System(s) and Version:	Compiler
SML/NJ Version: 	0.97
Machine: 		sparc
Severity: 		major
Problem: 		When building CML, the compiler reports a sharing
			violation that is incorrect.
Code:
(* this code causes the bug *)
signature CONCUR_ML =
  sig

    type 'a event

    type thread_id
    type 'a cond_var
    type 'a chan

  end; (* signature CONCUR_ML *)

signature INTERNAL_CML =
  sig

    datatype 'a queue_t = Q of {front : 'a list ref, rear : 'a list ref}

    include CONCUR_ML

  end; (* INTERNAL_CML *)

structure CML : INTERNAL_CML =
  struct

    datatype 'a queue_t = Q of {front : 'a list ref, rear : 'a list ref}

  (* Per-thread descriptors *)
    datatype thread_id = TID of {  (* thread ids *)
	id	   : int,
	done_comm  : bool ref,		(* set this whenever this thread does *)
					(* some concurrency operation. *)
	death_cond : unit cond_var
      }
  (* condition variables *)
    and 'a cond_var = COND of 'a cond_state ref
    and 'a cond_state
      = COND_unset of (thread_id * bool ref * 'a cont) list
      | COND_set of 'a

  (* channels *)
    datatype 'a chan = CHAN of {
	inq	: (thread_id * 'a cont) chanq,
	outq	: (thread_id * 'a * unit cont) chanq
      }
      withtype 'a chanq = (bool ref * 'a) queue_t

  (* events *)
    datatype abort_fn = NO_ABORT | ABORT of (unit -> unit)
    datatype 'a base_evt = BASE_EVT of {
	  pollfn : unit -> bool,
	  dofn : abort_fn -> 'a,
	  blockfn : (bool ref * abort_fn * (unit -> unit)) -> 'a,
	  abortfn : abort_fn
	}
    datatype 'a event
      = EVT of ('a base_evt list * bool)    (* the boolean is true if one of the *)
					    (* base events has an abort action *)
      | GUARD of (unit -> 'a event)

  end; (* CML *)

signature RUN_CML =
  sig
    structure CML : CONCUR_ML
  end; (* RUN_CML *)

functor RunCML (CML : INTERNAL_CML) : RUN_CML =
  struct
    structure CML : CONCUR_ML = CML
  end; (* functor RunCML *)

signature CONCUR_IO =
  sig
    structure CML : CONCUR_ML
  end; (* CONCUR_IO *)

functor ConcurIO (RunCML : RUN_CML) : CONCUR_IO =
  struct
    structure CML = RunCML.CML
  end; (* functor ConcurIO *)

signature TRACE_CML =
  sig
    structure CML : CONCUR_ML
    structure CIO : CONCUR_IO
  end; (* TRACE_CML *)

functor TraceCML (
    structure CML : INTERNAL_CML
          and RunCML : RUN_CML
	  and CIO : CONCUR_IO
    sharing CML = RunCML.CML = CIO.CML
  ) : TRACE_CML = struct

    open CML (* need to open INTERNAL_CML version before rebinding CML *)

    structure CIO : CONCUR_IO = CIO
    structure CML : CONCUR_ML = CML

  end; (* TraceCML *)

abstraction CML : sig  (* hide the internals, but preserve type equality *)
    structure CML : sig
        include CONCUR_ML
        sharing type thread_id = CML.thread_id
	    and type chan = CML.chan
	    and type event = CML.event
      end
    structure RunCML : RUN_CML
    structure CIO : CONCUR_IO
    structure TraceCML : TRACE_CML
    sharing CML = RunCML.CML = CIO.CML = TraceCML.CML
  end = struct
    structure CML = CML
    structure RunCML = RunCML(CML);
    structure CIO = ConcurIO(RunCML);
    structure TraceCML = TraceCML(
        structure CML = CML
              and RunCML = RunCML
              and CIO = CIO);
  end; (* CML *)

Transcript:
<jhr@arran> /usr/local/sml/97/bin/sparc/sml
Standard ML of New Jersey, Version 0.97, 11 June 1993
- use "bug";
[opening bug]
signature CONCUR_ML =
  sig
    type 'a event
    type thread_id
    type 'a cond_var
    type 'a chan
  end
signature INTERNAL_CML =
  sig
    datatype 'a queue_t
      con Q : {front:'a list ref, rear:'a list ref} -> 'a queue_t
    type 'a event
    type thread_id
    type 'a cond_var
    type 'a chan
  end
structure CML : INTERNAL_CML
signature RUN_CML = sig structure CML : ... end
functor RunCML : <sig>
signature CONCUR_IO = sig structure CML : ... end
functor ConcurIO : <sig>
signature TRACE_CML =
  sig
    structure CML : ...
    structure CIO : ...
  end
functor TraceCML : <sig>
bug:116.26-119.28 Error: structure sharing violation
  RunCML.CML # <Parameter>.CML
bug:101.13-120.5 Error: structure sharing violation
  RunCML.CML # CML
Status: fixed in 102
----------------------------------------------------------------------
Number: 799
Title: bogus type name paths
Keywords: types, type names, printing
Submitter: Carl Gunter
Date: 7/13/93
Version: 0.93?
Severity: minor
Problem: 
  Bogus path names (starting with ?) are displayed in types.
Code: 

  (* Set.sml *)

  (* The SET signature adds various operations to the ORD_SET signature
  from the SML/NJ library *)

  signature SET =
  sig
    include ORD_SET
    val subset : (set * set) -> bool
    val mkset : (item list) -> set
  end

  (* The functor Set extends the functor BinarySet from the library to
  include various new functions by which the SET signature extends the
  ORD_SET signature *)

  functor Set(K : ORD_KEY) : SET =
  struct
    structure BinarySet = BinarySet(K)
    open BinarySet
    fun subset(a,b) =
      ((app (fn x => find(a,x))); true) handle NotFound => false
    fun mkset [] = empty
      | mkset (h::t) = add ((mkset t), h)
  end

	       --------------------------------------------

  structure Atom =
  struct
    datatype atom = Atom of int;
    type ord_key = atom
    fun cmpKey (Atom i, Atom j) =
      if i=j then LibBase.Equal
      else if i<j then LibBase.Less
      else LibBase.Greater
  end

  structure AtomSet = Set(Atom)
Transcript: 
  bolete:$ /usr/local/sml/bin/sparc/sml+lib
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  Library, Version 0.1
  val it = () : unit
  - use "Set.sml";
  use "Atom.sml";

  [opening Set.sml]
  signature SET =
    sig
      type item
      type set
      exception NotFound
      val empty : set
      val singleton : item -> set
      val add : set * item -> set
      val find : set * item -> item
      val peek : set * item -> item option
      val member : set * item -> bool
      val delete : set * item -> set
      val numItems : set -> int
      val union : set * set -> set
      val intersection : set * set -> set
      val difference : set * set -> set
      val listItems : set -> item list
      val app : (item -> 'a) -> set -> unit
      val revapp : (item -> 'a) -> set -> unit
      val fold : (item * 'a -> 'a) -> set -> 'a -> 'a
      val revfold : (item * 'a -> 'a) -> set -> 'a -> 'a
      val subset : set * set -> bool
      val mkset : item list -> set
    end
  functor Set : <sig>
  val it = () : unit
  - [opening Atom.sml]
  structure Atom :
    sig
      datatype atom
	con Atom : int -> atom
      eqtype ord_key
      val cmpKey : atom * atom -> LibBase.relation
    end
  structure AtomSet : SET
  val it = () : unit
  - AtomSet.mkset;
  val it = fn : ?.AtomSet.BinarySet.item list -> ?.AtomSet.BinarySet.set
  - 
Owner: dbm
Status: fixed in 109.31 [dbm, 8/14/97]
----------------------------------------------------------------------
Number: 800
Title: bad definition of dec in profiling script
Keywords: profiler, dec
Submitter: Andreas (andreas@metasoft.com)
Date: 7/15/93
Version: 0.93
Severity: major
Problem: 
You defined the 'dec' function like the 'inc' function (both with 'i+1').

This killed all our attempts to use the profiling image because we use the
'inc' and 'dec' to do some lexical checking (count '(' and ')')

Status: fixed in 1.02
----------------------------------------------------------------------

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