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.1201-1400
ViewVC logotype

View of /bugs/branches/smlnj/bugs.1201-1400

Parent Directory Parent Directory | Revision Log Revision Log


Revision 945 - (download) (annotate)
Thu Oct 4 13:38:32 2001 UTC (17 years, 8 months ago)
File size: 350899 byte(s)
This commit was manufactured by cvs2svn to create branch 'smlnj'.
Number: 1201
Title: ltUnbound in curried functor with where structure
Keywords: modules, functors, where structure
Submitter: Dave MacQueen
Date: 5/16/97
Version: 109.27+ (with SML 97 sharing, where structure, etc.)
System: -
Severity: major 
Problem: 
  A "where structure" clause modifying the second parameter signature
  refers to a substructure of the first parameter.  The result is
  a message "**** hmmm, I didn't find the variable 52" and an uncaught
  ltUnbound exception.
Code:
  signature SA =
  sig
    type t
  end;

  signature SX =
  sig
    structure A : SA
  end;

  signature SY =
  sig
    structure A : SA
  end;

  functor F
    (structure X : SX)
     (structure Y : SY
       where structure A = X.A) =
  struct
  end;

Transcript:
  - use "bug1201.sml";
  [opening bug1201.sml]
  signature SA =
    sig type t end
  signature SX =
    sig structure A : sig type t end end
  signature SY =
    sig structure A : sig type t end end
  **** hmmm, I didn't find the variable 52

  uncaught exception ltUnbound
    raised at: basics/ltyenv.sml:244.32-244.41
	       util/stats.sml:164.40
	       util/stats.sml:164.40
	       util/stats.sml:164.40
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49

Comments:
  An extended variant of this remains open.  See bug 1205. [fixed in 109.31]

Fix: In ElabSig, where a STRdef is created by elabWhere, in the case that
  the STRdef in a CONSTstrDef variant, we replace the access and info fields
  by null values (NO_ACCESS and INL_NO respectively), since these fields 
  are not relevant.  Alternatively we could have CONSTstrDef have a
  record with only the sign and rlzn fields from the structure.

Test: bug1201.sml
Owner: dbm, zhong
Status: fixed in 109.28 [dbm, 5/19/97]
----------------------------------------------------------------------
Number: 1202
Title: Unbound in functor with where structure clause on parameter sig
Keywords: modules, functors, where structure
Submitter: Dave MacQueen
Date: 5/16/97
Version: 109.27+ (with SML 97 sharing, where structure, etc)
System: -
Severity: major
Problem: 
  where structure clause in parameter signature causes uncaught
  exception Unbound
Code:
  signature SA =
  sig
    type t
  end;

  signature SX =
  sig
    structure A : SA
  end;

  signature SY =
  sig
    structure A : SA
  end;

  functor F
    (structure X : SX
     structure Y : SY
       where structure A = X.A) =
  struct
  end;

Transcript:
  - use "bug1202.sml";
  [opening bug1202.sml]
  signature SA =
    sig type t end
  signature SX =
    sig structure A : sig type t end end
  signature SY =
    sig structure A : sig type t end end

  uncaught exception Unbound
    raised at: elaborate/elabmod.sml:1144.39-1144.49
	       util/stats.sml:164.40
	       build/evalloop.sml:120.38
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49

Comments:
  Note that in bug1202.3, the explicit definition of the parameter
  signature SZ works, but the functor declaration still fails with
  uncaught Unbound.

  This is probably the same bug as 1200.
Fix: 
Test: bug1202.1.sml, bug1202.2.sml, bug1202.3.sml
Owner: dbm
Status: fixed in 109.28 [dbm,5/20/97]
----------------------------------------------------------------------
Number: 1203
Title: structure def spec doesn't work
Keywords: modules, signatures, functors, structure definition spec
Submitter: Dave MacQueen
Date: 5/16/97
Version: 109.27+ (with SML 97 sharing, where structure, etc)
System: -
Severity: major 
Problem: 
  A structure def spec in a functor parameter signature doesn't have
  the expected effect.
Code:
  signature S =
  sig
    type t
  end;

  structure A : S =
  struct
    type t = int
  end;

  functor F1(X: sig type t = A.t end) =
  struct
    val x : X.t = 3
  end;

  functor F2(X: sig structure B: S = A end) =
  struct
    val x : X.B.t = 3
  end;

Transcript:
  - use "bug1203.sml";
  [opening bug1203.sml]
  signature S =
    sig type t end
  structure A :
    S
  functor F1 : <sig>
  GC #0.0.0.0.1.2:   (0 ms)
  bug1203.sml:18.3-18.20 Error: pattern and expression in val dec don't agree [literal]
    pattern:    ?.t
    expression:    int
    in declaration:
      x : ?.t = (3 : int)

  uncaught exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49

Comments:
Fix:
Test: bug1203.sml
Owner: dbm
Status: fixed in 109.28 [dbm]
----------------------------------------------------------------------
Number: 1204
Title: invalid paths in lhs of where clauses
Keywords: modules, signatures, where clauses
Submitter: Dave MacQueen
Date: 5/16/97
Version: 109.27+ (SML 97 sharing, where structure, etc.)
System: -
Severity: major 
Problem: 
  An invalid path in the the lhs of a where clause is not detected
  when a signature is elaborated, and causes uncaught Unbound when
  the signature is instantiated as a functor parameter.
Code:
 This causes no complaint:

  (* bug1204.1.sml *)

  signature S =
  sig
    type t
  end;

  signature S1 = S where type A.t = int;

 while this causes uncaught exception Unbound:

  (* bug1204.2.sml *)

  signature S =
  sig
    type t
  end;

  functor F(X: S where type A.t = int) =
  struct end;

Comments:
Fix: added checkWhereDefs in ElabSig to check that lhs paths are valid.
Test: bug1204.1.sml, bug1204.2.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 5/17/98]
----------------------------------------------------------------------
Number: 1205
Title: problem with "where structure" and curried functors (cf. 1201)
Keywords: modules, functors, curried functors, where structure
Submitter: Dave MacQueen
Date: 5/21/97
Version: 109.27+ (109.28)
System: -
Severity: major
Problem: 
  Defining the result of a curried functor by partial application of another
  curried functor, a "where structure" spec is not matched.
Code:
  (* bug1205.sml *)

  signature SA =
  sig
    type t
  end;

  signature SX =
  sig
    structure A : SA
  end;

  signature SY =
  sig
    structure A : SA
  end;

  functor F
    (structure X : SX)
     (structure Y : SY
       where structure A = X.A) =
  struct
    fun f(x: X.A.t, y: Y.A.t list) = x::y
  end;

  functor G(structure A : SA) : 
    sig
      functor G1(structure Y: SY where structure A = A) : sig end
    end =
  struct
    functor G1 = F(structure X = struct structure A = A end)
  end;

Transcript:
  [opening test/bugs/bug1205.sml]
  signature SA =
    sig type t end
  signature SX =
    sig structure A : sig type t end end
  signature SY =
    sig structure A : sig type t end end
  GC #0.0.0.0.1.5:   (0 ms)
  functor F : <sig>
  test/bugs/bug1205.sml:26.9-32.4 Error: where structure spec not matched: A

  uncaught exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49
Comments:
  This bug represents a problem with MLRISC/mlrisc/ra.sml and
  MLRISC/hppa/hppaRegAlloc.sml and MLRISC/alpha32/alpha32RegAlloc.sml.
Fix:
  In processing structure def specs or where structure defs,   
  lookStrDef has to relativize structures that are local to a functor
  (such as the functor parameter), turning CONSTstrDefs into VARstrDefs
  for such local structures.  A local version of lookStrDef was defined
  within ElabSig (which is the only module using Lookup.lookStrDef) that
  does this relativization.
Test: bug1205.sml
Owner: dbm, Zhong
Status: fixed in 109.31 [dbm, 8/14/97]
----------------------------------------------------------------------
Number: 1206
Title: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
Keywords: modules, functors, TransTypes
Submitter: George Russell <george@persimmon.co.uk>
Date: 5/7/97
Version: 109.28-
System: -
Severity: major 
Problem: 
  Compiling the code below (which requires smlnj-lib) causes 
  Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
Code:
  functor Dictionary (HK:HASH_KEY):
  sig type 'b dictionary 
     val create: int->'b dictionary 
  end=
  struct
     structure Hash=HashTableFn(HK)

     exception NF
     type 'b dictionary='b Hash.hash_table
     fun create i=Hash.mkTable(i,NF)
  end
  functor T(S:HASH_KEY)=
  struct
     structure U=Dictionary(S)
     datatype v=v of int U.dictionary
     fun cre n=v(U.create n)
  end;
  structure OP=T(struct
	type hash_key=Word.word
	fun hashVal k=k
	val sameKey=op=
     end)

  [Zhong, 5/7/97] I have narrowed your code further down the following
  (it does not rely on the SML Library any more):

  functor Dict (type t) : sig type dict
			  end
  = struct
      datatype dict = HT of t | NIL
      type dict = dict     (* removing this line, the bug goes away *)
    end

  functor T(type t) =
    struct structure U = Dict(type t = t)
	   datatype s = EE of U.dict | FF
	   val x = FF
    end;

  structure A = T(type t = int)

Transcript:
  - use "/usr/local/sml/bugs/tests/bug1206.sml";
  [opening /usr/local/sml/bugs/tests/bug1206.sml]
  functor Dictionary : <sig>
  functor T : <sig>
  Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h

  uncaught exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       util/stats.sml:164.40
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49
Comments: [Zhong, 6/24/97]
  (* The following is a narrowed-down version of the code. The code raises
     the following exception:

     - [opening ztodo/z3.sml]
     functor T : <sig>
     Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h

     I managed to track it down and understand that the bug is caused
     by the incorrect management of "epContext".

     The scenerio is like this: datatype u is shadowed by another DEFtyc
     u inside U, so it is not exported by structure U; when we enter
     structure U, we create a new level of epContext, but when finish
     processing structure U, this level of epContext is popped off; 
     we do try to recover the epContext binding all the components 
     exported by structure U, but not the shadowed datatype "u". 

     Therefore, when we process datatype s, the type U.u is not properly
     relativized because the shadowed version of u is not in the epContext.

     Possible fixes: we have to adjust the "enterClosed" or the "mapEPC"
     functions to take account these shadowed type bindings.
   *)

  functor T(type t) =
    struct 
      structure U = 
	struct
	  datatype u = HT of t 
	  type u = u      (* removing this line, the bug goes away *)
	end
      datatype s = EE of U.u 
      val x = fn (_: s) => 0
    end;

  structure A = T(type t = int)
Fix:
  Added enterOpenNew and mergeHidden functions to modules/epcontext.sml
  and called them within function elabStrbs in elaborate/elabmod.sml.
  The effect is the preserve mappings for local hidden types that won't
  be found by the call to mapPaths, like the internal datatype u in
  the above code.
Test: bug1206.sml (requires smlnj-lib), bug1206.2.sml
Owner: Zhong, dbm
Status: fixed in 109.32 (dbm, 7/21/97)
----------------------------------------------------------------------
Number: 1207
Title: unimplemented include syntax
Keywords: syntax, parsing, include, signatures
Submitter: John Reppy
Date: 5/22/97
Version: 109.29
System: -
Severity: medium
Problem:
  The syntax for the basic "include" spec is

    include sigexp
 
  (page 14, DSMLR).  Only sidids are accepted as arguments now.
Comments:
  The derived form 

    include sigid1 ... sigidn

  is implemented properly.  The derived form does not allow for sigexps.
Code: (from Andrew Kennedy)
  signature SIG =
  sig 
    datatype d = c include sig type t end where type t = d 
  end;
Transcript:  Error: Compiler bug: Include: elabInclude
Fix:
Test: bug1207.sml
Owner: dbm
Status: fixed in 110 [dbm, 10/25/97]
----------------------------------------------------------------------
Number: 1208
Title: unimplemented strexp syntax
Keywords: syntax, parsing, structures
Submitter: Dave MacQueen
Date: 6/19/97
Version: 109.29
System: -
Severity: major 
Problem: 
  Syntax for structure expressions includes 

    strexp : sigexp

  (DSMLR, p.13). This isn't implemented.

Comments:
Fix:
Test:
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1209
Title: casting polymorphic functions and abstract types
Keywords: cast, polymorphism, abstract types
Submitter: Chris Paris <cap@cmu.edu>
Date: 5/28/97
Version: 109.28
System: ?
Severity: minor
Problem: 
  casting a polymorphic function causes a Compiler bug.  A better error
  message should be generated.
Transcript:
  - fun subst (f : 'a -> unit) = System.Unsafe.cast f ();
  Error: Compiler bug: Contract: UsageMap on 158
  
Comments:
[Paris]
  I reworked some of my code, and I believe I have it working in 109.28
  now. In response to a comp.lang.ml post I made a while ago, Zhong Shao
  suggested that the introduction of the FLINT code would change the
  behavior of the cast function, so that I get to write one evil thing
  instead of another. The "nicer" approach seems to work in 109.28,
  though I don't know why my earlier code broke between 27 and 28, since
  I thought that FLINT has been around for a while now.

[Zhong]
  While FLINT has been around for a few months, it is changing almost every 
  week :-) There are some major differences between 27 and 28, one is the
  default calling conventions for polymorphic functions --- the result
  is that it is no longer safe to directly cast a polymorphic function 
  from "'a -> unit" into "unit -> unit".

  Future compilers will report such "unsafe" uses of cast. For the time
  being, the compiler does not bother, the CPS optimizer takes the code and
  complains about "Contract: UsageMap on 158". I'll try to get a fix 
  into 109.29. 

[jhr]
  The example where I get this bug involves converting the type

	  (char -> char) -> string -> string

  to

	  (Word8.word -> Word8.word) -> Word8Vector.vector -> Word8Vector.vector

  No polymorphism is involved, and the representations of the two types should
  be the same.

[Zhong]
  There is a bug in 109.28 on representation analysis of values 
  with "abstract types". In this case, Word8Vector.vector is an 
  abstract type created by :> in boot/built-in.sml. I'll try to
  fix this in 109.29.

  In general, care must be taken when creating new types using :>.
  For example,

	  structure V :> sig
		eqtype vector
		val create : int -> vector
	      end = struct
		type vector = string
		val create = Assembly.A.create_s
	      end

  representation analysis would think V.vector has type

	  TC_ABS (string) 

  and process it in the same way as other abstract types (with
  same shapes but different type stamps). A better way to 
  add built-in types such as word8vector is to directly add it 
  into the initial Prim environment. 

  There are no guarantees that values of type T and ABS(T) would
  have same representations (right now, T and ABS(T) would have 
  same representations if T is "boxed" in a canonical way)

Fix: same as fix for 1323?
Test: bug1209.sml
Owner: Zhong
Status: fixed in 110.0.1 [Zhong, 1/7/98]
----------------------------------------------------------------------
Number: 1210
Title:       weak pointers to strings cause SML to crash
Keywords:    weak pointers
Submitter:   Edo Biagioni, esb@cs.cmu.edu
Date:        05/30/1997
Version:     109.27
System:      DEC alpha Osf1 V3.2
Severity:    minor

Transcript:  

% /afs/cs.cm.edu/project/fox/port/109.27/bin/sml
Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM&CMB]
val it = () : unit
- val a = "foo";
val a = "foo" : string
- val b = SMLofNJ.Weak.weak a;
val b = - : string ?.weak
- SMLofNJ.Internals.GC.doGC 0;
GC #1.1.1.1.1.2:  /afs/cs.cmu.edu/project/fox/port/109.27/bin/.run/run.alpha32x-osf1: Fatal error -- weak big object

Comments:
[jhr]
  Actually, this bug is weak pointers to big objects (aka, code).  Heap allocated
  strings should work okay.  This will be fixed when we go to the new array/vector
  representations.
Fix:
Test:
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1211
Title: signature problems not reported until signature instantiation
Keywords: modules, signatures, instantiation
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 5/30/97
Version: 109.28
System: -
Severity: major
Problem: 
  I'm having trouble migrating my code to the new rules for sharing.
  The error message I get is:
    control.nw:94.9-94.44 Error: rigid type spec in sharing: item
  The source code prompting this message is:
    functor CodeBogus(Code : CODE) = struct end

  It would be more helpful if
    - the error message were issued when the CODE signature was compiled
    - the source locations referred to in the message contained the offending
      sharing constraint
    - the README file for 109.28 indicated what error message to expect
      when the new illegal constructs are used.  This way I could correlate
      the error message with the potential problem.
Comments:
Fix:
  Need to instantiate signatures where they are declared to detect these
  errors at the appropriate point.  This could be controlled by a
  flag that could turn off instantiation when recompiling debugged code.
Test:
Owner: dbm, Zhong
Status: fixed in 109.30 [dbm]
----------------------------------------------------------------------
Number: 1212
Title: where structure when signatures differ
Keywords: modules, where structure, SML97
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 5/30/97
Version: 109.28
System: -
Severity: major 
Problem: 
  I am informed:
    elabexp.nw:32.9...53.4 Error: Inconsistent defining constraints : type item = item

  I introduced this error by replacing

  functor ElabExpFun (structure Denotable : DENOTABLE
		      structure DoublePattern : DOUBLE_PATTERN
			  sharing DoublePattern.Normal = Denotable.Pattern
		      val simplify : Denotable.Constructor.Pattern.Exp.exp ->
				     Denotable.Constructor.Pattern.Exp.exp
		     ) : ELAB_EXP = struct ... end
   with

  functor ElabExpFun (structure Denotable : DENOTABLE
		      structure DoublePattern : DOUBLE_PATTERN
			  where structure Normal = Denotable.Pattern
		      val simplify : Denotable.Constructor.Pattern.Exp.exp ->
				     Denotable.Constructor.Pattern.Exp.exp
		     ) : ELAB_EXP = struct ... end

  The replacement was necessary because the two structures have
  difference signatures and both signatures are full of 'rigid' type
  definitions (I've forgotten the proper term for these).

  I have no idea how to track down and diagnose this error.
  Some more source locations in the error message might help.

Comments:
  Same as bug 1232.
Fix:
Test:
Owner: dbm
Status: fixed in 109.30
----------------------------------------------------------------------
Number: 1213
Title: CM dependency analysis
Keywords: CM, dependency
Submitter: Andrew Kennedy <andrew@persimmon.co.uk>
Date: 6/3/97
Version: 109.28
System: -
Severity: major
Problem: 
  I don't have sample code for this one; I'm hoping that my vague
  description will suffice. The situation is that a structure imports
  another structure but only by way of rebinding e.g.

    structure STR1 = struct

    structure STR2 = STR3

    .... STR2.x  ...

    end

  so that STR3 is never used in a qualified identifier. This seems to
  trick the compilation manager into thinking that STR3 is not referenced
  in STR1, leading to compilation errors such as "no such structure STR3".
  However, if one of the qualified identifiers (such as STR2.x above) is
  replaced by its synonym (STR3.x) then this fixes things. What's more, I
  can then change it back to STR2.x and the compilation manager seems to
  `remember' that STR1 referred to STR3. 

Comments:
Fix:
Test:
Owner: Matthias
Status: not reproducible [blume, 8/3/97]
----------------------------------------------------------------------
Number: 1214
Title:       Increased make time
Keywords:    CM, memory usage
Submitter:   Emden R. Gansner, erg@research.att.com
Date:        Wed Jun  4 17:35:01 EDT 1997
Version:     109.28
System:      Only tested on irix-mips
Severity:    minor
Problem:     There seems to be a dramatic increase in make time
             from 109.27 to 109.28
Code:        
Transcript:  
  <load in CML & eXene, plus 3 small files>
  <edit one file and run CM.make()>
  In 109.27, the entire process takes 20 secs and I get something like
  the following:

[dependency analysis completed]
GC #3.23.28.47.230.7259:   (34 ms)
GC #3.23.28.47.231.7305:   (29 ms)
GC #3.23.28.47.232.7343:   (18 ms)
GC #3.24.29.48.233.7406:   (127 ms)
GC #3.24.29.48.234.7455:   (9 ms)
GC #3.24.29.48.235.7523:   (18 ms)
GC #3.24.29.48.236.7581:   (23 ms)
GC #3.24.29.48.237.7657:   (19 ms)
GC #3.24.29.48.238.7735:   (29 ms)
[compiling bezier.sml -> CM/mipseb-unix/bezier.sml.bin]

  In 109.28, the entire process takes 60 secs and I get something like
  the following:

[dependency analysis completed]
GC #2.15.16.21.104.6631:   (35 ms)
GC #2.15.16.21.105.6741:   (19 ms)
GC #2.15.16.21.106.6841:   (10 ms)
GC #2.15.16.21.107.6955:   (13 ms)
GC #2.15.16.21.108.7097:   (7 ms)
GC #2.15.16.21.109.7242:   (5 ms)
GC #2.15.16.21.110.7341:   (48 ms)
GC #2.16.17.22.111.7408:   (97 ms)
GC #2.16.17.22.112.7417:   (1 ms)
GC #2.16.17.22.113.7453:   (34 ms)
GC #2.16.17.22.114.7520:   (8 ms)
GC #2.16.17.22.115.7586:   (42 ms)
GC #2.17.18.23.116.7728:   (159 ms)
GC #3.18.19.24.117.7774:   (736 ms)
GC #3.18.19.24.118.7816:   (37 ms)
GC #3.18.19.25.119.7887:   (33 ms)
GC #3.18.19.25.120.7968:   (43 ms)
GC #3.18.19.25.121.8107:   (31 ms)
GC #3.18.19.25.122.8258:   (17 ms)
GC #3.18.19.25.123.8389:   (17 ms)
[compiling bezier.sml -> CM/mipseb-unix/bezier.sml.bin]

Comments:
  This was caused by supplying a context entityEnv when building a
  realization for a closed signature in modules/instantiate.sml.
Fix:
Test:
Owner: dbm
Status: fixed in 109.30
----------------------------------------------------------------------
Number: 1215
Title: Unaligned access messages
Keywords: reals, real arrays, alignment
Submitter: George Russell <george@persimmon.co.uk>
Date: 4/3/97
Version: 109.26
System: alpha, OSF4.0 (& probably OSF3.2)
Severity: major
Problem: 
  Following code produces lots and lots of "Unaligned access . . ."
  messages.
Code:
  Array.tabulate(500,fn i=>RealArray.array(500,0.0));
Transcript:
Comments: [Lal]
  This bug appears to be garbage collection related.
  Executing:

	  Array.tabulate(100, fn i=>RealArray.array(500,0.0));

  results in a large number of unaligned accesses. However, executing
  this under:

	  sml @SMLalloc=10M

  works fine. 
 [jhr, 7/31/97]
  This is the same as bug 1227, which is fixed in 109.30.
Fix:
Test: bug1215.sml
Owner: Lal, jhr
Status: fixed in 109.30 [jhr]
----------------------------------------------------------------------
Number: 1216
Title: curried higher-order functors not accepted
Keywords: modules, functors, higher-order functors
Submitter:      Zhong Shao (shao@cs.yale.edu)
Date:           April 4, 1997
Version:        109.29
System:         all platform 
Severity:       minor
Problem:        curried higher-order functors not accepted
Code:           
 
      signature SIG = sig end
      functor F (A : SIG) (B : SIG) = struct end
      structure V = struct end
      structure X = F (struct end) (struct end)
      structure Y = F (structure A = V) (structure B = V);

      structure Z = F V V ; (* this one is problematic *)

Transcript:    

      - signature SIG =  sig end
        functor F : <sig>
        structure V :  sig end
        structure X :  sig end
        structure Y :  sig end
      - stdIn:94.23 Error: syntax error found at ID

Comments: 
 
      Probably this is not a bug. But I was never clear about
      the currying syntax for higher-order functors. Is the
      functor application "(F V V)" allowed ? 

 [dbm]
  Not a bug.  Parantheses are required around all functor arguments.
Fix:  
Test: bug1216.sml
Owner: dbm
Status: not a bug
----------------------------------------------------------------------
Number: 1217
Title: Compiler generates exception [FPRegEA].
Keywords: code generation
Submitter: ?
Date:        5/1/97
Version:     109.27
System:	     x86-linux
Severity:    major
Problem:     Compiler generates exception [FPRegEA].
Code:	     val foo = fn x : 'a * 'b => [x]
             val bar = fn y => foo(y,13)
Transcript:  
Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
- val foo = fn x : 'a * 'b => [x]
  val bar = fn y => foo(y,13) ;

uncaught exception in compiler: FPRegEA
  raised at: cps/generic.sml:98.67-98.74
             util/stats.sml:164.40
             util/stats.sml:164.40
             build/evalloop.sml:191.58

Comments:    For the polymorphic function 'foo',
             because 'x' is put in a list, representation analysis
             generates special code (governed by a runtime test) that
             coerces 'x' to its boxed representation if 'x' is a pair
             of floats.  In the cps optimizer, because the call to
             'foo' in 'bar' is known, it is inlined.  Because the type
             of 'y' is unknown, the runtime test in 'foo' remains, and the
             special case code for floating points is not dead.
             However, the record '(y,13)' is known and the coercion
             code for floating point attempts to coerce this record
             to its boxed representation, which causes it to think
             that '13' can be put in a floating point register.

             The bug occurs if you attempt to batch compile ml-yacc
             (i.e. if you cat all the source files and compile as one
             declaration).

Fix:	     This is speculative, but the representation analysis uses
             the following idiom, which is not type correct:

             Lambda alpha. lambda z:alpha.
               typecase alpha of
                  float =>  <code depends on z being a float>
                  _ => <code that ignores the type of z>

             The idiom could be replaced by the following, which is
             type correct:

             Lambda alpha. 
               typecase alpha of
                  float => lambda z:float.<code depends on z being a float>
                  _ => lambda z:alpha.<code that ignores the type of z>

Comment:
 [Lorenz, 5/1/97]
  For what it's worth, this bug appeared in the transition from 
  109.23 to 109.24, appears (at least) on x86-linux and sparc-solaris,
  but not on mipseb-unix.

 [Zhong, 5/1/97]
  Thanks for the bug report (and also suggestion the fix). This was really 
  bug 1175 in the masterbug list.  I have fixed it and will incorporate 
  the fix into 109.28. 

Test: bug1217.sml
Owner: Zhong
Status: fixed in 109.28 [Zhong]
----------------------------------------------------------------------
Number: 1218
Title: increase in size of exportFn image
Keywords: exportFn, image size
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 5/1/97
Version: 109.27
System: ?
Severity: major 
Problem: 
  The size of the image that is exported with 109.27
  is significantly higher than with for instance version
  108. I made the following tests:
Transcript:
  [108:]

  structure Test = 
  struct

  fun dummy(_,[name]) = 
      (print ("Hi I am "^name^"\n"))

  fun export() = 
      exportFn("/step/sml-108/bin/.heap/hi",dummy)

  end


  [109.27:]

  structure Test = 
  struct

  fun dummy(name,_) = 
      (TextIO.print ("Hi I am "^name^"\n");
       OS.Process.success)

  fun export() = 
      SMLofNJ.exportFn("/step/sml/bin/.heap/hi",dummy)

  end

  The sizes of the exported images were:

  108:
  -rw-rw----   1 nikolaj    196292 May  1 22:42 hi

  109.27
  -rw-rw----   1 nikolaj    500824 May  1 22:38 hi.sparc-solaris

  For larger executables the situation gets even worse. I 
  reported an image size of more than 35 MB in 109.27 compared
  to approx 13 MB in 108.

Comments:
 [Zhong, 5/2/97]
  This difference seems to be caused from changes in the runtime
  system, as even the image for a null function is about this 
  big. 

     fun export1() = SMLofNJ.exportFn("xxx1", dummy);
     fun export2() = SMLofNJ.exportFn("xxx2", fn _ => 0);

  -rw-r--r--   1 shao     systems   449616 May  2 09:38 xxx1.sparc-solaris
  -rw-r--r--   1 shao     systems   433232 May  2 10:55 xxx2.sparc-solaris

  I also checked the runtime closures for both the dummy function and
  the "fn _ => 0" function, they all contain minimum amount of 
  free variables.

  |> For larger executables the situation gets even worse. I 
  |> reported an image size of more than 35 MB in 109.27 compared
  |> to approx 13 MB in 108.
  |>
  |> Is there any way to improve on this situation?

  This could be caused by completely different reasons from the previous.
  Sorry for keeping asking this, but if you can ship us the entire 
  source code, we can probably take a look and narrow the problem down
  for you.

 [Nikolaj, 5/20/97]
  A.
  --

  I was asked if I could provide a more realistic example
  where the size of the exported image problem showed up
  in the 109 version. The example directory in eXene 
  (the bricks example) appears to be excellent.

  With 108:

  -rw-rw----   1 nikolaj   1490428 May 20 14:17 /step/sml-108/bin/.heap/bricks

  With 109.27:

  -rw-rw----   1 nikolaj  12978676 May 20 14:21 /step/sml/bin/.heap/bricks.sparc-solaris

  As we can see, the size of the image is almost 10 times larger for this small eXene example.


  The size problem seems however not to be an artifact of eXene.
  I have exported images that are purely ML (that do not use CML)
  that are much larger than they should be. The fact that I am using
  an eXene demo is that it was the first and best example that I could find.


  B.
  --

  I have previously reported problems with CM. I still think there is something
  fishy about CM. Some of the problems appear to arise when the same files are loaded
  using different .cm files. If person A has one cm file and person B has a different
  one that loads different files, and A and B both use SCCS they may see different
  versions of files that other files depend on. It is typically possible to hack around
  this so I have not been eager to clarify the source of the problems precisely.

  C.
  --

  eXene/CML may have some problems running under Linux and over the network. 
  We have just started to port our system to a laptop (IBM thinkpad 760 E).
  Here the Inbuf appears to die as well as IO exceptions are raised at will.
  Over the network (phone line) in Inbuf dies. Other applications (emacs,...)
  do not have these problems.

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


  Below follows the modifications I did to export the images (so you can reproduce it):

  109:

  examples/bricks/sources.cm:
  Group
  is

    cml.cm
    cml-lib.cm
    ../../sources.cm

    util.sml
    brickview.sml
    brick.sml
    wall.sml
    badbricks.sml
    export.sml


  examples/bricks/export.sml:


  structure Export = 
  struct

    val tq = Time.fromMilliseconds 20

    fun main(name,display::args) = 
	(RunCML.doit(fn ()=>BadBricks.badBricks display,SOME tq);
	 OS.Process.success)

    fun export() = 
	SMLofNJ.exportFn("/step/sml/bin/.heap/bricks",main)

  end

  -----------------------------------------------
  108:

  examples/bricks/sources.cm:
  (* sources file for triangle demo *)
  Group
  is
  /step/sml-108/lib/smlnj-lib.cm
  /step/sml-108/lib/cml.cm
  /step/sml-108/lib/cml-lib.cm
  ../../sources.cm

  util.sml
  brickview.sml
  brick.sml
  wall.sml
  badbricks.sml
  export.sml

  examples/bricks/export.sml:


  structure Export = 
  struct

    fun main(env,display::args) = 
	BadBricks.badBricks display

    fun export() = 
	RunCML.exportFn("/step/sml-108/bin/.heap/bricks",main,SOME 20)

  end


  examples/bricks/brickview.sml: 
  This does not compile under 108, so I corrected it with parts from 109.

  Replaced:

       fun showText (backc, framec) txt _ = (
	  Label.setBackground label backc;
	  Label.setLabel label (Label.Text txt);
	  Frame.setColor frame framec;
	  framec)

	val showView = showText (#concrete palette, SOME(#lightLines palette))
	val endView = showText (#brick palette, SOME(#lightLines palette))
	val markView = showText (#mark palette, SOME(#darkLines palette)) "ok"
	val normView = showText (#brick palette, SOME(#darkLines palette)) ""

  examples/bricks/wall.sml:
  This does not compile under 108, so I corrected it with parts from 109.

  Replaced:

	fun setMsg txt = Label.setLabel msgArea (Label.Text txt)

 [Zhong, 5/21/97]
  Hi, Nikolaj, Thanks very much for narrowing down the problem for us. 
  I can reproduce the image size using the following export.sml:

    structure Export = 
      struct
	fun export() = 
	 SMLofNJ.exportFn("bricks", fn _ => (RunCML.doit (fn () => (), NONE); 0))
      end

  There are definitely wierd thing going on with exportFn. As if I use
  the following sources.cm file:

    Group
    is

    cml.cm
    cml-lib.cm
    ../../sources.cm

    util.sml
    brickview.sml
    brick.sml
    wall.sml
    badbricks.sml
    export.sml

  I get 12Mbytes image, while if I use this sources.cm file:

    Group
    is

    cml.cm
    cml-lib.cm
    export.sml

  I get only 8.2Mbytes. Even though export.sml does not refer to
  anything in eXene or brick code at all. 

  Clearly, the closure for RunCML.doit function contains a pointer
  to all the toplevel environments. Even worse, I am afraid that
  it contains a pointer to the top-level environment (where code
  for bricks and eXene stays). 

  This bug occurs also in version 109.16 (with probably 1.2 Mbytes
  smaller image size, which is the image size difference between
  sml-cm-109.16 and sml-cm-109.27). 

  John, what are the main differences between 108's RunCML.doit and
  109.16's RunCML.doit ? Would the new code possibly hold more 
  free variables ?

  |> The size problem seems however not to be an artifact of eXene.
  |> I have exported images that are purely ML (that do not use CML)
  |> that are much larger than they should be. The fact that I am using
  |> an eXene demo is that it was the first and best example that I could find.

  It is possible that the image-size problems for these purely-ML code
  are caused by different reasons (from the brick example above). We'll
  continue diagnosing the problem, at the same time, we would very 
  appreciate you send us new (purely-ML) examples if you happen to run
  into any of them in the future. 

 [Bjorner, 8/7/97]
  The recent bugfixes in version 109.30 offered some hopes that
  the heap size bug has been fixed. This appears not to be the
  case:

  -rw-rw----   1 root     14293696 Aug  7 08:38 bricks.sparc-solaris

  is the 109.30 size of the bricks exported image. Compared with
  previous sizes this is a clear worsening.

 [Bjorner, 8/7/97]
  I have previously communicated with various members of the SML/NJ
  team on the memory problems in versions 109.**. Desparately trying
  to track the problem down further in 109.30 (it is really a serious
  problem for us and others who wish to use SML/NJ images on reasonable
  hardware) I ran into the following simple scenario that can recreate 
  some weird memory behaviour.

  I am still a bit frustrated that I am don't have an overview of the
  source code of SML/NJ which could allow me to track the problem in
  a more systematic way. What are the documents describing the design
  of the present compiler?

  Regards
	  Nikolaj


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

  sources.cm:

  Group
  is


  (** (* C *)
    cml.cm
    cml-lib.cm

   **)

    export.sml


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


  structure Export = 
  struct

    val tq = Time.fromMilliseconds 20

    fun main(name,display::args) = 
  (** (* A *)
	(TextIO.print "dummy"; OS.Process.success) 
  **)
  (** (* B *)
	(RunCML.doit(fn ()=>(),SOME tq);
	 OS.Process.success) 
   **)


    fun export() = 
	SMLofNJ.exportFn("dummy",main)

  end

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

  1. To obtain an image of with 318 big objects (9 MB!) uncomment C and B.

  2. Then comment B, and uncomment A. This still gives the same image size.

  3. Then comment C. This gives 38 big objects, about 0.5 MB (nice and "small").

  4. Then uncomment C. This still gives only 38 big objects, different than
     point 2 although the CM.sa files look exactly the same!
     It has been listed below.

  To narrow the source of the problems down further it should also
  be possible to recreate the situation with the reference to cml-lib.cm
  deleted from the sources.cm. This already seems to follow from the CM.sa
  generate file below. 
  Even when replacing C by:

    /sml-109.30/src/cml/src/Unix/sources.cm

  in step 2 I get the 9 MB large image size.

  In comparison when compiling the following under version 108 I only
  get 22 big objects ( 0.3 MB). This is the 108 equivalent of step 1 above.

  sources.cm
  ----------

  Group
  is

    /sml-108/lib/cml.cm

    export.sml


  export.sml
  ----------

  structure Export = 
  struct

    val tq = Time.fromMilliseconds 20

    fun main(name,display::args) = 
	(RunCML.doit(fn ()=>(),SOME 20);())


    fun export() = 
	exportFn("dummy",main)

  end



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

  CM.sa for step 1,2,3,4:

  local open Compiler.CMSA val pervenv = pervenv ()
  val o1 = run ("/step/sml-109.30/src/cml/src/core-cml/rep-types.sml", pervenv)
  val d0 = layer [o1, pervenv]
  val o2 = run ("/step/sml-109.30/src/cml/src/core-cml/queue.sml", d0)
  val o3 = run ("/step/sml-109.30/src/cml/src/core-cml/debug.sml", pervenv)
  val d1 = layer [o1, o2, o3, pervenv]
  val o4 = run ("/step/sml-109.30/src/cml/src/core-cml/scheduler.sml", d1)
  val o5 = run ("/step/sml-109.30/src/cml/src/core-cml/event-sig.sml", pervenv)
  val d2 = layer [o1, o4, o5, pervenv]
  val o6 = run ("/step/sml-109.30/src/cml/src/core-cml/event.sml", d2)
  val d3 = layer [o6, pervenv]
  val o21 = run ("/step/sml-109.30/src/cml/src/OS/os-io-sig.sml", d3)
  val o22 = run ("/step/sml-109.30/src/cml/src/OS/os-process-sig.sml", d3)
  val d4 = layer [o21, o22, pervenv]
  val o23 = run ("/step/sml-109.30/src/cml/src/OS/os-sig.sml", d4)
  val d5 = layer [o21, o22, o23, pervenv]
  val o24 = run ("/step/sml-109.30/src/cml/src/OS/os-signatures.sml", d5)
  val f0 = filter [SIG "OS", SIG "OS_IO", SIG "OS_PROCESS"]
  val d6 = f0 o24
  val d7 = layer [o1, o4, o6, pervenv]
  val o13 = run ("/step/sml-109.30/src/cml/src/core-cml/io-manager.sml", d7)
  val o0 = run ("/step/sml-109.30/src/cml/src/core-cml/version.sml", pervenv)
  val o7 = run ("/step/sml-109.30/src/cml/src/core-cml/thread-sig.sml", pervenv)
  val d8 = layer [o1, o4, o6, o7, pervenv]
  val o8 = run ("/step/sml-109.30/src/cml/src/core-cml/thread.sml", d8)
  val o9 = run ("/step/sml-109.30/src/cml/src/core-cml/channel-sig.sml", pervenv)
  val d9 = layer [o1, o2, o4, o6, o8, o9, pervenv]
  val o10 = run ("/step/sml-109.30/src/cml/src/core-cml/channel.sml", d9)
  val o11 = run ("/step/sml-109.30/src/cml/src/core-cml/timeout-sig.sml", pervenv)
  val d10 = layer [o1, o4, o6, o11, pervenv]
  val o12 = run ("/step/sml-109.30/src/cml/src/core-cml/timeout.sml", d10)
  val d11 = layer [o5, o7, o9, o11, pervenv]
  val o14 = run ("/step/sml-109.30/src/cml/src/core-cml/cml-sig.sml", d11)
  val d12 = layer [o0, o6, o8, o10, o12, o14, pervenv]
  val o15 = run ("/step/sml-109.30/src/cml/src/core-cml/cml.sml", d12)
  val d13 = layer [o13, o15, d6, pervenv]
  val o25 = run ("/step/sml-109.30/src/cml/src/Unix/os-io.sml", d13)
  val f1 = filter [SIG "OS", STR "OS_Process", SIG "OS_IO", STR "OS_IO", SIG "OS_PROCESS", STR "ProcManager"]
  val d14 = f1 o25
  val d15 = layer [o15, pervenv]
  val o16 = run ("/step/sml-109.30/src/cml/src/core-cml/sync-var-sig.sml", d15)
  val d16 = layer [o1, o2, o4, o16, pervenv]
  val o17 = run ("/step/sml-109.30/src/cml/src/core-cml/sync-var.sml", d16)
  val d17 = layer [o15, o17, pervenv]
  val o20 = run ("/step/sml-109.30/src/cml/src/util/result.sml", d17)
  val d18 = layer [o4, o6, o20, pervenv]
  val o26 = run ("/step/sml-109.30/src/cml/src/Unix/proc-manager.sml", d18)
  val d19 = layer [o26, o4, o6, d6, pervenv]
  val o27 = run ("/step/sml-109.30/src/cml/src/Unix/os-process.sml", d19)
  val d20 = f1 o27
  val d21 = layer [d6, d14, d20, pervenv]
  val o45 = run ("/step/sml-109.30/src/cml/src/Unix/os.sml", d21)
  val f2 = filter [STR "OS", SIG "UNIX", STR "Unix", STR "TextPrimIO", STR "BinPrimIO", SIG "OS_IO", STR "BinIO", STR "RunCML", SIG "OS_PROCESS", STR "TextIO"]
  val d22 = f2 o45
  val o32 = run ("/step/sml-109.30/src/cml/src/IO/prim-io-sig.sml", d15)
  val d23 = layer [o32, o15, pervenv]
  val o36 = run ("/step/sml-109.30/src/cml/src/IO/prim-io-fn.sml", d23)
  val d24 = layer [o36, pervenv]
  val o39 = run ("/step/sml-109.30/src/cml/src/IO/text-prim-io.sml", d24)
  val o34 = run ("/step/sml-109.30/src/cml/src/IO/cml-text-stream-io-sig.sml", d15)
  val d25 = layer [o34, o39, o15, pervenv]
  val o40 = run ("/step/sml-109.30/src/cml/src/IO/cml-text-io-sig.sml", d25)
  val d26 = layer [o32, pervenv]
  val o41 = run ("/step/sml-109.30/src/cml/src/IO/os-prim-io-sig.sml", d26)
  val o18 = run ("/step/sml-109.30/src/cml/src/core-cml/mailbox-sig.sml", d3)
  val d27 = layer [o1, o4, o18, pervenv]
  val o19 = run ("/step/sml-109.30/src/cml/src/core-cml/mailbox.sml", d27)
  val d28 = layer [o32, o15, o17, o19, pervenv]
  val o43 = run ("/step/sml-109.30/src/cml/src/IO/chan-io-fn.sml", d28)
  val d29 = layer [o39, o40, o41, o43, o15, o17, pervenv]
  val o44 = run ("/step/sml-109.30/src/cml/src/IO/text-io-fn.sml", d29)
  val o37 = run ("/step/sml-109.30/src/cml/src/IO/bin-prim-io.sml", d24)
  val d30 = layer [o45, o4, pervenv]
  val o46 = run ("/step/sml-109.30/src/cml/src/Unix/syscall.sml", d30)
  val d31 = layer [o45, o46, o13, o15, o17, o37, o41, pervenv]
  val o47 = run ("/step/sml-109.30/src/cml/src/Unix/posix-bin-prim-io.sml", d31)
  val d32 = layer [o47, o15, o17, o39, o41, pervenv]
  val o49 = run ("/step/sml-109.30/src/cml/src/Unix/posix-text-prim-io.sml", d32)
  val d33 = layer [o49, o44, pervenv]
  val o50 = run ("/step/sml-109.30/src/cml/src/Unix/posix-text-io.sml", d33)
  val d34 = f2 o50
  val d35 = layer [d22, d34, pervenv]
  val o153 = run ("export.sml", d35)
  in val _ = register o153 end

Fix:
 Optimization to lift structure references out of closures restored (it
 had been dropped in 109.24).  Isolate function fixed.  CML version of
 exportFn cleaned up.
Test:
Owner: Zhong, jhr
Status: fixed in 109.31 [jhr, Zhong, 9/15/97]
----------------------------------------------------------------------
Number: 1219
Title: sml crashes while trying to print
Keywords: printing, representations
Submitter: Chris Paris <cap@cs.cmu.edu>
Date: 5/5/97
Version: 109.27
System: sparc/solaris 5.5, mipseb
Severity: major
Problem: 
  Printing datatype values involving ints and words causes segmentation faults.
Transcript:
  Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
  - datatype id = ID of Int32.int;
  datatype id = ID of int32
  - ID (Int32.fromInt 0);
  Segmentation fault

  Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
  - datatype id = ID of int32;
  datatype id = ID of int32
  - ID (0 : int32);
  Segmentation fault

  Standard ML of New Jersey, Version 109.27, April 20, 1997 [CM; autoload enabled]
  - datatype id = ID of Word32.word;
  datatype id = ID of word32
  - ID (Word32.fromInt 0);
  Segmentation fault

Comments:
  
Fix:
Test: bug1219.sml
Owner: Zhong
Status: fixed
----------------------------------------------------------------------
Number: 1220
Title: type definition masks datatype
Keywords: modules, signature matching, datatypes
Submitter: Zhong Shao
Date: 5/7/97
Version: 109.29
System: -
Severity: minor
Problem: 
  Is the following legal sml ? 

    structure A : sig datatype t = HT end = 
      struct datatype t = HT
	     type t = t
      end

  Our compiler complains that 

  z2.sml:1.1-4.6 Error: type t must be a datatype
  z2.sml:1.1-4.6 Error: unmatched type specification: t

  uncaught exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49

  Changing it to the following works as expected: 

    structure A : sig datatype t = HT end = 
      struct datatype t = HT
	     datatype t = datatype t
      end

Code:
Transcript:
Comments:
  Check whether this is legal.
Fix:
Test:
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1221
Title:       type inference of literals is quirky
Keywords:    type inference, literals
Submitter:   Perry Cheng;  pscheng@cs.cmu.edu
Date:        5/9/97
Version:     109.25, 109.29
System:      alpha DEC UNIX 3.2
Severity:    minor
Problem:     The type of word literals seems to fail when they occur
		in top-level bindings inside a structure.
Transcript:

  - let val ten = 0w10 val y = Word32.div(ten,ten) in y end;
  val it = 0wx1 : Word32.word
  - structure X = struct val ten = 0w10 val y = Word32.div(ten,ten) end;
  stdIn:270.21-277.4 Error: operator and operand don't agree (tycon mismatch)
    operator domain: Word32.word * Word32.word
    operand:         word * word
    in expression:
      Word32.div (ten,ten)

Comments:    
  This is not a bug because of the way literal overloading is resolved
  in let expressions vs within structures.  The overloading is resolved
  at each structure element declaration, meaing that the type of ten
  in structure X will default to Word.word, not Word32.word.  In the
  let expression the resolution of the type of ten is not done until
  after the body is typed.
Fix:         
Test: bug1221.sml
Owner: dbm
Status: not a bug
----------------------------------------------------------------------
Number: 1222
Title: ref assignment not performed before overflow
Keywords: 
Submitter:      Lorenz Huelsbergen (lorenz@research.bell-labs.com)
Date:		5/27/97
Version:        109.28
System:         mipseb-irix5 (but not sparc-solaris)
Severity:       major
Problem:        ref assignment not performed before overflow
Code:           
   val x = ref 0;

   fun f n : unit = 
	(x := !x + 1;
         f (n+1));

   f (valOf Int.maxInt);
   x;  (* should be 1 *)

Transcript:

  - : canna.research.bell-labs.com 178; 
  Standard ML of New Jersey, Version 109.28, May 23, 1997 [new runtime]
  -    val x = ref 0;
  val x = ref 0 : int ref
  -    fun f n : unit = 
	  (x := !x + 1;
	   f (n+1));
  = = val f = fn : int -> unit
  - ;
  -    f (valOf Int.maxInt);

  uncaught exception Overflow [overflow]
  -    x;  (* should be 1 *)
  val it = ref 0 : int ref
  - 

Comments:
  Appears to be work properly on sparc.
Fix:
    The problem is caused by the following CPS fragment generated
    by unrolling f a couple of times:

    f772(v785[I],v784[PV]) =
       !(v784) -> v698[PV]			.. 1
       +i31(v698,(I)1) -> v710[I]		.. 2
       unboxedupdate(v784,(I)0,v710)		.. 3
       +i31(v785,(I)1) -> v740[I]		.. 4
       !(v784) -> v758[PV]			.. 5
       +i31(v758,(I)1) -> v759[I]		.. 6
       unboxedupdate(v784,(I)0,v759)		.. 7
       +i31(v740,(I)1) -> v760[I]		.. 8
       (L)f772(v760,v784)			.. 9

    In mips/mipsdepend.sml the use/def information associated with
    trapping add is given by: 

     fun arith_ud(rd,rs,ea) = (exnptr::(reg rs @ arithOpndUse ea), reg rd)

    The problem with this, is that there is no dependence of any kind with
    memory. Thus there is nothing preventing (trapping) instruction 4 from
    being scheduled before 3. [I cannot believe that we haven't tripped
    this bug earlier.] 

    It doesn't matter what kind of dependency is introduced so I think I
    prefer to create a regular data dependency and define arith_ud as:

     fun arith_ud(rd,rs,ea) = 
       (mem::exnptr::(reg rs @ arithOpndUse ea), reg rd)

    This essentially says that the trapping instruction will use memory
    on a trap. A similar consideration should be made with arith3_ud and
    mult_ud. 
							-- Lal

Test:
Owner: 
Status: fixed in 109.31 [Lal, 8/18/97]
----------------------------------------------------------------------
Number: 1223
Title:  Compiler bug: ModuleUtil: strId after unbound structure in functor
Keywords: modules, unbound identifier, secondary error
Submitter: Chris Paris (cap@cs.cmu.edu)
Date: 6/15/97
Version: 109.29
System: -
Severity: minor
Problem: Unbound structure identifier in a functor body leads to 
  "Compiler bug: ModuleUtil: strId".
Code:
  functor A () = struct structure B = B end;
Transcript:
  Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled]
  - functor A () = struct structure B = B end;
  stdIn:17.37 Error: unbound structure: B
  Error: Compiler bug: ModuleUtil: strId
Comments:
Fix:
Test: bug1223.sml
Owner: Zhong
Status: fixed in 109.31 [Zhong, 8/14/97]
----------------------------------------------------------------------
Number: 1224
Title: representation foulup
Keywords: data representation
Submitter: Chris Paris
Date: 6/15/97
Version: 109.28?
System: ?
Severity: major
Problem: 
  Execution gives wrong answers or core dumps.
Code:
  structure T =
  struct
      datatype 'a pref = PREF of {obj : 'a}
      fun apply (PREF {obj}, arg) = obj arg

      fun f ((x, y), z) = y

      fun s () = apply (PREF {obj=f}, (("one", "two"), "three"))
      fun t () = apply (PREF {obj=f}, (("one", "two"), ()))
  end;
  T.s();
  T.t();
Transcript:
  - T.s();
  val it = "three" : string	(* should be "two" *)
  - T.t();
  Bus error			(* tries to print a unit as a string? *)

Comments: [Paris]
  Something interesting happens if I change the definition of f to
  fun f ((x, y), z) = x
  Then we get

  - T.s();
  val it =
    "\238\160\145\224\238\160\145\208\238\1335X\238\^Q\218\244\238\147 0\000\000\^A\219\000\000\000\^A\238\029\231\^H\000\000\000\^E\238\029\231\^P\238\029\231\^X\238\029\231 \000\000\000\^E\238\029\231(\000\000\000\^E\238\029\2310\238\178\250\192\000\000#"
    : string

  And if f is fun f ((x, y), z) = z, then the file doesn't compile:

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

  uncaught exception Lookup
    raised at: cps/nclosure.sml:384.49-384.62
	       util/stats.sml:164.40
	       util/stats.sml:164.40
	       build/evalloop.sml:192.58
	       build/evalloop.sml:284.46-284.49
Fix:
Test: bug1224.sml
Owner: Zhong
Status: fixed in 109.30 [Zhong]
----------------------------------------------------------------------
Number: 1225
Title:       SMLofNJ.Internals.GC.doGC doesn't work
Keywords:  garbage collection, runtime
Submitter:   Christoph Kern <ckern@cs.ubc.ca>
Date:        06/18/97
Version:     Version 109.28, May 23, 1997
System:	     sparc-solaris (probably any)
Severity:    minor
Problem:     SMLofNJ.Internals.GC.doGC x doesn't cause a collection,
	     regardless of the value of x.
Fix:
--- src/runtime/c-libs/smlnj-runtime/gc-ctl.c.orig      Wed Jun 18 14:11:03
1997
+++ src/runtime/c-libs/smlnj-runtime/gc-ctl.c   Wed Jun 18 14:12:51 1997
@@ -86,7 +86,7 @@
 PVT void DoGC (ml_state_t *msp, ml_val_t arg)
 {
     heap_t     *heap = msp->ml_heap;
-    int                level = INT_MLtoC(arg);
+    int                level = INT_MLtoC(DEREF(arg));

     if (level < 0)
        level = 0;
Comment [jhr]
  I think you are right.  What is happening is that the ref cell's
  address is a negative number on the sparc, but is a (large) positive
  number on the SGI.  When you call doGC, it only does a minor collection,
  whereas, when I call it, it always collects all generations.  I've applied
  your patch, and it will be in 109.30.  Thanks.

Test: *
Owner: jhr
Status: fixed in 109.30
----------------------------------------------------------------------
Number: 1226
Title:       Ctrl-C no longer works on Alpha
Keywords:    signals, interrupt
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        6/17/97
Version:     109.29
System:      Alpha
Severity:    critical
Problem:     Ctrl-C does not interrupt compilation or execution
Comments:    
 [George Russell <george@persimmon.co.uk>, 6/23/97]
  This is more about a problem reported by Andrew Kennedy, that SML109.29
  on Digital Unix 4 does not respond to <Ctrl>/C.  I can now report that
  it also does not respond to 

  kill -2 [process id]
  (IE sending SIGINT to it).  However SML109.29 on Digital Unix 3.2,
  and SML109.28 on Digital Unix 4, both do respond to kill -2.

 [jhr, 6/23/97]
  We have not been able to reproduce these problems on our Unix 4.0
  Alpha, so we will need your help in tracking this down.
  Please try the following experiment:

    cd src/runtime/objs
    make -f mk.alpha32-dunix BASE_DEFS="-DSIGNAL_DEBUG"
    run.alpha32-dunix @SMLload=../../../bin/.heap/sml
    (* and then try your ^C at the SML prompt *)

  Another thing to try (you might do this first) is typing

    Signals.inqHandler Signals.sigINT;

  at the prompt.  This should return

    val it = HANDLER fn : sig_action

  Let me know what you find out.

 [jhr, 6/23/97]
  In message <33AE614D.41C6@persimmon.co.uk>, George Russell writes:
  >
  > Test #1 - Ctrl/C does nothing.  I'll keep this SML session going in
  > case there's anything else you want me to try.
  > 
  > Test #2 yields 
  > val it = IGNORE : sig_action
  > !!
  > But for 109.28 and 109.29 on 3.2 it does what you say it should do.

  Then the explanation is quite simple.  When SML starts up, it checks
  the status of signals that it inherits from its parent process; if
  the status is SIGING, then it doesn't install a handler.  This behavior
  is necessary to get sml to work properly as a background process (or
  under nohup).  Why you see different behavior between 109.28 and
  109.29, I have no idea, but I think that the problem is in your
  shell environment.

 [jhr, 7/14/97]
  not a bug --- sml was built in a non interactive shell.

Owner: jhr, Lal
Status: not a bug
----------------------------------------------------------------------
Number: 1227
Title:       Unaligned access generated from floating-point arrays
Keywords:    arrays, reals
Submitter:   Perry Cheng  (pscheng@cs.cmu.edu)
Date:        6/26/97
Version:     109.28
System:      Alpha OSF/1 3.2
Severity:    major
Problem:     Floating point array manipulations cause unaligned accesses.
Code:        The following program computes FFTs at sizes 16, 32, ..., 65536.
	     The code comes from a CAML-Lite distribution.

local
val sin = Real.Math.sin
val cos = Real.Math.cos
open Array
fun abs_real(x:real) = if x < 0.0 then ~x else x
fun print_real (x:real) = print(Real.toString x)

(* $Id$ *)

val pi = 3.14159265358979323846

val tpi = 2.0 * pi

fun for(start,stop,f) = 
    let fun loop i = if i > stop then () else (f i; loop (i+1))
    in
	loop start
    end

val print_string : string -> unit = print
val print_int : int -> unit = print_string o Int.toString
val print_newline : unit -> unit = fn _ => print_string "\n"

fun dump pxr pxi = 
  for(0,15,fn i => 
      (print_int i; 
       print " ";
       print_real (sub(pxr,i+1)); 
       print " "; 
       print_real (sub(pxi,i+1));
       print_newline()))


fun fft px py np =
let val i = ref 2 
    val m = ref 1 
  
    val _ = 
	while (!i < np) do
	    (i := !i + !i; 
	     m := !m + 1)
    val n = !i 
in  
  if n <> np then (
    for (np+1,n,fn i=>
      (update(px,i,0.0); 
       update(py,i,0.0)));
    print_string "Use "; print_int n;
    print_string " point fft"; print_newline()
  ) else ();

  let val n2 = ref(n+n) 
  in
    for(1,!m-1,fn k =>
    let val _ = n2 := !n2 div 2
	val n4 = !n2 div 4 
	val e  = tpi / (real (!n2 ))
    in
      for(1,n4,fn j =>
      let val a = e * real(j - 1) 
	  val a3 = 3.0 * a 
	  val cc1 = cos(a) 
	  val ss1 = sin(a) 
	  val cc3 = cos(a3)
	  val ss3 = sin(a3)
	  val is = ref j 
	  val id = ref(2 * !n2) 
      in
        while !is < n do
          let val i0r = ref (!is)
	  in
	      while !i0r < n do
		  let val i0 = !i0r 
		      val i1 = i0 + n4 
		      val i2 = i1 + n4 
		      val i3 = i2 + n4 
		      val r1 = sub(px,i0) - sub(px,i2) 
		      val _ = update(px,i0,sub(px,i0) + sub(px,i2))
		      val r2 = sub(px,i1) - sub(px,i3) 
		      val _ = update(px,i1,sub(px,i1) + sub(px,i3))
		      val s1 = sub(py,i0) - sub(py,i2) 
		      val _ = update(py,i0,sub(py,i0) + sub(py,i2))
		      val s2 = sub(py,i1) - sub(py,i3) 
		      val _ = update(py,i1,sub(py,i1) + sub(py,i3))
		      val s3 = r1 - s2 
		      val r1 = r1 + s2 
		      val s2 = r2 - s1 
		      val r2 = r2 + s1 
		  in
		      update(px,i2,r1*cc1 - s2*ss1);
		      update(py,i2,~s2*cc1 - r1*ss1);
		      update(px,i3,s3*cc3 + r2*ss3);
		      update(py,i3,r2*cc3 - s3*ss3);
		      i0r := i0 + !id
		  end;
	     is := 2 * !id - !n2 + j; 
	     id := 4 * !id
	     (* ; dump px py *)
	  end
      end)
    end)
  end;

(************************************)
(*  Last stage, length=2 butterfly  *)
(************************************)

  let val is = ref 1 
      val id = ref 4 
  in
      while !is < n do
	  let val i0r = ref (!is)
	  in
	      while !i0r <= n do
		  let val i0 = !i0r 
		      val i1 = i0 + 1 
		      val r1 = sub(px,i0) 
		      val _ = update(px,i0,r1 + sub(px,i1))
		      val _ = update(px,i1,r1 - sub(px,i1))
		      val r1 = sub(py,i0) 
		  in
		      update(py,i0,r1 + sub(py,i1));
		      update(py,i1,r1 - sub(py,i1));
		      i0r := i0 + !id
		  end;
	      is := 2 * !id - 1; 
	      id := 4 * !id
	  end
  end;
(*
  print "\nbutterfly\n";
  dump px py;
*)
(*************************)
(*  Bit reverse counter  *)
(*************************)

  let val j = ref 1 
  in
    for (1,n-1,fn i =>
    (if i < !j then (
      let val xt1 = sub(px,!j) 
	  val xt2 = sub(px,i)
	  val _ = update(px,!j,xt2)
	  val _ = update(px,i,xt1)
	  val yt1 = sub(py,!j) 
	  val yt2 = sub(py,i)
      in
	  update(py,!j,yt2);
	  update(py,i,yt1)
      end)
     else ();
     let val k = ref(n div 2) 
     in
        while !k < !j do (j := !j - !k; k := !k div 2);
        j := !j + !k
     end));
(*
     print "\nbit reverse\n";
     dump px py;
*)
     n
  end
end;

fun test np =
  (print_int np; print_string "... "; 
  let val enp = real np 
      val npm = np div 2 - 1
      val pxr = array ((np+2), 0.0)
      val pxi = array ((np+2), 0.0)
      val t = pi / enp
      val _ = update(pxr,1,(enp - 1.0) * 0.5)
      val _ = update(pxi,1,0.0)
      val n2 = np div 2 
      val _ = update(pxr,n2+1,~0.5)
      val _ = update(pxi,n2+1,0.0)
  in
      for (1,npm,fn i =>
      let val j = np - i 
	  val _ = update(pxr,i+1,~0.5)
	  val _ = update(pxr,j+1,~0.5)
	  val z = t * (real i)
	  val y = ~0.5 * (cos(z)/sin(z)) 
      in
	   update(pxi,i+1,y);
	   update(pxi,j+1,~y)
      end);
(*
  print "\n"; print "before fft: \n";
  dump pxr pxi;
*)
  fft pxr pxi np;
(*
  print "\n"; print "after fft: \n";
  dump pxr pxi;
*)
  let val zr = ref 0.0 
      val zi = ref 0.0 
      val kr = ref 0 
      val ki = ref 0 
  in
      for (0,np-1,fn i =>
      let val a = abs_real(sub(pxr,i+1) - (real i))
      in
	   if !zr < a then 
	       (zr := a; 
		kr := i)
	   else ();
	   let val a = abs_real(sub(pxi,i+1))
	   in
	       if !zi < a then 
		   (zi := a; 
		    ki := i)
	       else ()
	   end
      end);
      let val zm = if abs_real (!zr) < abs_real (!zi) then !zi else !zr 
      in
	  print_real zm; print_newline()
      end
  end
 end)

fun doit() = 
  let val np = ref 16 
  in for(1,13,fn i => (test (!np); np := (!np)*2))
  end

in
val _ = doit()
end

Transcript:  

Standard ML of New Jersey, Version 109.28, May 23, 1997 [CM&CMB]
val it = () : unit
- use "/afs/cs/user/pscheng/bug.sml";
[opening /afs/cs/user/pscheng/bug.sml]
GC #0.0.0.0.1.6:   (10 ms)
GC #0.0.0.0.2.24:   (14 ms)
GC #0.0.0.1.3.40:   (23 ms)
GC #0.0.0.1.4.51:   (16 ms)
GC #0.0.1.2.5.60:   (55 ms)
GC #0.0.1.3.6.96:   (12 ms)
GC #0.0.1.3.7.120:   (23 ms)
16... 8.881784197e~16
32... 3.5527136788e~15
64... 1.06581410364e~14
128... 2.84217094304e~14
256... 5.68434188608e~14
512... 1.16795462191e~13
1024... GC #0.0.1.4.8.130:   (1 ms)
Unaligned access pid=1001 <run.alpha32x-osf> va=31c205c pc=2b439f4 ra=2b43994 
type=stt
Unaligned access pid=1001 <run.alpha32x-osf> va=31c2064 pc=2b43a28 
ra=ffffffffffffffff type=stt
Unaligned access pid=1001 <run.alpha32x-osf> va=31c206c pc=2b439f4 
ra=ffffffffffffffff type=stt
Unaligned access pid=1001 <run.alpha32x-osf> va=31c2074 pc=2b43a28 
ra=ffffffffffffffff type=stt
Unaligned access pid=1001 <run.alpha32x-osf> va=31c207c pc=2b439f4 
ra=ffffffffffffffff type=stt
Unaligned access pid=1001 <run.alpha32x-osf> va=31c2084 pc=2b43a28 
ra=ffffffffffffffff type=stt
Unaligned access pid=1001 <run.alpha32x-osf> va=31c208c pc=2b439f4 
ra=ffffffffffffffff type=stt

Comments:    This works correctly in 109.25.
 [Zhong, 6/26/97]
  This seems to be an Alpha-specific bug, as the above code work
  fine on my SPARC. Do we align all floating-point numbers on Alpha ?
 [jhr, 6/26/97]
  I suspect that it must be a bug in the code generator.  The run-time
  system and garbage collector aligns all real and real array objects
  on 64-bit boundries on all machines.

  BTW, I hope this code is not being used for benchmarking.  It uses
  int refs to do iteration, instead of the more natural (and more
  efficient) tail recursive form.

 [Lal, 6/29/97]
  The bug is in the runtime system, in the routine 
	  runtime/gc/ml-object.c:ML_AllocRealdarray.

  If garbage collection is invoked there is no guarantee that the 
  next word in the STRING arena is properly aligned.

  ------
  ml_val_t ML_AllocRealdarray (ml_state_t *msp, int len)
  {
      int		nwords = DOUBLES_TO_WORDS(len);
      if (nwords > SMALL_OBJ_SZW) {
	  arena_t	*ap = msp->ml_heap->gen[0]->arena[STRING_INDX];
	  BEGIN_CRITICAL_SECT(MP_GCGenLock)
  #ifdef ALIGN_REALDS
	    /* Force REALD_SZB alignment (descriptor is off by one word) */
	      ap->nextw = (ml_val_t *)((Addr_t)(ap->nextw) | WORD_SZB);
  #endif
	      IFGC (ap, (WORD_SZB*(nwords + 1))+msp->ml_heap->allocSzB) {
		/* we need to do a GC */
		  ap->reqSizeB += WORD_SZB*(nwords + 1);
		  RELEASE_LOCK(MP_GCGenLock);
		      InvokeGC (msp, 1);
		  ACQUIRE_LOCK(MP_GCGenLock);
	      }
	      *(ap->nextw++) = desc;		<<<<<< not aligned.
	      res = PTR_CtoML(ap->nextw);
	      ap->nextw += nwords;

  ----

  A crude fix to get you going is to replicate the 
	  #ifdef ALIGN_REALDS ... #endif

  just before the line containing:

      *(ap->nextw++) = desc;		<<<<<< not aligned.

  p.s. This bug manifested on the HPPA, and this fix solved the
  problem. I have not tested this on the alpha, so please let me know if
  it works on the alpha as well. Thanks.
Fix:         
Test: 
Owner: Lal, jhr
Status: fixed in 109.30
----------------------------------------------------------------------
Number: 1228
Title:  various Real functions on Alpha
Keywords: Floating point, Real
Submitter:  Andrew.Kennedy@persimmon.co.uk, George Russell <george@persimmon.co.uk>
Date:        7/7/97
Version:     109.29
System:      Alpha, OSF 4.0
Severity:    Minor
Problem:
 1. Real.ceil and Real.floor cause segmentation fault on reals
    whose integer equivalent is out of range
 2. Real.signBit (~0.0);
    returns false on both Alpha/OSF 4.0 and Linux/i386.
 3. Real.fromManExp{exp=0,man=1.5};
    causes SML/NJ 109.29 to hang forever (well, 8 GCs so far and counting)
    on Alpha/Digital Unix 4 and i686/Linux
 4. Real.toManExp(1.0);
    returns
    {exp=0,man=1.0}
    for both Alpha/Digital Unix 4.0 and Linux/i686.  However by my version
    of the standard this is wrong because we should have
    0.5<=man<1.0.  The correct answer is {exp=1,man=0.5}.  The local
    version of frexp gets this right, incidentally.
 5. Real.isNormal 0.0
    ought to return false.

Code:        Real.floor  1073741824.0
Transcript:  
Comments:
 [Kennedy]  NB Real.ceil 1073741823.1 correctly raises Overflow
 [jhr, 7/7/97]
  > Real.signBit (~0.0);
  > returns false on both Alpha/OSF 4.0 and Linux/i386.

  Actually, this is a feature of the IEEE 754-1985 specification.
  The negation of zero is negative zero, only when the rounding
  mode is set to TO_NEGINF.

  I don't know if the SML specification says anything about how
  the literal ~0.0 should be interpreted (is it the same as
  Real.~(0.0) in default rounding mode)?
 [appel, 9/17/97]
  No, this is not true.  The IEEE specification calls for the
   negation of 0.0 to be ~0.0 regardless of rounding mode.

 [jhr, 7/7/97]
  I've tried the various FP bugs on canna, and here is some more info:

  1) The Real.floor and Real.ceil of 1073741824.0 work correctly.  This
     is probably a bug in the assembly code for floor.

  2) Real.signBit(~0.0) returns false, but Real.signBit(0.0/ ~1.0) returns
     true.  This is probably not a bug, but a feature of the IEEE specification.

  3) Real.fromManExp{exp=0,man=1.5} goes to lunch on the MIPS too.  I suspect
     this is a bug in the Real.fromManExp function (written by Andrew, I think).

Fix: [for which part?]
 [Lal, 7/7/97]
  Thanks for the bug report. In the file 
	  src/runtime/mach-dep/ALPHA32-prim.asm

  there are two labels called floor_overflow that require a trapb
  instruction at the end. The first floor_overflow label should look
  like: 

  floor_overflow:
	  ldl	ATMP1, ovfl_MAXINT
	  addlv	ATMP1, ATMP1, ATMP1
	  trapb

  and the second should look like:

  floor_overflow:
	  addq	$30, 16, $30
	  ldl	ATMP1, ovfl_MAXINT
	  addlv	ATMP1, ATMP1, ATMP1
	  trapb

  The stack deallocation must be added to the second label as well.

  Making this change and recompiling the runtime system fixes this
  problem.
Test: *
Owner: jhr, Lal
Status: fixed in 109.31 [Lal, Andrew]
----------------------------------------------------------------------
Number: 1229
Title:       Bugs in unionWith, unionWithi of smlnj-lib
Keywords:    smlnj-lib, binary-set-map
Submitter:   Yasuhiko Minamide, nan@kurims.kyoto-u.ac.jp
Date:        7/11/1997
Version:     109.29
System:	     any
Severity:    minor
Problem:     

The behaviour of unionWith and unionWithi of smlnj-lib seems wrong.

Code:	     

let open IntBinaryMap
    val x = insert (insert (empty, 1,1),  2, 2)
    val y = insert (empty, 1, 0)
    val z = unionWith (fn (x,y) => x) (x, y)
in
    listItemsi z
end

Transcript:  

The code above returns

val it = [(1,0),(2,2)] : (int * int) list

I think that this should be

val it = [(1,1),(2,2)] : (int * int) list

Test: *
Owner: jhr
Status: fixed in 109.30 [jhr, 7/14/97]
----------------------------------------------------------------------
Number: 1230
Title: bus-error due to representation problem
Keywords: bus-error
Submitter: manuel@cs.berkeley.edu
Date: July 12
Version: 109.26 and 109.29
System: Solaris Ultrasparc and Linux i686
Severity: severe
Problem: Small test program crashes sml process
Code:
signature CONS =
    sig
	type 'a sign
	type 'a constructor

	val new   : {name   : string,
		     signa  : 'a sign} -> 'a constructor
		    
    end

structure Cons : CONS =
    struct

	    datatype sort =
		SUB		
	      | CSUB     	

	    datatype datacon = DCON of {name    : string,
					arity   : int,
					sign    : sort list,
					sort    : sort,
					strict  : bool}

	    type 'a constructor = datacon
	    type 'a sign = {sign : sort list, sort : sort, strict : bool}

	    fun new {name,signa={sign,sort,strict}} =
		DCON {name=name,
		      arity=List.length sign,
		      sign=sign,
		      sort=sort,
		      strict=strict
		      }

    end

Transcript:
[Solaris,UltraSparc]
Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
- [opening /tmp/mla002oZ]
signature CONS =
  sig
    type 'a sign
    type 'a constructor
    val new : {name:string, signa:'a sign} -> 'a constructor
  end
structure Cons :
  CONS?
val it = () : unit
- Cons.new;

Process sml bus error

[Linux i686]
Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
use "/tmp/mla32088";^M
- [opening /tmp/mla32088]
signature CONS =
  sig
    type 'a sign
    type 'a constructor
    val new : {name:string, signa:'a sign} -> 'a constructor
  end
structure Cons :
  CONS?
val it = () : unit
- Cons.new;
/disks/orodruin/aa/home/manuel/Projects/sml-109.26/bin/.run/run.x86-linux:
Fatal error --\
 unexpected fault, signal = 11, code = 0x4081346b

Process sml exited abnormally with code 1

Comments:
I tried to make the example as short as possible. It seems important
that the datatype DCON have at least 5 fields in the record, and that
new takes 2 arguments.

Fix:
Test: bug1230.sml
Owner: Zhong
Status: fixed in 109.30 [Zhong]
----------------------------------------------------------------------
Number: 1231
Title: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
Keywords: secondary error, error recovery
Submitter: manuel@cs.berkeley.edu
Date: July 12
Version: 109.29
System: Solaris Ultrasparc
Severity: severe
Problem: Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo
Code:
signature CONS =
    sig
	type 'a sign
	type 'a constructor

	val new   : {name   : string,
		     signa  : 'a sign} -> 'a constructor
		    
    end

structure Cons : CONS =
    struct

	    datatype sort =
		SUB		
	      | CSUB     	

	    datatype datacon = DCON of {name    : string,
					arity   : int,
					sign    : sort list,
					sort    : sort,
					strict  : bool}

	    type 'a constructor = datacon
	    datatype 'a sign = Sign of {sign : sort list, sort : sort, strict : bool}

	    fun new {name,signa=Sign{sign,sort,strict}} =
		DCON {name=name,
		      arity=List.length sign,
		      sign=sign,
		      sort=sort,
		      strict=strict
		      }

    end

signature B =
    sig
	structure Cons : Cons
    end

structure B :> B =
    struct
	structure Cons = Cons
    end

Transcript:
Standard ML of New Jersey, Version 109.29, June 13, 1997 [CM; autoload enabled]
- [opening /tmp/mla002oZ]
/tmp/mla002oZ:39.2-40.5 Error: unbound signature: Cons
Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo

uncaught exception Error
  raised at: util/errormsg.sml:51.14-51.19
             modules/sigmatch.sml:807.24
             elaborate/elabmod.sml:1039.8
             util/stats.sml:164.40
             build/evalloop.sml:120.38
             build/evalloop.sml:192.58
             build/evalloop.sml:284.46-284.49
- 
Comments:
Fix:
Test: bug1231.sml
Owner: Zhong
Status: fixed in 109.30
----------------------------------------------------------------------
Number: 1232
Title: consistent definitional specs seen as inconsistent
Keywords: modules, signatures, definitional specs, where definitions
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 6/19/97
Version: 109.29
System: -
Severity: major 
Problem: 
  Definitional specs are rejected as inconsistent when they are not.
Code:
  signature SIG1 =
  sig
    type t = int
  end

  signature SIG2 =
  sig
    structure N : SIG1
  end

  functor Bad(structure X : SIG1
	      structure Y : SIG2 where N = X) =
  struct end;

Transcript:
  - use "foo.sml";
  [opening foo.sml]
  foo.sml:11.9-13.11 Error: Inconsistent defining constraints : type t = t

  uncaught exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:193.58
	       build/evalloop.sml:285.46-285.49

Comments:
  Confusing error message too.
Fix:
  Remove consistency checking for multiple definitions in
  Instantiate.builtTycClass.constrain when one or both definitions 
  are not instantiated (NOTINST tyc).
Test: bug1232.sml
Owner: dbm
Status: fixed in 109.30 [dbm, 7/16/97]
----------------------------------------------------------------------
Number: 1233
Title: funny printing of multiple bindings in a declaration
Keywords: printing, duplicate binding
Submitter: Walid Taha
Date: 7/16/97
Version: 109.29
System: -
Severity: minor 
Problem: 
  The top level prints an odd message when a value variable is bound twice
  in a declaration.
Transcript:
  - val c = 1 val c = 2;
  val c = <hidden-value> : int
  val c = 2 : int
Comments:
  It would be preferable to just print

    val c = 2 : int

  as the result of the declaration.
Fix:
Test: bug1233.sml
Owner: Zhong?
Status: open
----------------------------------------------------------------------
Number: 1234
Title: EntityEnv.Unbound raised in functor application
Keywords: modules, translation, hidden types
Submitter: Dave MacQueen
Date: 7/21/97
Version: 109.30 (+ bug 1206 fix)
System: -
Severity: major 
Problem: 
  EntityEnv.Unbound exception raised in function specLty when compiling
  legal functor application.
Code:
  functor F(type t val x : t) =
  struct 
    structure U : sig type u val y : u end = 
      struct
	datatype u = K of t 
	type u = u list
	val y = [K x]
      end
    val z = hd U.y
  end;

  structure A = T(type t = int val x = 3);
Transcript:
  - use "bug1234.sml";
  [opening bug1234.sml]
  functor F : <sig>

  uncaught exception Unbound
    raised at: translate/transmodules.sml:79.33-79.43
	       util/stats.sml:164.40
	       build/evalloop.sml:193.58
	       build/evalloop.sml:285.46-285.49
Comments:
 [dbm]
  This is after incorporating the fix for bug 1206.
  If the signature on U is removed, the code works.

  Looking at the functor representation and the bad entityEnv with
  debugging on, it looks like signature matching is introducing an extra
  level of structure nesting.  The path to the hidden datatype u should
  be of length 2, but in the entityEnv, the datatype is nested inside an
  extra intermediate structure, so the length two path doesn't reach it.
  I presume that sigmatch is creating the extra intermediate structure
  level.

Fix:
Test: bug1234.sml
Owner: dbm, Zhong
Status: Fixed in 109.31 [Zhong]
----------------------------------------------------------------------
Number: 1235
Title: Argument type constraint changes behavior of a function
Keywords:    types
Submitter:   Sam Kamin, s-kamin@uiuc.edu
Date:        7/21/97
Version:     Version 109.29, June 13, 1997 [CM&CMB]
System:      sparc-solaris, don't know what version offhand
Severity:    major
Problem:     Function defined as fun f x = ... type-checks, but then
             crashes.  When defined as fun f (x:T) = ..., it works
             fine.
Code:        I'm not going to send enough to reproduce the error,
             because it's too much.  If this turns out to be an
             interesting problem, I can send it.  Anyway, the specific
             problem is demonstrated in this function:

             fun mkseqlist seqop [] = empty
           | mkseqlist seqop [p:Picture] = p
           | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);

             If the ":Picture" in the second clause is omitted, the
             function type-checks but crashes when used.

Transcript:  In this transcript, "seq" is an infix operator.  As I said,
             I haven't come up with a simpler example, and I don't
             think you want all the code (especially not if this turns
             out to be something simple).

- fun mkseqlist seqop [] = empty
  | mkseqlist seqop [p] = p
  | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
= = val mkseqlist = fn
  : ((('a -> string) * Environment) * (('a -> string) * Environment)
     -> ('a -> string) * Environment)
    -> (('a -> string) * Environment) list -> ('a -> string) *
Environment
- val seqlist = mkseqlist (op seq);
val seqlist = fn
  : ((GraphicsContext -> string) * Environment) list
    -> (GraphicsContext -> string) * Environment
- draw (seqlist [text "a"]) "test";
~2.34725596609e228, ~2.34705354077e228
uncaught exception Overflow [overflow]
- fun mkseqlist seqop [] = empty
  | mkseqlist seqop [p:Picture] = p
  | mkseqlist seqop (p::ps) = seqop (p, mkseqlist seqop ps);
= = val mkseqlist = fn
  : (Picture * ((GraphicsContext -> string) * Environment)
     -> (GraphicsContext -> string) * Environment)
    -> Picture list -> (GraphicsContext -> string) * Environment
-  val seqlist = mkseqlist (op seq);
val seqlist = fn : Picture list -> (GraphicsContext -> string) *
Environment
- draw (seqlist [text "a"]) "test";
1.0, 0.0(1.0, 1.0)(0.0, 0.0)val it = () : unit
- 

Comments:    I'm not sure if this is really a bug, but it seems to me
             that adding type declarations is not supposed to matter.
             And it's a heck of a difficult error to track down.
Fix:
Test: ?
Owner: Zhong
Status: fixed in 109.30
----------------------------------------------------------------------
Number: 1236
Title: TextIO.outputSubstr doesn't work on substrings containing \n
Keywords: IO, TextIO, outputSubstr
Submitter: Konrad.Slind@cl.cam.ac.uk
Date: 7/23/97
Version: 109.30
System: sparc/solaris 2.5.5
Severity: major
Problem: 
  TextIO.outputSubstr doesn't seem to handle substrings with "\n" in
  them. For example:

     - TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n"));
     val it = () : unit

  This behaviour contradicts the description in the basis documentation.

Code:
  TextIO.outputSubstr(TextIO.stdOut, Substring.all("hello\n"));
Comments:
Fix:
Test: bug1236.sml
Owner: jhr, erg
Status: fixed in 109.32 [jhr, 7/24/97]
----------------------------------------------------------------------
Number: 1237
Title: ml-yacc doesn't handle constructors with long names
Keywords: ml-yacc, constructor names
Submitter: Konrad.Slind@cl.cam.ac.uk
Date: 7/23/97 
Version: 109.30
System: -
Severity: major 
Problem: 
  ml-yacc emits bogus string literals from constructors with long
  names. The following input will generate a file where, on about line
  104, a mangled string literal is produced.
Code:
  %%
  %term I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild
      | EOLEX
      | EOF 

  %nonterm START of unit

  %start START
  %eop EOF EOLEX
  %pos int
  %header (functor ELrValsFun (structure Token : TOKEN))
  %name E
  %noshift EOF
  %pure
  %%

  START : I_am_a_great_long_lexeme_comma_of_a_sort_not_normally_found_in_the_wild()
Transcript:
Comments:
Fix:
Test:
Owner: appel
Status: fixed in 109.32
----------------------------------------------------------------------
Number: 1238
Title:       Elaboration error involving where structure
Keywords:    where structure
Submitter:   Perry Cheng (pscheng@cs.cmu.edu)
Date:        7/23/97
Version:     109.30
System:      Digital Unix 4.0
Severity:    major
Problem:     Where structure construct causes strange error message.
Code:        
signature MA =
sig
  type t
end;

signature MU =
sig
  structure M  : MA 
end;

signature DA =
sig
  type t
end;

(* ------------ this one works ---------------------- *)
functor Good(structure D : DA
	     structure Mu : MU 
		  where type  M.t = D.t) 
    = struct end;

(* ------------ this one fails ---------------------- *)
functor Bad(structure D : DA
	    structure Mu : MU where M = D) 
    = struct end;

Transcript:
- use "bug1238.sml";
[opening bug1238.sml]
signature MA =
  sig type t end
signature MU =
  sig structure M : sig type t end end
signature DA =
  sig type t end
functor Good : <sig>

uncaught exception Unbound
  raised at: elaborate/elabmod.sml:1164.39-1164.49
             util/stats.sml:164.40
             build/evalloop.sml:120.38
             build/evalloop.sml:193.58
             build/evalloop.sml:285.46-285.49

Comments:
  Minor modification to the code will make the bug go away.
  This bug is related to bug 1232.
  On a related note, sometime a functor definition that involves 
  "where structure" generates a functor which, when instantiated,
  gives the same error message even though the code is correct.

 [dbm, 7/23/97]
  If DA is replaced by MA in Bad, the code compiles ok.  So the problem
  is caused by the difference in signatures (DA vs MA).
Fix:
 Modified entityInfo datatype in Instantiate so that GENERATE_ENT
 carries a boolean value indicating whether there was a VARstrDef
 with signature that does not agree with the spec.
Test: bug1238.sml
Owner: dbm
Status: fixed in 109.31 [dbm, 8/13/97]
----------------------------------------------------------------------
Number: 1239
Title:       Subscript-out-of-bounds error when opening a structure
Keywords:    pretty printing, compiler
Submitter:   Jon Riecke, riecke@bell-labs.com
Date:        07/25/97
Version:     109.30
System:      Linux and Irix
Severity:    major
Problem:     
When opening the CML structure, a "subscript out of bounds" exn is raised.
Code:        CML standard library
Transcript:  
- open CML;
GC #0.0.0.1.3.57:   (43 ms)
open CML
val version = {date="June 11, 1997",system="Concurrent ML",version_id=[1,0,7]}
  : {date:string, system:string, version_id:int list}
val banner = "Concurrent ML, Version 1.0.7, June 11, 1997" : string
val getTid = fn : unit -> thread_id
val sameTid = fn : thread_id * thread_id -> bool
val compareTid = fn : thread_id * thread_id -> order
val hashTid = fn : thread_id -> word
val tidToString = fn : thread_id -> string
val spawnc = fn : ('a -> unit) -> 'a -> thread_id
val spawn = fn : (unit -> unit) -> thread_id
val exit = fn : unit -> 'a
val joinEvt = fn : thread_id -> unit event
val yield = fn : unit -> unit
val channel = fn : unit -> 'a chan
val sameChannel = fn : 'a chan * 'a chan -> bool
val send = fn : 'a chan * 'a -> unit
val recv = fn : 'a chan -> 'a
val sendEvt = fn : 'a chan * 'a -> unit event
val recvEvt = fn : 'a chan -> 'a event
val sendPoll = fn : 'a chan * 'a -> bool
val recvPoll = fn : 'a chan -> 'a option

uncaught exception in compiler: subscript out of bounds
  raised at: print/ppobj.sml:89.24-89.29
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             util/pp.sml:545.6
             build/evalloop.sml:193.58

Comments:    
 [jhr, 7/30/97]
  Appears to be the same as bug 1241, which is fixed in 109.31.
Fix:         
Test: *
Owner: Zhong
Status: fixed in 109.31 [Zhong, 7/29/97]
----------------------------------------------------------------------
Number: 1240
Title:       Can't form pairs of reals
Keywords:    reals
Submitter:   Sam Kamin, kamin@cs.uiuc.edu
Date:        7/25/97
Version:     109.30
System:      sparc-solaris
Severity:    Critical
Problem:     Attempt to create tuples containing only real numbers
             results in "uncaught exception in compiler: Representation"
Code:        (0.0,0.0)
Transcript:  Here are a couple of more examples:

- (0.0, 0.0);
 
uncaught exception in compiler: Representation
  raised at: boot/Unsafe/object.sml:58.19-58.33
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             util/pp.sml:545.6
             build/evalloop.sml:193.58
- (real 0, real 0);
 
uncaught exception in compiler: Representation
  raised at: boot/Unsafe/object.sml:58.19-58.33
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             util/pp.sml:545.6
             build/evalloop.sml:193.58
- ((fn x => (x,x)) 0.0);
 
uncaught exception in compiler: Representation
  raised at: boot/Unsafe/object.sml:58.19-58.33
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             util/pp.sml:545.6
             build/evalloop.sml:193.58

- (0.0, 0);
val it = (0.0,0) : real * int
- (0.0, "abc");
val it = (0.0,"abc") : real * string


Comments:    
Fix:      
Test: bug1240.sml
Owner: jhr, Zhong
Status: fixed in 109.31 [jhr, 7/28/97]
----------------------------------------------------------------------
Number: 1241
Title:       confused datatype constructors
Keywords:    datatype
Submitter:   Elsa L. Gunter, elsa@research.bell-labs.com
Date:        July 25, 1997
Version:     109.30
System:      x86 - linux 2.0
Severity:    critical
Problem:     In a datatype with two constructors, the constructors get
             swapped
Code:

datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1;

datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0;

norfolk% sml
Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- datatype 'a t1 = A1 | B1 of ('a list) val i1 = A1;
datatype 'a t1 = A1 | B1 of 'a list
val i1 = B1 [] : 'a t1
- datatype 'a t2 = A2 of int | B2 of ('a list) val i2 = A2 0;
datatype 'a t2 = A2 of int | B2 of 'a list

uncaught exception in compiler: subscript out of bounds
  raised at: print/ppobj.sml:89.24-89.29
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             util/pp.sml:545.6
             build/evalloop.sml:193.58
- 
Comments: Notice that in the first datatype declaration, I assign, i1
to be A1, but it gives me back that it is B1 [].  In the second case,
it raises an exception (I think because it is trying to apply B2 [] to
0.).

Fix: change to ppobj.sml
Test: bug1241.sml
Owner: Zhong
Status: fixed in 109.31 [Zhong]
----------------------------------------------------------------------
Number: 1242
Title: error recovery in open could be better
Keywords: open error recovery
Submitter: manuel@cs.berkeley.edu
Date: July 29/97
Version: 109.29
System: all
Severity: low
Problem: If one structure is undefined in an open declarations with
multiple structures, the non-constant constructors made visible from
opening preceding structures are not bound. Results in weird spurious
error messages.

Code:
  structure A =
      struct
	  datatype at = A | B | C of int
      end

  local
      open A Foo
  in
      fun toString A = "A"
	| toString B = "B"
	| toString (C i) = "C " ^ Int.toString i
  end

Transcript:
- [opening /tmp/mla003Cy]
/tmp/mla003Cy:7.5-7.15 Error: unbound structure: Foo
/tmp/mla003Cy:9.9-11.47 Error: non-constructor applied to argument in pattern: C

uncaught exception Error
  raised at: build/evalloop.sml:103.44-103.52
             build/evalloop.sml:120.38
             build/evalloop.sml:192.58
             build/evalloop.sml:284.46-284.49
- 

Comments:
	The C constructor isn't visible, even though A and B
	are. Removing the Foo structure from the open declaration
	makes the second error disappear.
 [dbm, 7/29/97]
  The reason there is no error message complaining about A and B
  in the first two clauses of toString is that since these are not
  bound as constructors they are interpreted as variables.

  It should be possible to have the open take effect on the structures
  that are defined, which would cut down on secondary errors like
  this one.
 [manuel, 7/29/97]
  Yes, you are right about the constant constructors. I didn't think of
  that. But what is strange is that only constructors seem to be missing
  from the environment. Value bindings are visible in the same context.
Fix:
Test: bug1242.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1243
Title:       Application of functor to different representations
Keywords:    functor application, polymorphism, representation analysis
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        7/28/97
Version:     109.30
System:	     x86-linux
Severity:    major
Problem:     compiler bug tickled by application of functor 
             to two different polymorphic representations
Code:	     

local
   functor Foo(type 'a t
	       val destruct : 'a t -> ('a * 'a t) option) =
      struct
	 fun first s =
	    case destruct s of
	       SOME(x,_) => x
      end
   
   structure Foo1 = 
      Foo(type 'a t = 'a list
	  fun destruct _ = let exception E in raise E end)
      
   structure Foo2 =
      Foo(datatype 'a t = T of ('a * 'a t) option
	  fun destruct _ = let exception E in raise E end)
      
in
   val _ = 13
end            

Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]

stdIn:36.6-37.23 Warning: match nonexhaustive
          SOME (x,_) => ...
  
for the type:
I
Error: Compiler bug: LambdaType: unexpected case in tcd_arw
- 

Comments:
Fix: change to translate/specialize.sml	 
Test: bug1243.sml
Owner: Zhong
Status: fixed in 109.31 [Zhong, 7/29/97]
----------------------------------------------------------------------
Number: 1244
Title:       Explicitly scoped type variable with 'val ... and' declaration
Keywords:    translate, lambda types 
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>   
Date:        8/1/97
Version:     109.30, 109.30+
System:	     x86-linux
Severity:    minor
Problem:     Compiler bug caused by use of an explicitly scoped type
             variable in multiple val declarations.
Code:

 val 'a f = fn x : 'a => x
 and g = fn y : 'a => y           

Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- val 'a f = fn x : 'a => x
and g = fn y : 'a => y
= = ;
Error: Compiler bug: Translate: unexpected tyvar INSTANTIATED in mkPE
- 

Comments:
Fix:	 
Test: bug1244.sml
Owner: Zhong, dbm
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1245
Title:       Pretty printer bug
Keywords:    
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/4/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     Error raised when attempting to print the binding of a
             pair of empty lists in the REPL.

Code:        val (x,y) = ([],[])

Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
val it = () : unit
- val (x,y) = ([],[]);

uncaught exception in compiler: subscript out of bounds
  raised at: print/ppobj.sml:422.28-422.33
             print/ppobj.sml:349.20
             print/ppobj.sml:349.20
             util/pp.sml:545.6
             build/evalloop.sml:193.58
- 
Comments:    
Fix:         
Test: bug1245.sml
Owner: Zhong
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1246
Title:       Explicit scoping of type variables does not obey the standard.
Keywords:    explicity scoped type variable
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/4/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     

The following definition does not typecheck.

fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, 
           fn z => z:'a)

The following definition does typecheck.

fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, 
           fn z => z:'b)

I believe that, according to the standard, they both should typecheck.
It appears that the first example is failing because the typechecker
is changing the scope of the explicitly scoped 'a, whereas the
standard only specifies how to determine the scope of implicitly
scoped type variables -- the scope of explicitly scoped type variables
should not change.  As the second example demonstrates, the problem
appears to occur because a bound type variable happens to have the
same name as a free type variable.

Code:        

  fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, 
	     fn z => z:'a)
  fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, 
	     fn z => z:'b)

Transcript:  

  Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
  val it = () : unit
  - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, 
	     fn z => z:'a);
  = stdIn:13.12-13.60 Error: operator and operand don't agree [UBOUND match]
    operator domain: 'a
    operand:         'a -> 'a
    in expression:
      id id
  - fun f() = (let val 'a id :'a -> 'a = fn z => z in id id end, 
	     fn z => z:'b);
  = val f = fn : unit -> ('a -> 'a) * ('b -> 'b)
  - 

 Another example from Andrew Tolmach [8/18/97]

  - val 'a f = fn (x:'a) => let val 'a g = fn (y:'a) => (y,y) in g (x,x) end;
  stdIn:15.25-15.73 Error: operator and operand don't agree [UBOUND match]
    operator domain: 'a
    operand:         'a * 'a
    in expression:
      g (x,x)

Comments:    
 [Andrew Kennedy, 3/20/98]
  I have a small query concerning explicit type variables: the final
  syntactic restriction listed in Section 2.9 (page 9) of the Definition
  seems unnecessary and isn't enforced by SML/NJ. Was it a mistake? In
  particular, the Tolmach example cited on your bug list

     val 'a f = fn (x:'a) => 
     let val 'a g = fn (y:'a) => (y,y) in g (x,x)
     end

  would appear (to me) not to obey this restriction, and yet is perfectly
  sensible if val 'a is essentially `big lambda'. Surely a desirable
  property of the SML is that a declaration such as

     val 'a id = fn x : 'a => x

  can be plugged into an arbitrary program context without breaking any
  restrictions.


Fix: in elabcore.sml, revised calculations of updt in the presence of
  etvs (explicitly bound type variables) to avoid inappropriate instantiations
  of explicit variables.        
Test: bug1246.sml, bug1246.1.sml
Owner: dbm
Status: fixed in 109.31 [dbm, 9/4/97]
----------------------------------------------------------------------
Number: 1247
Title: IntSet library module is wrong
Keywords: smlnj-lib, IntSet, ListSet
Submitter: Andrew Kennedy <andrew@persimmon.co.uk>
Date: 8/4/97
Version: 109.30
System: -
Severity: major 
Problem: 
  A while back I reported some bugs in the ListSet functor. They were
  fixed but unfortunately the fix doesn't appear to have been applied to
  the IntSet specialised version. (Just compare the source files: they're
  are some missing primes on variable names in some functions). 
Comments:
Fix:
Test: ?
Owner: jhr, Emden
Status: Fixed in 109.31
----------------------------------------------------------------------
Number: 1248
Title: blastWrite failures
Keywords: blastRead, blastWrite
Submitter: Chris Paris <cap@cmu.edu>
Date: 8/5/97
Version: 109.30
System: ?
Severity: major 
Problem: blastwrite fails catastrophically
Code:
Transcript:
  Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
  val it = () : unit
  - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);val blastWrite = fn : 'a -> Word8Vector.vector
  - blastWrite (Word8Array.array (516000, 0w0));
  GC #0.0.0.0.1.4:   (0 ms)
  GC #0.0.0.0.2.6:   (10 ms)
  val it = - : Word8Vector.vector
  - blastWrite (Word8Array.array (516001, 0w0));
  GC #0.0.0.1.3.7:   (0 ms)
  GC #0.0.0.1.4.8:   (0 ms)
  ./sml: Fatal error -- blasting out of 516096 bytes not supported yet!  Increase allocation arena size.

But perhaps blasting one large atomic object presents a problem that
blasting a collection of small objects wouldn't, so here's another
example.

  Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
  val it = () : unit
  - val blastWrite : 'a -> Word8Vector.vector = (fn x => Unsafe.CInterface.c_function "SMLNJ-RunT" "blastOut" x);
  val blastWrite = fn : 'a -> Word8Vector.vector
  - fun iter 0 = []
  =   | iter n = n :: (iter (n-1));
  val iter = fn : int -> int list
  - blastWrite (iter 10);
  val it = - : Word8Vector.vector
  - blastWrite (iter 100);
  val it = - : Word8Vector.vector
  - blastWrite (iter 1000);
  val it = - : Word8Vector.vector
  - blastWrite (iter 10000);
  GC #0.0.0.0.1.13:   (20 ms)
  val it = - : Word8Vector.vector
  - blastWrite (iter 100000);
  GC #0.0.0.1.2.16:   (110 ms)
  GC #0.0.0.2.3.17:   (140 ms)
  Segmentation fault

Comments:
 [Chris Paris, 8/5/97]
  In last night's message, I meant to make another comment about
  blastWrite but forgot. I find it limiting that the size of the object
  blastWrite can handle is limited by the allocation arena size. I'm
  already running with a doubled allocation arena size to accomodate our
  growing data, but I understand that I can't just keep increasing it
  indefinitely and expect to retain reasonable performance. The end of
  blast-out.c mentions allocating space in the big-object arena as an
  alternative implementation. I'm wondering if this would be an easy
  change to make that hasn't been done simply due to lack of demand, or
  whether there are difficult issues to overcome in order to remove the
  current limitation.
Fix:
Test: bug1248.1.sml, bug1248.2.sml
Owner: jhr
Status: fixed in 109.31 [jhr, 8/12/97]
----------------------------------------------------------------------
Number: 1249
Title: Time.time type too small
Keywords: Time.time
Submitter: Chris Paris <cap@cmu.edu>
Date: 8/5/97
Version: 109.30
System: -
Severity: minor
Problem: 
  The project I'm working on uses the Time.time type for some
  things. Today we ran into some data that required 32 bits in the sec
  field. We had to write our own time type to handle this. I'm not
  saying the system Time type should definitely be changed, but I
  thought you'd like to know that someone needed more than 31 bits
  there.
Comments:
  The SML Basis now specifies  a LargeInt.int representation for 
  the seconds field. -- jhr
Fix:
Test:
Owner: jhr?
Status: Fixed in 109.31 [jhr, 7/31/97]
----------------------------------------------------------------------
Number: 1250
Title:       Bind exception delayed by polymorphic generalization
Keywords:    Bind exception
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/5/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     A Bind exception is not raised in a value declaration 
             when the variable being defined is polymorphically
             generalized.  I suspect that the raise is getting wrapped
             in a _/\_ in the translation into the typed IL.
             The exception is raised later if the polymorphic value
             is applied.

Code:        datatype 'a foo = Foo1 of 'a | Foo2 of 'a
             val Foo1 f = Foo2(fn x => x);
             f 13;
Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
- datatype 'a foo = Foo1 of 'a | Foo2 of 'a
val Foo1 f = Foo2(fn x => x);
= stdIn:<nullRegion> Warning: binding not exhaustive
          Foo1 f = ...
datatype 'a foo = Foo1 of 'a | Foo2 of 'a
val f = fn : 'a -> 'a
- f 13;

uncaught exception Bind [nonexhaustive binding failure]
  raised at: stdIn:<nullRegion>

Comments:    
 [Zhong, 8/5/97]
  Thanks for the bug report. This bug is actually related to the
  pretty-printing. As you observed, binding f to _/\_ does not
  raise the exception; the exception should be raised when 
  printing f in the top-level (however, the pretty-printing in
  109.30 was broken, so the exception is not raised). 

  Our fixes for the other pretty-printing bugs (which have been
  incorporated into 109.31) should correctly raise the exception,
  however, the exception name is not printed out correctly still.
Fix:         
Test: bug1250.sml
Owner: Zhong
Status: Fixed in 109.31 [Zhong]
----------------------------------------------------------------------
Number: 1251
Title:       where specs cause exception Unbound
Keywords:    where Unbound
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/6/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     The use of a where spec can cause exception Unbound to be
             raised by the elaborator.
Code: 

structure S : sig
                 structure A : sig end
                 structure B : sig structure C : sig end end where C = A
              end =
   struct
      structure A = struct end
      structure B = struct structure C = A end
   end
       
Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- structure S : sig
                 structure A : sig end
                 structure B : sig structure C : sig end end where C = A
              end =
   struct
      structure A = struct end
      structure B = struct structure C = A end
   end;


uncaught exception in compiler: Unbound
  raised at: elaborate/elabmod.sml:1050.15-1050.25
             util/stats.sml:164.40
             build/evalloop.sml:120.38
             build/evalloop.sml:193.58

Comments:    
 [Zhong, 8/6/97]
  Thanks for the bug report. I encountered this same bug while
  trying to fix bug 1205. It happens only if the righthand side
  of the where clause is a "flexible" structure (i.e., locally
  defined structure). Dave and I will try to get a fix into 109.31.
Fix: change strEntEnv to entEnv around line 545 of sigmatch.sml
Test: bug1251.sml
Owner: Zhong, dbm
Status: fixed in 109.31 [Zhong, dbm]
----------------------------------------------------------------------
Number: 1252
Title:       Unbound exception on functor application
Keywords:    modules, functors
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/6/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     A compiler bug is raised on the following code.
  
Code:

  functor F(type t) =
     let structure S : sig
			  type v
			  val x : v
		       end =
	    struct
	       datatype 'a u = U of (t * 'a) list
	       type v = t u
	       val x = U[]
	    end
     in struct
	   datatype t = T of S.v
	   val x = T S.x
	end
     end;

  structure S = F(type t = int);
   
Transcript:

  Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
  - functor F(type t) =
     let structure S : sig
			  type v
			  val x : v
		       end =
	    struct
	       datatype 'a u = U of (t * 'a) list
	       type v = t u
	       val x = U[]
	    end
     in struct
	   datatype t = T of S.v
	   val x = T S.x
	end
     end;

  - structure S = F(type t = int);
  functor F : <sig>
  Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h

[dbm: In 109.31-, the behavior is different.  Unbound (EE.Unbound?) is
raised instead: ]

  - use "test/bugs/bug1252.sml";
  [opening test/bugs/bug1252.sml]
  functor F : <sig>

  uncaught exception Unbound
    raised at: elaborate/elabmod.sml:1060.15-1060.25
	       util/stats.sml:164.40
	       build/evalloop.sml:123.38
	       build/evalloop.sml:196.58
	       build/evalloop.sml:289.46-289.49

Comments:    
 [Zhong]
  This seems to be the same as bug 1234.
Fix:         
Test: bug1252.sml, bug1252.1.sml
Owner: Zhong, dbm
Status: Fixed in 109.31 [Zhong]
----------------------------------------------------------------------
Number: 1253
Title: pretty printing nested polymorphic records
Keywords: pretty printing, representations
Submitter: Chris Page <cap@cmu.edu>
Date: 8/6/97
Version: 109.30
System: -
Severity: major 
Problem: 
  The code in the printer that tries to avoid printing
  polymorphic records doesn't work when the record is wrapped in another
  (non-record) type.
Transcript:
  Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM&CMB]
  val it = () : unit
  - (NONE, ());
  val it = <poly-record> : 'a option * unit
  - SOME (NONE, ());

  uncaught exception in compiler: Representation

Comments:
 [Zhong, 4/4/98]
  By the way, in 110.4, I have fixed the pretty printing of poly record.
  So typing things such as:

    val x = (nil, nil)

  or 

    val x = (nil, 3)

  will print the expected values rather than <poly-record>.

Fix:
Test: bug1253.sml
Owner: Zhong
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1254
Title: Disagreements between SML/NJ and Defn: datatype replication
Keywords:    datatype replication
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/11/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:
  (1) I believe that the Standard says that the following
  program is legal, and should make 's' an abbreviation for
  'int'. However, SML/NJ responds with "Error: rhs of
  datatype replication not a datatype".

    type t = int
    datatype s = datatype t

  SML/NJ and the Standard both accept the following program,
  but I believe they do so for different reasons.

  (2)
    structure S : sig type t end =
    struct
      datatype t = T
    end

    datatype u = datatype S.t

  After the above program is entered, I believe that the
  Standard says that the following declaration is illegal,
  whereas SML/NJ accepts it. 

    val x = T

  My reading of the Standard is that the signature
  constraint on 'S' should hide the constructors associated
  with type 't' and that the declaration of 'u' should
  declare 'u' as an abbreviation of 't', but not be able to
  access t's constructors, since they were hidden by the 
  signature.

Comments:    
 [dbm, 8/14/97]
  Part (1) is considered an omission in the Definition.
  Part (2) is a bug because of rule (80), which says that
  the constructor environment component of t is stipped out
  by signature matching.  This should really cause the
  subsequent datatype replication declaration

    datatype u = datatype S.t

  to fail, because there is no constructor environment for
  u to inherit from S.t, and a datatype without a constructor
  environment is not a proper datatype.
Fix:         
Test: bug1254.sml
Owner: dbm
Status: open (2)
----------------------------------------------------------------------
Number: 1255
Title: Disagreements between SML/NJ and Defn: datatype replication, part II
Keywords:    datatype replication
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/11/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     I believe that the following code is legal, according
             to the Standard.  However, SML/NJ rejects it, responding
             with:

Error: value type in structure doesn't match signature spec
    name: U
  spec:   ?.t -> ?.Foo.u
  actual: ?.int -> ?.Foo.u

Code:        
structure Foo : sig
		   type t
		   datatype u = U of t
		   structure Goo :
		      sig
			 datatype v = datatype u
		      end
		end =
   struct
      type t = int
      datatype u = U of t
      structure Goo =
	 struct
	    datatype v = datatype u
	 end
   end

Transcript:  
Comments:    
Fix:         
  Modified PATHtyc case of expandTyc in elabDATArepl in elabsig.sml.
  Check if entPath is external, in which case nothing needs to be 
  done.  Otherwise, if PATHtyc is internal to current signature, adjust
  it by adding appending prefix.
Test: bug1255.sml
Owner: dbm
Status: fixed in 109.31 [dbm, 7/15/97]
----------------------------------------------------------------------
Number: 1256
Title:       Free type variables in local datatype declarations.       
Keywords:    datatype type variable
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/11/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     In a local datatype declarations, SML/NJ does not accept
             constructors whose types contain type variables that are not
             bound in the datatype declaration (even if they are bound
             in the enclosing program).  For example, I believe that
             the Standard says that following program should be
             accepted.  SML/NJ responds with "Error: unbound type
             variable in type declaration: 'a".

Code:        
fun 'a f (x : 'a) =
   let datatype foo = Foo of 'a * int
   in 13
   end
Transcript:  
Comments:    
 [dbm, 8/13/97]
  This may technically be accepted under the definition, but this is
  an oversight or error in the definition.  For various reasons, if
  a polymorphically bound type variable could participate in type
  definitions as in your example, there would be serious implementation
  complications for very little gain in utility.  I don't plan to "fix"
  this bug in SML/NJ.
Fix:         
Test: *
Owner: dbm
Status: not a bug
----------------------------------------------------------------------
Number:	     1257
Title:       (spurious) dependency cycle in instantiate
Keywords:    modules, opaque signatures
Submitter:   manuel@cs.berkeleye.edu
Date:        8/19/97
Version:     SML-109.30 + blume patch
System:	     x86-linux, sparc-solaris2.5
Severity:    major
Problem:     Opaque signature matching fails when the structure
	     contains a functor whose signature has where
	     specifications. Produces uncaught exception Unbound and
	     a message "dependency cycle in instantiate"

Code:
signature S =
    sig
	type genT
	
	type T

	val embed : T -> genT
    end


structure S =
    struct
	type genT = int
	type T    = int

	val embed = fn x => x
    end



signature B =
    sig
	type genT

	functor mkS() : S where type genT = genT

    end

structure B :> B =
    struct
	type genT = S.genT

	functor mkS() = S

    end

Transcript:

- use "bug_inst.sml";
[opening bug_inst.sml]
bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate

uncaught exception Unbound
  raised at: elaborate/elabmod.sml:1060.15-1060.25
             util/stats.sml:164.40
             build/evalloop.sml:123.38
             build/evalloop.sml:196.58
             build/evalloop.sml:289.46-289.49
- 
Comments:    The idea behind this code is to create new structures
	     using B.mkS(), each of which will share the type genT,
	     but not the type T.

	     The desired behavior can be obtained with the following
	     code, which moves the opaque matching from B to the
	     functor. The difference to the code above is in that genT
	     is not opaque in B.

signature S =
    sig
	type genT
	
	type T

	val embed : T -> genT
	val new   : int -> T
	val show  : genT -> unit

    end


structure S =
    struct
	type genT = int
	type T    = int

	val embed = fn x => x
	
	fun new x = x
	val show = fn x => print (Int.toString x ^"\n")

    end



signature B =
    sig
	type genT

	functor mkS() : S where type genT = genT

    end

structure B : B =
    struct
	type genT = S.genT

	functor mkS() :> S where type genT = genT = S

    end

structure X = B.mkS;
structure Y = B.mkS;

val x = X.new 5;
val y = Y.new 7;

val xe = X.embed x;
val ye = X.embed y;

val _ = X.show ye;   (* is accepted correctly *)
val _ = Y.show xe;   (* is accepted correctly *)
val xf = Y.embed x;  (* rejected correctly *)
val yf = X.embed y;  (* rejected correctly *)

val _ = X.show 5;    (* genT isn't opaque. *)

Fix:
Test:
Owner:		dbm
Status:		Fixed in 109.31
----------------------------------------------------------------------
Number:	     1258
Title:       OS.Process.atExit does not agree with basis documentation
Keywords:    standard basis
Submitter:   Chris Stone, cstone+@cs.cmu.edu
             Perry Cheng, pscheng+@cs.cmu.edu
Date:        August 19, 1997
Version:     109.30
System:      Alpha OSF/1 3.2
Severity:    minor
Problem:     

 From the on-line standard basis documentation for OS.Process.atExit:

  Calls to exit do not return, but should cause the remainder of the
  functions registered with atExit to be executed.

The code does not have this behavior.

Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- OS.Process.atExit (fn _ => print "1\n");
val it = () : unit
- OS.Process.atExit (fn _ => print "2\n");
val it = () : unit
- OS.Process.atExit (fn _ => print "3\n");
val it = () : unit
- ^D3
2
1

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- OS.Process.atExit (fn _ => print "1\n");
val it = () : unit
- OS.Process.atExit (fn _ => OS.Process.exit 1);
val it = () : unit
- OS.Process.atExit (fn _ => print "3\n");
val it = () : unit
- ^D3
3
3
3
...[infinite loop]

Comments:  

A quick glance at the file NJ/cleanup.sml led us to initially expect
that the call to exit would terminate the program immediately,
skipping the third function registered with atExit.  However, it turns
out that since the "clean" function does not change the list "hooks"
when called with the AtExit parameter, the call to exit starts
re-invoking all of the functions registered with AtExit.

Fix:
Test:
Owner:		jhr
Status:		fixed in 109.31
----------------------------------------------------------------------
Number:      1259
Title:       Mistakenly inadmissable signature.
Keywords:    modules, signatures
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/19/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:
  The following signature is not accepted by SML/NJ 109.30,
  even though it should be.  SML/NJ 109.30 returns the message
  "Error: dependency cycle in instantiate".  Earlier
  versions, such as 109.29, accepted this signature at
  the point it was declared, but reported the dependency
  cycle error when it was used as a functor parameter
  (i.e. when it was instantiated).
Code:        
  signature SIG =
  sig
    type b'
    datatype a = A1 | A2 of b'
    datatype b = B1 | B2 of a
    sharing type b = b'
  end

The signature is accepted when it directly constrains a structure, as
in the following code.

  structure S : sig
		  type b'
		  datatype a = A1 | A2 of b'
		  datatype b = B1 | B2 of a
		  sharing type b = b'
	        end =
  struct
    datatype a = A1 | A2 of b
    and b = B1 | B2 of a
    type b' = b
  end

Transcript:  
Comments:    
  This might be the same as bug #1257.

 [Zhong, 8/21/97]
  Ok, in 109.30, we check the validity of every signature at its definition
  site (i.e., we try to instantiate it), thus the cycle is detected even
  at the declaration site.

  |> In any case, both versions are wrong to reject the signature, since it 
  |> can be instantiated by the structure I provided.
  |>
  |> structure S : sig
  |>		  type b'
  |>		  datatype a = A1 | A2 of b'
  |>		  datatype b = B1 | B2 of a
  |>		  sharing type b = b'
  |>	       end =
  |>   struct
  |>      datatype a = A1 | A2 of b
  |>      and b = B1 | B2 of a
  |>      type b' = b
  |>   end

  I'd not say our implementation is wrong :-) I'd argue that it is the 
  Definition that is wrong --- in fact, the Definition is vague on how 
  the above signature will be elaborated --- if you follow what's said 
  in the Definition, you will get a structure of the form

      structure SIG-INST = 
	struct type b' = b
	       datatype a = A1 | A2 of b
	       datatype b = B1 | B2 of a
	end

  [dbm: not quite.  The definition (rule 78) elaborates the sharing
  spec by applying a substitution to an already elaborated environment
  structure representing the previous specs.]

  Notice I have no way to reorder the above into a valid ML structure.
  The best I can do is:

      structure SIG-INST = 
	struct datatype a = A1 | A2 of b
	       datatype b = B1 | B2 of a
	       type b' = b
	end

  still type a and b are mutually recursive. To make it work, the
  signature elaboration has to make a and b mutually recursive:

      structure SIG-INST = 
	struct datatype a = A1 | A2 of b
	       and b = B1 | B2 of a
	       type b' = b
	end

  This is non-trivial to generalize to cover other cases; for example,
  what if SIG is like the following:

      signature SIG' =
	sig  type b'
	     datatype a = A1 | A2 of b'
	     structure S : sig
			       datatype b = B1 | B2 of a
			   end
	     sharing type b' = S.b'
	end

  SIG' probably will not match any structure, but it is very hard
  to discover what is match-able and what is not.

  Because of all these, we decided to adopt a simpler algorithm
  in SML/NJ --- we'll only do reorganizations of all the specs,
  but we'll never merge two non-recursive datatype specs into 
  mutually-recursive ones.

 [dbm, 8/5/97]
  I think that it would probably be possible to fix this "bug"
  superficially in the Instantiate module, but I am not sure what
  the consequences would be for FLINT's type representation analysis.

  In particular, with a signature declaration such as the
  following

[1] signature SIG =
    sig
      type b'
      datatype a = A1 | A2 of b'
      datatype b = B1 | B2 of a
      sharing type b = b'
    end

  the datatypes a and b are made mutually recursive "after the fact"
  as a consequence of the type sharing spec.  Will the FLINT
  representation analysis be able to come up with the same
  representations of a and b as for the following "equivalent"
  (see comment on equality properties below) signatures:

[2] signature SIG =
    sig
      datatype a = A1 | A2 of b
	   and b = B1 | B2 of a
      type b'
      sharing type b = b'
    end

[3] signature SIG =
    sig
      datatype a = A1 | A2 of b
	   and b = B1 | B2 of a
      type b' = b
    end

  and if you come up with different representations for the latter
  two signatures, does it matter?

  In other words, if you have two independent datatype specs, and
  then tie a knot between them by a subsequent sharing spec, can you
  recover the same representation as though the types had originally
  been specified as mutually recursive, or do you care?

  There is also the issue of assigning the equality properties to
  the specified types.  In [1], b' does not admit equality, and
  therefore neither does a, and so neither does b.  In [2] and [3],
  a and b, and therefore b', do admit equality.  Does this inconsistency
  matter?

  Also, things can get much more convoluted; for instance

    signature SIG =
    sig
      structure A : sig
                      type a
                    end		      
      structure B : sig
                      datatype b = B1 | B2 of A.a
                    end		      
      structure C : sig
                      datatype c = C1 | C2 of B.b
                    end		      
      sharing type A.a = C.c
    end

  which could be matched by the structure

    structure S =
    struct
      datatype b = B1 | B2 of c
           and c = C1 | C2 of b
      structure A = struct
                      type a = c
                    end
      structure A = struct
                      datatype b = datatype b
                    end
      structure A = struct
                      datatype c = datatype c
                    end
    end

  I think it is clear that we don't want to force Instantiate
  to be this clever when attempting to create a realization.

  So how do we formulate a sharp condition that will disallow
  these kinds of recursion through sharing specs?

Fix:         
Test: bug1259.1.sml, bug1259.2.sml, bug1259.3.sml
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number:		1260
Title: 		Compiler bug (EntityEnv) when compiling ml-yacc
Keywords: 
Submitter: 	John Reppy (jhr@research.bell-labs.com)
Date: 		August 26, 1997
Version: 	109.30+
System: 	all
Severity: 	major
Problem: 
  I changed ml-yacc by replacing the three uses of "abstraction"
  with ":>".  Now I get a compiler error on the file parser2.sml,
  which is one of the files I changed.  I note that this file compiled
  okay in the context of the compiler, but not when trying to
  compile ml-yacc.  Note, the changed file is accepted by 109.30,
  so this must have been introduced by one of the recent changes.
Code:
Transcript:
  [opening ../lib/parser2.sml]
  GC #0.0.0.1.3.62:   (76 ms)
  lookEnt.1: expected STRent
  found entity: TYCent
  entpath: [#L.52,#L.1]
  Error: Compiler bug: EntityEnv: lookEnt.2
 
  uncaught exception TopLevelException [Error]
    raised at: util/errormsg.sml:54.14-54.19
               modules/instantiate.sml:1122.9
               elaborate/elabmod.sml:1119.8
               util/stats.sml:164.40
               build/evalloop.sml:123.38
               build/evalloop.sml:196.58
               build/evalloop.sml:289.46-289.49

Comments:
  Zhong says:
    I found a fix for the bug. The bug was caused by Dave and Matthias's
    recent changes on turning off "pickling" in the top level (sigh ...).
    In fact, a more severe bug is the test case below.

    It turns out that the mkStamp function is making new stamp from 0
    when compiling each compilation unit (hmmm, not quite accurate, look
    when evalLoop is called in interact.sml). So t and s share the
    same stamp (L0).

    If we do pickling, s and t's stamps will be globalized during the
    pickling, so they will not be indentified.

    For the ML-Yacc, it is the similar reason. Because the stamp is not
    unique, the entity variable created for each signature component is
    not unique, this confuses the elaborator thus causing the bug.

Fix:
    I make sure that the compiler never resets the global stamp
    counter --- notice that if the interactive loop is long enough
    (e.g., even after exportML,...); it is possible to run out of the stamps
    (i.e., overflow) --- especially the same stamp counter is now used
    for multiple purposes (stamp, entvar, ...). With pickling, the counter
    is reset each time and the pickler always globalize all the stamps
    (even hidden ones) with an external pid !

Test:
  (* typing in each of the following at the top-level *)

        local datatype t = A
        in val x = A
        end;

        junk; (* this line is crucial; the purpose is to cause an error *)

        local datatype s = B
        in val y = B
        end;

        x = y;

  (* The compiler accepts the "x = y", and producing true. *)

Owner: dbm, blume, zsh
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1261
Title: explicit type parameter with "val rec" not supported
Keywords: syntax, explicit type parameters
Submitter: Dave MacQueen
Date: 9/4/97
Version: 109.30
System: -
Severity: minor 
Problem: 
  Syntax "val 'a rec ..." not implemented.
Transcript:
  - val 'a rec f = fn x : 'a => x;
  stdIn:14.8-14.15 Error: syntax error: deleting  REC ID EQUALOP
  stdIn:14.16-14.22 Error: syntax error: deleting  FN ID COLON
  stdIn:14.23-14.28 Error: syntax error: deleting  TYVAR DARROW
Comments:
Fix:
Test: bug1261.sml
Owner: dbm, Appel
Status: open
----------------------------------------------------------------------
Number: 1262
Title: literal ~0.0 reads as 0.0
Keywords: floating point, literals
Submitter:      appel
Date:		August 19, 1997
Version:        109.30
System:         any
Severity:       minor
Problem:        literal ~0.0 reads as 0.0
Code:           Real.copysign(1.0,~0.0)
Transcript:     val it = 1.0
Comments:       
Fix:            in first if-statement of ieeereal.sml
Test:		bug1262.sml
Owner:		Appel
Status: open
----------------------------------------------------------------------
Number: 1263
Title: sqrt, ln incorrect on subnormal numbers
Keywords: floating point, math
Submitter:      appel
Date:		August 19, 1997
Version:        109.30
System:         any
Severity:       minor
Problem:        sqrt, ln incorrect on subnormal numbers
Code:           let val a = Math.sqrt(Real.minNormalPos * 0.1)
                 in [Real.minNormalPos*0.1, a*a]
                end
Transcript:     val it = [2.22507385851e~309,1.22379062218e~308] : real list
Comments:       The scalb and logb functions in math64.sml
                called upon Assembly.A.scalb,logb, 
                and were already augmented to handle a bigger range 
                of cases than the assembly-lang primops,
                but I made them even fancier to handle subnormal
                inputs and outputs.
Status:         fixed in 109.31
----------------------------------------------------------------------
Number: 1264
Title:       (spurious) dependency cycle in instantiate
Keywords:    modules, opaque signatures
Submitter:   manuel@cs.berkeleye.edu
Date:        8/19/97
Version:     SML-109.27 + blume patch
System:	     x86-linux, sparc-solaris2.5
Severity:    major
Problem:     Opaque signature matching fails when the structure
	     contains a functor whose signature has where
	     specifications. Produces uncaught exception Unbound and
	     a message "dependency cycle in instantiate"

Code:
signature S =
sig
  type genT
  type T
  val embed : T -> genT
end;

structure S =
struct
  type genT = int
  type T    = int
  val embed = fn x => x
end;

signature B =
sig
  type genT
  functor mkS() : S where type genT = genT
end;

structure B :> B =
struct
  type genT = S.genT
  functor mkS() = S
end;

Transcript:

- use "bug_inst.sml";
[opening bug_inst.sml]
bug_inst.sml:29.1-35.8 Error: dependency cycle in instantiate

uncaught exception Unbound
  raised at: elaborate/elabmod.sml:1060.15-1060.25
             util/stats.sml:164.40
             build/evalloop.sml:123.38
             build/evalloop.sml:196.58
             build/evalloop.sml:289.46-289.49
- 
Comments:    The idea behind this code is to create new structures
	     using B.mkS(), each of which will share the type genT,
	     but not the type T.

	     The desired behavior can be obtained with the following
	     code, which moves the opaque matching from B to the
	     functor. The difference to the code above is in that genT
	     is not opaque in B.

signature S =
sig
  type genT
  type T

  val embed : T -> genT
  val new   : int -> T
  val show  : genT -> unit
end

structure S =
struct
  type genT = int
  type T    = int

  val embed = fn x => x

  fun new x = x
  val show = fn x => print (Int.toString x ^"\n")
end

signature B =
sig
  type genT
  functor mkS() : S where type genT = genT
end

structure B : B =
struct
  type genT = S.genT
  functor mkS() :> S where type genT = genT = S
end

structure X = B.mkS;
structure Y = B.mkS;

val x = X.new 5;
val y = Y.new 7;

val xe = X.embed x;
val ye = X.embed y;

val _ = X.show ye;   (* is accepted correctly *)
val _ = Y.show xe;   (* is accepted correctly *)
val xf = Y.embed x;  (* rejected correctly *)
val yf = X.embed y;  (* rejected correctly *)

val _ = X.show 5;    (* genT isn't opaque. *)

Fix:	     <sorry>
Test: bug1264.sml
Owner: Zhong
Status: fixed in 109.31 [Zhong, 8/21/97]
----------------------------------------------------------------------
Number: 1265
Title:       uncaught Match exn in elabmod.sml:632.7
Keywords:    module elaboration, signature matching
Submitter:   manuel@cs.berkeley.edu
Date:        8/19/97
Version:     109.30 + Matthias Blume patch
System:	     x86-linux, sparc-solaris2.5
Severity:    major
Problem:     Signature matching causes Match exception in compiler
Code:
structure J : S = K : T;

Transcript:  
-  structure J : S = K : T;

uncaught exception in compiler: nonexhaustive match failure
  raised at: elaborate/elabmod.sml:632.7
             elaborate/elabmod.sml:1059.8
             util/stats.sml:164.40
             build/evalloop.sml:123.38
             build/evalloop.sml:196.58
- 
Comments:    
Fix:	     
Test: bug1265.sml
Owner: Zhong, dbm
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1266
Title:       OS.Process.atExit does not agree with basis documentation
Keywords:    standard basis
Submitter:   Chris Stone, cstone+@cs.cmu.edu
             Perry Cheng, pscheng+@cs.cmu.edu
Date:        August 19, 1997
Version:     109.30
System:      Alpha OSF/1 3.2
Severity:    minor
Problem:     

 From the on-line standard basis documentation for OS.Process.atExit:

  Calls to exit do not return, but should cause the remainder of the
  functions registered with atExit to be executed.

The code does not have this behavior.

Transcript:  

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- OS.Process.atExit (fn _ => print "1\n");
val it = () : unit
- OS.Process.atExit (fn _ => print "2\n");
val it = () : unit
- OS.Process.atExit (fn _ => print "3\n");
val it = () : unit
- ^D3
2
1

Standard ML of New Jersey, Version 109.30, July 17, 1997 [CM; autoload enabled]
- OS.Process.atExit (fn _ => print "1\n");
val it = () : unit
- OS.Process.atExit (fn _ => OS.Process.exit 1);
val it = () : unit
- OS.Process.atExit (fn _ => print "3\n");
val it = () : unit
- ^D3
3
3
3
...[infinite loop]

Comments:  

A quick glance at the file NJ/cleanup.sml led us to initially expect
that the call to exit would terminate the program immediately,
skipping the third function registered with atExit.  However, it turns
out that since the "clean" function does not change the list "hooks"
when called with the AtExit parameter, the call to exit starts
re-invoking all of the functions registered with AtExit.

Fix: *
Test: *
Owner: jhr
Status: fixed in 109.31 [jhr, 8/19/97]
----------------------------------------------------------------------
Number: 1267 (duplicate of bug 1259)
Title:       Mistakenly inadmissable signature.
Keywords:    modules, signatures, definition specs, datatype specs
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        8/19/97
Version:     109.30
System:      x86-linux
Severity:    minor
Problem:     The following signature is not accepted by SML/NJ 109.30,
             even though it should be.  SML/NJ 109.30 returns the message
             "Error: dependency cycle in instantiate".  Earlier
             versions, such as 109.29, accepted this signature.
       
signature SIG =
   sig
      type b'
      datatype a = A1 | A2 of b'
      datatype b = B1 | B2 of a
      sharing type b = b'
   end

             The signature is accepted when it directly constrains a 
             structure, as in the following code.

structure S : sig
		  type b'
		  datatype a = A1 | A2 of b'
		  datatype b = B1 | B2 of a
		  sharing type b = b'
	       end =
   struct
      datatype a = A1 | A2 of b
      and b = B1 | B2 of a
      type b' = b
   end

Code:        

Transcript:  
Comments:    
 [Zhong, 8/21/97]
  |> In any case, both versions are wrong to reject the signature, since it 
  |> can be instantiated by the structure I provided.
  |>
  |> structure S : sig
  |>		  type b'
  |>		  datatype a = A1 | A2 of b'
  |>		  datatype b = B1 | B2 of a
  |>		  sharing type b = b'
  |>	       end =
  |>   struct
  |>      datatype a = A1 | A2 of b
  |>      and b = B1 | B2 of a
  |>      type b' = b
  |>   end

  I'd not say our implementation is wrong :-) I'd argue that it is the 
  Definition that is wrong --- in fact, the Definition is vague on how 
  the above signature will be elaborated --- if you follow what's said 
  in the Definition, you will get a structure of the form

      structure SIG-INST = 
	struct type b' = b
	       datatype a = A1 | A2 of b
	       datatype b = B1 | B2 of a
	end

  Notice I have no way to reorder the above into a valid ML structure.
  The best I can do is:

      structure SIG-INST = 
	struct datatype a = A1 | A2 of b
	       datatype b = B1 | B2 of a
	       type b' = b
	end

  still type a and b are mutually recursive. To make it work, the
  signature elaboration has to make a and b mutually recursive:

      structure SIG-INST = 
	struct datatype a = A1 | A2 of b
	       and b = B1 | B2 of a
	       type b' = b
	end

  This is non-trivial to generalize to cover other cases; for example,
  what if SIG is like the following:

      signature SIG' =
	sig  type b'
	     datatype a = A1 | A2 of b'
	     structure S : sig
			       datatype b = B1 | B2 of a
			   end
	     sharing type b' = S.b'
	end

  SIG' probably will not match any structure, but it is very hard
  to discover what is match-able and what is not.

  Because of all these, we decided to adopt a simpler algorithm
  in SML/NJ --- we'll only do reorganizations of all the specs,
  but we'll never merge two non-recursive datatype specs into 
  mutually-recursive ones.

Fix: -
Test: -
Owner: dbm, Zhong
Status: not a bug
----------------------------------------------------------------------
Number: 1268
Title: logb of negative numbers on Sparc
Keywords: floating point, logb
Submitter: appel
Date: 8/21/97
Version: 109.30
System: Sparc
Severity: minor
Problem: Assembly.A.logb gives bogus result for any negative number.
Code: Assembly.A.logb ~1.0;  (* this example from 109.29 *)
Transcript: val it = 2048 : int
Comments: broken since 109.26 or before
 [dbm, 11/11/97] Test case is obsolete in 109.32 because Assembly is
  not bound at top level.  Needs to be tested indirectly by regression
  tests on Math, Real64 structures.
Fix: in SPARC.prim.asm
Test: bug1268.sml (obsolete)
Owner: Appel
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1269
Title:		CM.set_path has no effect after CM.make
Keywords: CM
Submitter:	John Reppy (jhr@research.bell-labs.com)
Date:		August 21, 1997
Version:	109.30
System:		all
Severity:	minor
Problem:	One a CM.make command has been executed, changing the
		search path has no effect.
Code:
Transcript:

  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/mipseb-unix/sources.cm.stable ... not usable]

  !* CM error: smlnj-lib.cm: description file not found
  - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]);
  val it = [] : string list
  - CM.make();
  [starting dependency analysis]

  !* CM error: smlnj-lib.cm: description file not found
  -

whereas, if I change the path first, it works fine.

  - CM.set_path(SOME[".", "/home/sml/Dev/jhr/109.x/lib"]);
  val it = [] : string list
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/mipseb-unix/sources.cm.stable ... not usable]
  [scanning /home/sml/Dev/jhr/109.x/lib/smlnj-lib.cm -> /n/stew/home/sml/Dev/jhr/109.x/src/smlnj-lib/Util/sources.cm]
  ...

Comments:
Fix:
Test:
Owner: Blume
Status: open?
----------------------------------------------------------------------
Number: 1270
Title: EntityEnv.Unbound raised while compiling functor
Keywords: modules, functors, signature matching
Submitter: Lal George
Date: 9/8/97
Version: 109.31
System: -
Severity: major 
Problem: 
  EntityEnv.Unbound raised while compiling functor
Code:
  (* bug1270.sml *)

  signature S2 =
  sig
    structure A : sig type s end
    val x : A.s
  end;

  signature S3 =
  sig
    type u
    val y : u
  end;

  functor F (structure X: S3) =  (* "structure" necessary *)
  struct
    type s = X.u
  end;

  functor G (U: S3) (V: S2) : S2 =  (* ": S2" necessary *)
  struct
    structure A = F (structure X = U)
    val x = U.y
  end;
Transcript:
  - use "bug1270.sml";
  [opening bug1270.sml]
  signature S2 =
    sig
      structure A : sig type s end
      val x : A.s
    end
  signature S3 =
    sig
      type u
      val y : u
    end
  functor F : <sig>

  uncaught exception Unbound
    raised at: elaborate/elabmod.sml:1225.39-1225.49
	       util/stats.sml:164.40
	       build/evalloop.sml:123.38
	       build/evalloop.sml:196.58
	       build/evalloop.sml:292.19-292.22

Comments:
  Regression failure for bug 922.
Fix:
Test: bug1270.sml
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1271
Title: uncaught Unbound while compiling open
Keywords: modules, functors, open
Submitter: Lal George
Date: 9/8/97
Version: 109.31
System: -
Severity: major
Problem: uncaught Unbound while compiling open
Code:
  signature SIG1 =
  sig
    type t
    val x: t
  end;

  signature SIG2 =
  sig 
    functor Foo(X:SIG1) : sig val w: X.t end 
  end;

  structure B : SIG2 =  (* ": SIG2" is necessary *)
  struct
    functor Foo(X:SIG1) =
      struct
	val w = X.x 
      end
  end;

  open B;

Transcript:
  - use "bug1271.sml";
  [opening bug1271.sml]
  signature SIG1 =
    sig
      type t
      val x : t
    end
  signature SIG2 =
    sig functor Foo : (<paramname>: <sig>) : <sig> end
  structure B :
    SIG2

  uncaught exception Unbound
    raised at: translate/transmodules.sml:80.33-80.43
	       util/stats.sml:164.40
	       build/evalloop.sml:196.58
	       build/evalloop.sml:292.19-292.22
Comments:
  Regression failure for bug 641.
 
  The SIG2 signature constraint on B is necessary for the
  bug to occur.

  Other references to B.Foo, such as 

    functor F = B.Foo

  or

    structure XX = B.Foo(struct type t = int val x = 3 end);

  will also cause an uncaught Unbound exception.
Fix:
Test: bug1271.sml
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1272
Title: Match exception raised in instantiate while elaborating sig
Keywords: modules, signatures, definition specs, sharing
Submitter: Lal George
Date: 9/8/97
Version: 109.31
System: -
Severity: major 
Problem: 
  Match exception raised in instantiate while elaborating sig
Code: (bug1272.sml)
  signature Z = sig end;

  signature S =
  sig
    structure A: Z
  end;

  signature T1 =
  sig
    structure B: S
    structure A : Z = B.A
  end;

  signature T2 =
  sig
    structure B: S
    structure A : Z = B.A
  end;

  signature V =
  sig
    structure C: T1
    structure D: T2
    sharing C = D
  end;

Transcript:
  uncaught exception Match [nonexhaustive match failure]
    raised at: modules/instantiate.sml:706.6
	       modules/instantiate.sml:802.29
	       modules/instantiate.sml:1164.55
	       util/stats.sml:164.40
	       elaborate/elabmod.sml:1259.33
	       util/stats.sml:164.40
	       build/evalloop.sml:123.38
	       build/evalloop.sml:196.58
	       build/evalloop.sml:292.19-292.22

Comments:
  Regression failure for bug 429.
Fix: added appropriate rule for VARstrDef to case expression in
  SDEFINE case of constrain within buildStrClass.
Test: bug1272.sml
Owner: dbm
Status: fixed in 109.32 [dbm, 9/9/97]
----------------------------------------------------------------------
Number: 1273
Title: control-c doesn't interrupt infinite loop
Keywords: interrupt, tail recursion, runtime, gc check
Submitter: Allen Stoughton allen@cis.ksu.edu
Date: 9/10/97
Version: 109.31
System: sparc-solaris
Severity: major
Problem: 
  When a tail-recursive function infinite loops, CTRL-c doesn't
  interrupt the computation
Code:
Transcript:
- fun f x = f x;
GC #2.5.6.7.9.24:   (0 ms)
val f = fn : 'a -> 'b
- f 0 : int;

(CTRL-c has no effect)

On the other hand, if I type

- fun f n = if n = 0 then 1 else n * f(n-1);
val f = fn : int -> int
- f ~1;
GC #0.0.0.0.1.4:   (0 ms)
GC #0.0.0.1.2.5:   (90 ms)
GC #0.0.1.2.3.10:   (470 ms)
GC #0.1.2.3.4.11:   (610 ms)
GC #1.2.3.4.5.16:   (1030 ms)
GC #1.3.4.5.6.17:   (350 ms)
GC #2.4.5.6.7.22:   (1480 ms)

Interrupt

then I can interrupt out successfully.
Comments: sparc-solaris specific
Fix:
  The problem was that on Solaris the heap addresses are in the top half
  of the range (i.e., negative), and the code generator was using a signed
  comparison for the heap limit check.  The fix was to change this to
  an unsigned comparison.
Test: -
Owner: jhr
Status: fixed in 109.32 [jhr, 9/10/97]
----------------------------------------------------------------------
Number: 1274
Title: secondary compiler bug caused by unbound signature
Keywords: secondary error, instantiate
Submitter: Lal George
Date: 9/8/97
Version: 109.31
System: -
Severity: minor 
Problem: secondary compiler bug caused by unbound signature
Code: 
  functor F
      (structure A : S
       structure B : S
	  sharing type B.t = A.s) = struct end;
Transcript:
  - functor F
  =   (structure A : S
  =    structure B : S
  =       sharing type B.t = A.s) = struct end;
  stdIn:8.6-10.24 Error: unbound signature: S
  stdIn:8.6-10.24 Error: unbound signature: S
  Error: Compiler bug: Instantiate: distributeT:stepPath 2

Comments:
Fix:
Test: bug1274.sml
Owner: dbm
Status: fixed in 109.32
----------------------------------------------------------------------
Number: 1275
Title: mod and div broken on alpha
Keywords: mod, div, alpha
Submitter: george@persimmon.co.uk
Date: 9/10/97
Version: 109.31
System: alpha-unix
Severity: major
Problem: mod and div broken on alpha
Transcript:
  - Word32.mod(0w22,0w11);
  val it = 0wxffffffea : Word32.word
Comments:
 [Lal, 9/11/97]
  In 109.31, division (divl and divlu) is implemented by a call to
  assembly rather than generating inline code that uses floating point
  registers. The overhead in doing this with a graph coloring allocator
  is very low.

  However, this test case pointed out a subtle bug in the interaction of
  parallel copy instructions with interference graph construction that
  is very serious and likely to show up wherever division is used. 

  I have corrected this and the fix will be in the next version. I will
  also be making a patch file available (soon) incase you are familiar
  with recompiling the compiler (see the CM doc).
Fix:
Test: bug1275.sml
Owner: Lal
Status: fixed in 109.32 [Lal, 9/11/97]
----------------------------------------------------------------------
Number: 1276
Title:       Posix.TTY.getattr returns invalid object.
Keywords:    Posix TTY
Submitter:   David Brown <dbrown@vigra.com>
Date:        09/10/1997
Version:     109.31
System:      x86-linux
Severity:    major
Problem:     The Posix.TTY.getattr function returns an object
	     that doesn't appear to be valid.  From what I can tell,
             the C code uses WORD_ALLOC to construct the members of
             the record.  This object doesn't correspond with the
             Word32.word object that the ml code is expecting.
Code:
   structure Read = struct
   
       structure FS = Posix.FileSys
       structure TTY = Posix.TTY
       structure IO  = Posix.IO
   
       val O_RDWR = FS.O_RDWR
       val no_flags = FS.O.flags []
   
       fun openf name = FS.openf (name, O_RDWR, no_flags)
   
       fun exp () = let
	   val fd = openf "/dev/tty"
   (*
	   val fields = {iflag = TTY.I.flags [],
			 oflag = TTY.O.flags [],
			 cflag = TTY.C.flags [TTY.C.cs8, TTY.C.cread],
			 lflag = TTY.L.flags [],
			 cc = Posix.TTY.V.cc [],
			 ispeed = TTY.b9600,
			 ospeed = TTY.b9600}
	   val ios = TTY.termios fields
	   val _ = TTY.setattr (fd, TTY.TC.saflush, ios)
   *)
	   val ios = TTY.getattr fd
	   val _ = IO.close fd
       in
	   ios
       end
   
   end
Transcript:  <transcript of exectution demonstating the bug>
      - use "read.sml";
      structure Read :
	sig
	  structure FS : <sig>
	  structure IO : <sig>
	  structure TTY : <sig>
	  val O_RDWR : ?.POSIX_FileSys.open_mode
	  val exp : unit -> ?.POSIX_TTY.termios
	  val no_flags : ?.POSIX_FileSys.O.flags
	  val openf : string -> ?.POSIX_FileSys.file_desc
	end
      val it = () : unit
      - Read.exp ();
      
      uncaught exception in compiler: Representation
	raised at: boot/Unsafe/object.sml:106.17-106.31
		   print/ppobj.sml:354.20
		   print/ppobj.sml:354.20
		   print/ppobj.sml:354.20
		   print/ppobj.sml:354.20
		   print/ppobj.sml:354.20
		   util/pp.sml:554.6
		   build/evalloop.sml:196.58
      -
Comments:    Everything that I can find built with WORD_ALLOC seems to
             be wrong in this way.
Fix:
 [jhr, 9/10/97]
  The problem is that the WORD_ALLOC (and INT32_ALLOC) macros in the
  run-time are allocating records, when they should be allocating
  4-byte vectors.

Test: *
Owner: jhr
Status: fixed in 109.32 [jhr, 9/10/97]
----------------------------------------------------------------------
Number: 1277
Title:       Segmentation fault
Keywords:    OS.FileSys OS.Path under suspicion, but perhaps it is eXene specific.
Submitter:   nikolaj@cs.stanford.edu
Date:        jada jada jada
Version:     109.31
System:      sparc-solaris2.5
Severity:    critical
Problem:

I am able to make 109.31 terminate with a segmentation fault. 
The problem could be connected to the IS.FileSys structures, but then 
I was able to generate segmentation faults without calls to OS. 
In the process of identifying the source of the problem further I ran
the following experiments which had some strange behaviour:


  - open Posix.FileSys;
  opening Posix.FileSys
    POSIX_FILE_SYS
  -  stat "/manet/u1";
  val it =
    ST
      {atime=TIME {sec=873972901,usec=0},ctime=TIME {sec=867367954,usec=0},

  uncaught exception in compiler: Representation
    raised at: boot/Unsafe/object.sml:106.17-106.31
	       print/ppobj.sml:354.20
	       print/ppobj.sml:354.20
	       print/ppobj.sml:354.20
	       print/ppobj.sml:354.20
	       print/ppobj.sml:354.20
	       util/pp.sml:554.6
	       build/evalloop.sml:196.58
  - 

In fact my code never calls this function, so this bug seems to be rather
peripheric to the main problem.


The Segmentation faults seem to happen in some different ways:

  manet> ./new-step
  GC #0.0.0.0.1.1:   (0 ms)
  GC #0.0.0.1.2.2:   (30 ms)

  STeP Version 1.2-beta (educational release)
  Compiled Wed Sep 10 02:53:48 1997
  Copyright 1995, 1996, 1997 Stanford University Computer Science Department
  SML Version: 109
  Concurrent ML, Version 1.0.9, September 1, 1997

  GC #0.0.0.2.3.3:   (30 ms)
  GC #0.0.1.3.4.27:   (50 ms)
  Segmentation fault (core dumped)
  -------------------------------------------------
  manet> ./new-step
  GC #0.0.0.0.1.1:   (0 ms)
  GC #0.0.0.1.2.2:   (10 ms)

  STeP Version 1.2-beta (educational release)
  Compiled Wed Sep 10 02:53:48 1997
  Copyright 1995, 1996, 1997 Stanford University Computer Science Department
  SML Version: 109
  Concurrent ML, Version 1.0.9, September 1, 1997

  GC #0.0.0.2.3.3:   (20 ms)
  GC #0.0.1.3.4.49:   (50 ms)
  GC #0.1.2.4.5.99:   (110 ms)
  GC #0.1.3.5.6.100:   (40 ms)
  GC #1.2.4.6.7.114:   (150 ms)
  GC #1.3.5.7.8.126:   (50 ms)
  Segmentation fault

Comments:
 [jhr, 9/11/97]
  This Representation exception bug is because we are allocating Word32.word
  values in the run-time with the wrong tag.  Someone else reported it yesterday,
  and it has already been fixed for the next release.  If you want, I can send
  you a replacement for src/runtime/include/ml-objects.h that fixes the bug.
Fix: 
Test: 
Owner: jhr
Status: fixed in 109.32 [jhr, 9/19/97]
----------------------------------------------------------------------
Number: 1278
Title: segmentation faults running Unix.execute
Keywords: Unix.execute, segmentation fault, core dump
Submitter: Nikolaj Bjorner <Theory.Stanford.EDU!nikolaj>
Date: 9/11/97
Version: 109.31
System: sparc-solaris?
Severity: critical
Problem: 
  We have now encountered some Segmentation faults while running Unix.execute 
  from inside RunCML.

  I have not been able to reproduce the Segmentation fault on a simple
  example yet, but the following code:

  structure Test = 
  struct

  fun doit fileName () = 
      let
	  val proc = Unix.execute(fileName,[])
	  val (fin,fout) = Unix.streamsOf proc
      in
	  TextIO.closeIn fin;
	  TextIO.closeOut fout;
	  ()
      end

  fun run fileName = 
      (print ("\n"^(fileName)^":\n");
       RunCML.doit(doit fileName, NONE)
      )

  end


  has the following effect:

  manet> /step/sml/bin/cml-cm
  Concurrent ML, Version 1.0.9, September 1, 1997[CML autoload]
  - CM.make();
  [starting dependency analysis]
  [scanning ....
  ..ecovering /step/sml-109.31/src/cml/src/glue/CM/sparc-unix/export-fn-fn.sml.bin... done]
  [recovering /step/sml-109.31/src/cml/src/glue/CM/sparc-unix/run-cml-fn.sml.bin... done]
  [recovering /step/sml-109.31/src/cml/src/Unix/CM/sparc-unix/unix-glue.sml.bin... done]
  [recovering /step/sml-109.31/src/cml/src/Unix/CM/sparc-unix/run-cml.sml.bin... done]
  [recovering CM/sparc-unix/test.sml.bin...GC #0.0.0.1.5.149:   (10 ms)
   done]
  [introducing new bindings into toplevel environment...]
  val it = () : unit
  - Test.run "ls";

  ls:
  manet> 

  That is, the ML session is terminated.
Comments:
Fix:
Test:
Owner: jhr
Status: fixed in 109.32 [jhr, 9/19/97]
----------------------------------------------------------------------
Number: 1279
Title:       frags and backquotes are confused
Keywords:    frag
Submitter:   Elsa L. Gunter
Date:        9/12/97
Version:     109.31
System:      x86-linux2.0
Severity:    major
Problem:     The type constructor frag is not present at top level,
and
             when given a quote it sits waiting further input
regardles of
             the state of Compiler.Control.quotation.
Code:
fn x:'a frag => x;

val y = 'a';

Transcript:  
norfolk% sml
Standard ML of New Jersey, Version 109.31, September 8, 1997 [CM;
autoload enabled]
- fn x:'a frag => x;
stdIn:17.9-17.13 Error: unbound type constructor: frag
- val y = 'a';
= 
= 
= stdIn:2.4 Error: syntax error found at TYVAR
- 

Comments:
  I typed ^D to get to return to top level.  The behavior is
  the same if you set Compiler.Control.quotation:= true;

 [jhr, 9/12/97]
  Quotation sort of works in my modified 109.31, but the translation
  of syntax is broken:

    Standard ML of New Jersey, Version 109.32, September 15, 1997 [new runtime]
    - Compiler.Control.quotation := true;
    val it = () : unit
    - `a`;
    stdIn:8.1-8.4 Error: unbound variable or constructor: QUOTE
    - datatype frag = datatype SMLofNJ.frag;
    datatype 'a frag = ANTIQUOTE of 'a | QUOTE of string
    - `a`;
    val it = [QUOTE "a"] : 'a frag list

Fix:
  Added (strSymbol "SMLofNJ") to quoteDcon and antiquoteDcon in parse/astutil.sml.
Test: bug1279.sml
Owner: dbm
Status: fixed in 109.32 [dbm, 9/12/97]
----------------------------------------------------------------------
Number: 1280
Title: structure sharing semantics
Keywords: modules, signatures, structure sharing
Submitter: Andrew Appel
Date: 9/16/97
Version: 109.31
System: -
Severity: major 
Problem: SML 97 semantics of structure sharing not implemented.
Code:
  signature INT = sig type t=int end
  structure ONE :> INT = struct type t=int end
  structure TWO :> INT = struct type t=int end
  functor F(structure A:INT   structure B:INT  sharing A=B) = struct end
  structure THREE=F(structure A=ONE structure B=TWO)
Transcript:
  Standard ML of New Jersey, Version 109.31, September 8, 1997 [CM&CMB]
  val it = () : unit
  - use "s3";
  [opening s3]
  s3:5.17-5.51 Error: structure sharing violation: A # B

  uncaught exception Error
    raised at: build/evalloop.sml:105.44-105.52
	       build/evalloop.sml:123.38
	       build/evalloop.sml:196.58
	       build/evalloop.sml:292.19-292.22
Comments:
Fix:
Test: bug1280.sml
Owner: dbm
Status: fixed in 109.32 [dbm]
----------------------------------------------------------------------
Number: 1281
Title:       Open in local-in-end can give "Compiler bug: PickMod: dontPickle"
Keywords:    compiler bug, local-in-end, open
Submitter:   Kjeld H. Mortensen <designCPN-support@daimi.aau.dk>
Date:        9/16/1997
Version:     109.31
System:      sparc-solaris2.5.1
Severity:    major
Problem:     source code below results in "Compiler bug: PickMod: dontPickle"
Code:        structure foo = struct val myfoo = 0 end;
             structure bar = struct val mybar =0 end;
             local open foo in open bar end;
Transcript:  Standard ML of New Jersey, Version 109.31, September 8, 1997
             - structure foo = struct val myfoo = 0 end;
             structure foo :
               sig val myfoo : int end
             - structure bar = struct val mybar =0 end;
             structure bar :
               sig val mybar : int end
             - local open foo in open bar end;
             Error: Compiler bug: PickMod: dontPickle
Comments:    The above example works fine with SML/NJ 109.30.
Fix:         
Test: bug1281.sml
Owner: dbm
Status: fixed in 109.32 [Zhong]
----------------------------------------------------------------------
Number: 1282
Title: sharing syntax not consistent with SML 97
Keywords: syntax, sharing, SML 97
Submitter: Dave MacQueen
Date: 9/18/97
Version: 109.31
System: -
Severity: minor 
Problem: 
  The syntax of sharing specs has changed in SML 97, and we are not
  implementing the new syntax at the moment.

  The old syntax allowed multiple sharing equations separated by
  "and", as in

    sharing A.B = C.D and type A.t = E.s = F.s and B = C.B

  (with the "type" keyword binding tighter than the "and").
  Also sharing constraints were a spec (which means that one could 
  occur at the beginning of a signature before any other specs).

  In the SML 97 grammar, sharing constraints are a spec modifier,
  so they apply to the sequence of contraints preceeding them.
  This means that they can't appear at the beginning of a signature
  (which wouldn't make sense anyway, since the paths refered to in
  the sharing equations have to be local to the innermost signature
  containing the sharing specs).

  Also, multiple sharing equations separated by "and" is not provided
  in SML 97, so the above example would have to be written as

    <preceding specs>
    sharing A.B = C.D
    sharing type A.t = E.s = F.s
    sharing B = C.B

Code:
  signature S =
  sig
    type t
    type u
    type v
    sharing type t = u and type u = v
  end;
Transcript:
Comments:
Fix: change grammar
Test: bug1282.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1283
Title: Representation exception raised during value pretty printing
Keywords: representation, pretty printing
Submitter: Kenneth Cline <Kenneth_Cline@silver.fox.cs.cmu.edu>
Date: 9/19/97
Version: 109.31+
System: - (sgi-irix)
Severity: major
Problem: 
  The following code causes the 109.31 compiler to raise an the
  Representation exception.

Code:
  type 'a queue = 'a list * 'a list;
  val empty : 'a queue = (nil, nil);

Transcript:
  <jhr@canna> /home/sml/Dev/jhr/109.x/bin/sml
  Standard ML of New Jersey, Version 109.32, September 15, 1997 [new runtime]
  - type 'a queue = 'a list * 'a list;
  type  'a queue = 'a list * 'a list
  - val empty : 'a queue = (nil, nil);

  uncaught exception in compiler: Representation
    raised at: boot/Unsafe/object.sml:65.19-65.33
	       print/ppobj.sml:354.20
	       print/ppobj.sml:354.20
	       print/ppobj.sml:354.20
	       util/pp.sml:554.6
	       build/evalloop.sml:194.58
Comments:
 [jhr, 9/19/97]
  Some more information: it appears that the pretty printer is calling
  Unsafe.Object.toTuple with an unboxed value.  Do you have any idea
  why that might be?
 [Zhong, 9/19/97]
  Yes, ([], []) is  a polymorphic record that when applied returns
  a pair of 0s in two general purpose registers (as records are always 
  flattened when returned as results) ---  the toTuple function is
  trying to cast a 0 into a tuple, thus the problem. 

  I can easily get the compiler to handle 

	val empty : 'a queue = (nil, nil);

  just as we deal with "val empty = (nil, nil);"

Fix:
Test: bug1283.sml
Owner: jhr, Zhong
Status: fixed in 109.32 [Zhong, 9/22/97]
----------------------------------------------------------------------
Number: 1284
Title:       bogus file created upon aborted run of ml-lex
Keywords:    ml-lex, CM
Submitter:   Matthias Blume, blume@cs.princeton.edu
Date:        Sun Sep 28 12:24:15 EDT 1997
Version:     109.31
System:      all
Severity:    minor
Problem:

ML-Lex creates its output file (<name>.lex.sml) too early.  If the Lex
specification has errors that force ml-lex to quit, then there will be
a new, empty SML output file.  If the programmer overlooks the error
and runs CM.make() again, then CM will mistakenly assume that
<name>.lex.sml is up-to-date, because it is younger than
<name>.lex. Therefore, under these circumstances, ml-lex will not be
invoked again.  Empty ML source files are legal, though. This causes
an error message down the line when structure Mlex (or equivalent) is
not found.

Code:        Any syncatically incorrect ML-Lex specification that is
	     used as part of a CM-managed project.

Transcript:  
Comments:    I could hack CM to cope with this problem (for example by
removing the bogus output file when ml-lex returns with an exit status
other than 0).  But I think the problem should be solved at its
origin.

Fix:

*** lexgen.sml.orig     Sun Sep 28 12:44:11 1997
--- lexgen.sml  Sun Sep 28 12:45:26 1997
***************
*** 1257,1267 ****
--- 1257,1269 ----
               parse() handle x =>
                          (close_ibuf(!LexBuf);
                   TextIO.closeOut(!LexOut);
+                  OS.FileSys.remove outfile;
                   raise x)
           val (fins,trans,tctab,tcpairs) = makedfa(rules)
           val _ = if !UsesTrailingContext then
                      (close_ibuf(!LexBuf);
                       TextIO.closeOut(!LexOut);
+                      OS.FileSys.remove outfile;
                       prErr "lookahead is unimplemented")
                   else ()
        in

Test: *
Owner: Andrew, Matthias
Status: fixed in 109.32+
----------------------------------------------------------------------
Number: 1285
Title: Compiler bug: LtyEnv: unexpected tycs in tcWhNorm-TC_PROJ
Keywords: modules, functors, higher-order functors
Submitter: Andrew Appel
Date: 10/2/97
Version: 109.32-
System: -
Severity: critical
Problem: Example functor code from MacQueen/Tofte paper on higher
  order functor fails with
 
    Compiler bug: LtyEnv: unexpected tycs in tcWhNorm-TC_PROJ
Code:(* bug1285.sml *)
  signature POINT =
  sig 
    type point
  end;

  signature INTERVAL =
  sig
    type point
    val mk : point * point -> unit
  end;

  functor Interval(P: POINT) : INTERVAL =
  struct
    type point = P.point
    fun mk(x,y) = ()  (* <=== culprit is the pair (x,y) *)
  end;

  structure IntPoint : POINT =
  struct
    type point = int
  end;

  functor G(functor Interv(P: POINT) : INTERVAL) =
  struct
    structure NatNumInt = Interv(IntPoint)
  end;

Transcript:
  - use "test/mods/270.sml";
  [opening test/mods/270.sml]
  signature POINT =
    sig
      type point
      val <= : point * point -> bool
    end
  signature INTERVAL =
    sig
      type interval
      type point
      val mk : point * point -> interval
      val left : interval -> point
      val right : interval -> point
    end
  functor Interval : <sig>
  structure IntPoint : POINT
  structure T : INTERVAL
  val test = 9 : T.point
  Error: Compiler bug: LtyEnv: unexpected tycs in tcWhNorm-TC_PROJ
  - 
Comments:
Fix: changes to basics/ltyenv.sml and modules/instantiate.sml
Test: bug1285.sml
Owner: Zhong
Status: fixed in 109.32 [Zhong, 10/3/97]
----------------------------------------------------------------------
Number: 1286
Title:       Flexible records and as patterns
Keywords:    
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        10/7/97
Version:     109.32
System:      x86-linux
Severity:    minor
Problem:     

I don't know if this is a bug, but it certainly was surprising to me.

The following program succeeds (this seems right) :

fun f() = let val {a,...} = g() in () end
and g() = {a = (), b = ()}

The following program does not type check (this seems wrong), although
the only difference from the above is the introduction of an as
pattern binding x.

fun f() = let val x as {a,...} = g() in () end
and g() = {a = (), b = ()}

The error message is the following:

Error: unresolved flex record
(can't tell what fields there are besides #a)

Code:        
  fun f() = let val x as {a,...} = g() in () end
  and g() = {a = (), b = ()}
Transcript:  
Comments:    
Fix:         
Test: bug1286.sml
Owner: dbm
Status: fixed in 110 [Zhong, 10/10/97]
----------------------------------------------------------------------
Number: 1287
Title:       SML'97 scoping restrictions on local datatypes
Keywords:  type checking, local datatypes
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        10/7/97
Version:     109.32
System:      Alpha, Digital Unix 4.0
Severity:    Minor
Problem:     Code in section G.7 of Revised Defn elaborates;
it                       shouldn't
Code:        (from Defn)
  val a = let datatype t = C in C end;
  val b = fn x => let datatype t = C
		      val _ = if true then x else C
                   in 5 end;
Transcript:  
  val a = C : ?.t
  val b = fn : ?.t -> int

Comments:    Bug not really a problem: just language pedantry.
Fix:         Implement side-conditions on rules 4, 14, 26 of Defn
Test: bug1287.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1288
Title: readDir returns "." and ".."
Keywords: input/output, directories, OS.FileSys
Submitter: John Reppy
Date: 10/7/97
Version: 109.32
System: -
Severity: minor 
Problem: 
  our implementation of readDir returns "." and "..".  I believe
  that the latest version of the spec says that these are filtered
  out of the stream.
Comments:
  the basis spec is a bit unclear on this --- for Posix.FileSys.readDir,
  it specifies this behavior, but not for OS.FileSys.readDir.
Fix:
Test:
Owner: jhr
Status: fixed in 110
----------------------------------------------------------------------
Number: 1289
Title: readDir and rewindDir raise the wrong exception on closed dir stream
Keywords: input/output, directories, OS.FileSys
Submitter: John Reppy
Date: 10/7/97
Version: 109.32
System: -
Severity: minor 
Problem: 
   readDir and rewindDir raise the wrong exception when the directory
   stream is closed:

        - readDir dstr;

        uncaught exception Fail: readdir on closed directory stream
          raised at: boot/Posix/posix-filesys.sml:72.10-72.51
        - rewindDir dstr;

        uncaught exception Fail: rewinddir on closed directory stream
          raised at: boot/Posix/posix-filesys.sml:76.10-76.53
        - closeDir dstr;

   These should raise OS.SysErr.
Comments:
Fix:
Test:
Owner: jhr
Status: fixed in 110
----------------------------------------------------------------------
Number: 1290
Title: OS.FileSys.fullPath raises exception on symbolic link
Keywords: input/output, directories, OS.FileSys
Submitter: John Reppy
Date: 10/7/97
Version: 109.32
System: -
Severity: minor 
Problem: 
  OS.FileSys.fullPath is raising an exception when applied to what
  seems to be an okay symbolic link.

	uncaught exception SysErr: No such file or directory [noent]
	  raised at: <stat.c>
	             boot/Unix/os-filesys.sml:78.39-78.41

  The function realPath has the same problem.
Comments:
  This was a bug in the run-time system (same bug as 1291).
Fix:
Test:
Owner: jhr
Status: fixed in 110.
----------------------------------------------------------------------
Number: 1291
Title: OS.FileSys.readLink returns bogus results
Keywords: input/output, directories, OS.FileSys
Submitter: John Reppy
Date: 10/7/97
Version: 109.32
System: -
Severity: minor 
Problem: 

    <jhr@vex> ls -l testlink
    lrwxrwxrwx   1 george          6 Mar 12  1997 testlink -> README

    - readLink "testlink";
    val it = "testli" : string

Comments:
  This was a bug in the run-time system (same bug as 1290).
Fix:
Test:
Owner: jhr
Status: fixed in 110
----------------------------------------------------------------------
Number: 1292
Title: val rec (fun) should be able to rebind constructor id
Keywords: type checking
Submitter: Dave MacQueen
Date: 10/8/97
Version: 109.32
System: -
Severity: minor 
Problem: 
  val rec or fun declarations fail if the identifier being bound is
  a constructor name.  This should be allowed according to the 
  SML 97 Defn (p. 24, rule (26)).
Code:
Transcript:
  - datatype t = f; 
  datatype t = f
  - val rec f = fn x => x;
  stdIn:13.9-13.22 Error: rebinding data constructor "f" as variable
  - fun f x = x;
  stdIn:2.4-2.11 Error: rebinding data constructor "f" as variable

Comments:
Fix:
Test: bug1292
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1293
Title:       CharVector.mapi doesn't work with non-zero start index
Keywords:    Basis CharVector mapi
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        10/8/97
Version:     109.32
System:      Alpha, Digital Unix 4.0
Severity:    Minor
Problem:     CharVector.mapi always starts from index 0
Code:        
CharVector.mapi (fn (i, c) => (print (Int.toString i ^ "\n"); c))
("ABCDEFG", 2, SOME 3)

Transcript:  
0
1
2
val it = "ABC" : vector

Comments:    By the way, CharVector.{map,mapi} aren't documented             
  [jhr] Same bug occurs for Word8Vector.{map,mapi}.
Fix:         
Test: *
Owner: jhr
Status: fixed in 110.
----------------------------------------------------------------------
Number: 1294
Title:       Real.fromString accepts too much
Keywords:    Basis
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        10/8/97
Version:     109.32
System:      any
Severity:    Minor
Problem:     Real.fromString "1.e1" should return 1.0, since "1" is the longest
	     prefix of "1.e1" which can be parsed as a real (according to the
	     basis library specification).  New Jersey ML 109.32 returns "10.0".

Code:        
	Real.fromString "1.e1"

Transcript:  
	- Real.fromString "1.e1";
	val it = SOME 10.0 : real option

Comments:
Fix:         
Test: bug1294.sml
Owner: jhr
Status: fixed in 110.0.6
----------------------------------------------------------------------
Number: 1295
Title:       SMLofNJ.exportFn should complain about an empty name
Keywords:    exportFn runtime
Submitter:   Daniel C. Wang danwang@cs.princeton.edu
Date:        10/7/97
Version:     109.32 and probably all previous versions
System:	     Unix
Severity:    cosmentic
Problem:     

When you do an exportFn and pass it the empty string as the name of the heap
image it goes ahead and creates a heap named ".heap-suffix", which is a
hidden file in Unix and doesn't behave in a obvious way on a Unix system.

Code:	     SMLofNJ.exportFn("",fooFn);
Transcript:  
Comments:    
Fix:
  I've added code to raise SysErr when either exportML or exportFn is
  called with "" as the filename. [jhr, 10/10/97]
Test: *
Owner: jhr
Status: fixed in 110 [jhr, 10/10/97]
----------------------------------------------------------------------
Number: 1296
Title:       Datatype replication and signature matching.
Keywords:    modules, signatures, datatype replication
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:	     10/15/97
Version:     109.32
System:      x86-linux
Severity:    major
Problem:     

This bug is similar to 1255.  The following code is rejected by SML/NJ
with the following error message

Error: value type in structure doesn't match signature spec
    name: A
  spec:   ?.b -> ?.S.t
  actual: ?.b -> ?.S.t

Code:        

structure S : sig
		 datatype t = A of b
		 and b = B
		 structure T :
		    sig
		       datatype u = datatype t
		    end
	      end =
   struct
      datatype t = A of b
      and b = B
      structure T =
	 struct
	    datatype u = datatype t
	 end
   end

Transcript:  
Comments:    
Fix:         
  Have spec entVar be the same as formal tycon stamp in type specs.  Then
  use this fact to translate RECtycs to PATHtycs in the datacon domains
  introduced by datatype replication specs.
Test: bug1296.sml
Owner: dbm
Status: fixed in 110 [dbm, 10/16/97]
----------------------------------------------------------------------
Number: 1297
Title:       Compile time and space performance bug
Keywords:    image size, compilation time 
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        10/13/97
Version:     109.32
System:      x86-linux
Severity:    major
Problem:     

The following code requires 470 seconds to compile using CM and
produces a five megabyte bin file on my 200MhZ Pentium.  Furthermore,
the time and space seem to vary at least as bad as exponentially in
the size of the program.

Code:        

signature U =
   sig
      structure T : sig end
   end

signature V2 =
   sig
      structure T1 : sig end
      structure T2 : sig end
      structure T3 : sig end
      structure T4 : sig end
      structure T5 : sig end
      structure T6 : sig end
      structure T7 : sig end

      structure U1 : U where T = T1
      structure U2 : U where T = T2
      structure U3 : U where T = T3
      structure U4 : U where T = T4
      structure U5 : U where T = T5
      structure U6 : U where T = T6
      structure U7 : U where T = T6
   end
   
structure V2 :> V2 =
struct

structure T = struct end
structure T1 = T
structure T2 = T
structure T3 = T
structure T4 = T
structure T5 = T
structure T6 = T
structure T7 = T

structure U = struct structure T = T end
structure U1 = U
structure U2 = U
structure U3 = U
structure U4 = U
structure U5 = U
structure U6 = U
structure U7 = U

end

Transcript:  
Comments:    
 [Blume, 10/13/97]
  It must be a pickling problem then.  The toplevel compiler and the one
  called by CM are pretty much the same -- except the toplevel does not
  call the pickler anymore.  Incidentally, Manuel Fahndrich reported
  something that sounds similar (related to opaque matching and
  filtering).
 [dbm,10/15/97] Definitely a pickling blowup.  Here is the Stats summary
  after CM.make().

    Code Size                               632
    Pickle Bytes                            4732609
    Source Lines                            0
    Compiler 010 Parse                      0.00u  0.01s  0.00g  
    Compiler 030 Elaborate                  0.01u  0.00s  0.00g  
    Compiler 032 1-instParam                0.00u  0.00s  0.00g  
    Compiler 033 1-mapPaths                 0.00u  0.00s  0.00g  
    Compiler 033 5-transType                0.00u  0.00s  0.00g  
    Compiler 035 decType                    0.00u  0.00s  0.00g  
    Compiler 036 pickUnpick                 410.48u  23.09s  112.63g  
    Compiler 038 1-SCStatenv                2.92u  0.02s  0.91g  
    Compiler 040 Translate                  1.79u  0.57s  1.79g  
    Compiler 044 x-evalApp                  0.00u  0.00s  0.00g  
    Compiler 045 matchcomp                  0.00u  0.00s  0.00g  
    Compiler 047 reformat                   0.00u  0.00s  0.00g  
    Compiler 050 CodeOpt                    0.00u  0.00s  0.00g  
    Compiler 051 1-ltAppSt                  0.00u  0.00s  0.00g  
    Compiler 051 2-ltAppSt                  0.00u  0.00s  0.00g  
    Compiler 052 lcontract                  0.00u  0.00s  0.00g  
    Compiler 053 specLexp                   0.00u  0.00s  0.00g  
    Compiler 054 wrapLexp                   0.00u  0.00s  0.00g  
    Compiler 055 ltyComp                    0.00u  0.00s  0.00g  
    Compiler 056 ltNarrow                   0.00u  0.00s  0.00g  
    Compiler 057 lambdaopt                  0.00u  0.00s  0.00g  
    Compiler 058 reorder                    0.00u  0.00s  0.00g  
    Compiler 060 Convert                    0.01u  0.00s  0.00g  
    Compiler 065 CPStrans                   0.00u  0.00s  0.00g  
    Compiler 070 cpsopt                     0.00u  0.00s  0.00g  
    Compiler 079 freemapClose               0.01u  0.00s  0.00g  
    Compiler 080 closure                    0.00u  0.00s  0.00g  
    Compiler 090 globalfix                  0.00u  0.00s  0.00g  
    Compiler 100 spill                      0.00u  0.00s  0.00g  
    Compiler 110 limit                      0.00u  0.00s  0.00g  
    Compiler 120 cpsgen                     0.00u  0.00s  0.00g  
    Compiler 130 Schedule                   0.00u  0.00s  0.00g  
    Compiler 140 CodeGen                    0.00u  0.01s  0.00g  
    Execute                                 0.02u  0.11s  0.00g  
    Other                                   0.01u  0.00s  0.00g  
    TOTAL                                   415.24u  23.81s  115.33g  

   No blowup seen if the file is compiled with "use" (interactive
   top level, and "use", do not pickle).

Fix:         
Test: bug1297.sml
Owner: dbm, Zhong, Appel
Status: fixed in 110 [Appel, dbm, 10/17/97]
----------------------------------------------------------------------
Number: 1298
Title:       TransTypes: unexpected FORMAL kind in tycTyc-h
Keywords:    functors, CM
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        10/16/97
Version:     109.32
System:      Alpha, Digital Unix 4.0
Severity:    Major
Problem:
  fatal error in CM.make (it doesn't seem to happen with use)
  when compiling the following bunch of files.
Code: 
===============
(* sources.cm *)
Group is

F.sml
Test.sml
===============
(* F.sml *)

functor F(type Error) :> (* must be opaque constraint *)
sig
  datatype Result = Failure of Error  (* "type Result" won't do *)
  val run : Result -> unit
end =

struct
  datatype Result = Failure of Error
  fun run m = ()
end
===============
(* Test.sml *)

structure Test = F(type Error = string)

===============

Transcript:  
  Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM&CMB]
  val it = () : unit
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/sparc-unix/sources.cm.stable ... not usable]
  [parsing F.sml]
  [Creating directory CM/DEPEND ...]
  [parsing Test.sml]
  [dependency analysis completed]
  [compiling F.sml -> CM/sparc-unix/F.sml.bin]
  [Creating directory CM/sparc-unix ...]
  [wrote CM/sparc-unix/F.sml.bin]
  [compiling Test.sml -> CM/sparc-unix/Test.sml.bin]
  Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h

  uncaught exception Error
    raised at: util/errormsg.sml:54.14-54.19
	       translate/translate.sml:129.39
	       translate/translate.sml:129.39
	       util/stats.sml:164.40
	       sched/recompile.sml:206.38-206.41

Comments:    
 [Matthias, 10/16/97]
  This, again, seems to be pickling-related because the main difference
  between the top level and CM is now that the former doesn't pickle
  anymore.

Fix:         
Test: cmtests/bug1298
Owner: dbm, Zhong
Status: fixed in 110 [Zhong, 10/19/97]
----------------------------------------------------------------------
Number: 1299
Title: some error messages aren't being sent to stderr
Keywords: errors, printing, stderr
Submitter:      lorenz
Date:		10/16/98
Version:        109.32
System:         presumably all
Severity:       minor
Problem:        
  Not all error messages are being sent to stderr.

Transcript:     

$ /usr/local/sml/109.32/bin/sml 2>/dev/null
Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled]
- asdf;
stdIn:17.1-17.5 Error: unbound variable or constructor: asdf
- 
Comments:
 [jhr, 10/16/97]
  I think this is not a bug, but a feature.  Remember that SML/NJ
  is an interactive system, thus error messages are part of the
  basic dialogue with the user.
Fix:
Test: 
Owner: 
Status: open
----------------------------------------------------------------------
Number: 1300
Title: type printing of datacon domain
Keywords: printing, types
Submitter: Dave MacQueen
Date: 11/11/97
Version: 109.32+
System: -
Severity: medium 
Problem: Int32.int printed as ?.int32 in the domain of a dataconstructor.
  Similarly for Word32.word.
Code:
Transcript:
  Standard ML of New Jersey, Version 109.32, October 1, 1997 [new runtime]
  - 3: Int32.int;
  val it = 3 : Int32.int
  - datatype t = T of Int32.int;
  datatype t = T of ?.int32
Comments:
Fix:
Test: bug1300.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1301
Title: too big real literal yields uncaught exception BadReal
Keywords: real, literals
Submitter: Dave MacQueen
Date: 11/11/97
Version: 109.32+
System: sparc-solaris
Severity: medium
Problem: too big real literal yields uncaught exception BadReal
Transcript:
  - 1.0E309;

  uncaught exception BadReal
    raised at: bignums/realconst.sml:228.54-228.63
Comments:
Fix:
Test: bug1301.sml
Owner: Andrew
Status: open
----------------------------------------------------------------------
Number: 1302
Title: handling differing newline conventions across OSes
Keywords: strings, input/output
Submitter: Bob Harper (rwh@cs.cmu.edu)
Date: 10/10/97
Version: 109.32
System: -
Severity: medium 
Problem: 
  Would you please change the NJ lexer so that it ignores CR's in all cases? 
  For various reasons I'm having to move files back and forth between NT and 
  Unix.  Guess what?  Under NT lines are terminated by both CR and LF (belt 
  and suspenders).  If I copy from NT to Unix and run NJ on the file, I get 
  zillions of lexer errors because of the CR's.
Code:
Transcript:
Comments:
 [Matthias, 10/11/97] Suggested fix:
  *** ml.lex.old  Tue Aug 26 15:25:26 1997
  --- ml.lex      Sat Oct 11 12:56:03 1997
  ***************
  *** 78,85 ****
    %arg ({comLevel,sourceMap,err,charlist,stringstart,stringtype,brack_stack});
    idchars=[A-Za-z'_0-9];
    id=[A-Za-z]{idchars}*;
  ! ws=("\012"|[\t\ ])*;
  ! nrws=("\012"|[\t\ ])+;
    some_sym=[!%&$+/:<=>?@~|#*]|\-|\^;
    sym={some_sym}|"\\";
    quote="`";
  --- 78,85 ----
    %arg ({comLevel,sourceMap,err,charlist,stringstart,stringtype,brack_stack});
    idchars=[A-Za-z'_0-9];
    id=[A-Za-z]{idchars}*;
  ! ws=("\012"|"\013"|[\t\ ])*;
  ! nrws=("\012"|"\013"|[\t\ ])+;
    some_sym=[!%&$+/:<=>?@~|#*]|\-|\^;
    sym={some_sym}|"\\";
    quote="`";

 [jhr, 10/14/97]
  If we are going to fix this, then we should get the newline counting right
  for all conventions (text files on the Mac use #"\r" for end of line).
  Also, I think DOS machines use ^Z as EOF, which we probably also need to handle.

 [Matthias, 10/15/97]
  I thought that normally TextIO will handle such translations.  Bob was
  only asking that #"\r"s are ignored in the case that they shouldn't
  have been there in the first place (i.e., when reading a DOS file
  under Unix). Reading a DOS file under DOS or reading a Mac file under
  MacOS should never produce #"\r"s in the input stream, because TextIO
  will translate them away.  But this translation will not happen (at
  least not properly) if the file is transmitted in binary form to a
  different OS with different conventions.

 [jhr, 10/15/97]
  If you snarf a DOS text file to a Unix machine w/o translation, then
  you get #"\r" at the end of each line, and a #"^Z" at the end of
  the file.  This is the situation that Bob would like fixed.  If we are going
  to fix it, we should do it properly (it is more than just making #"\r"
  be whitespace).

Fix:
Test: -
Owner: jhr
Status: fixed in 110.6, 110.0.4
----------------------------------------------------------------------
Number: 1303
Title:       CM file problems: multiple access not detected
Keywords:    "CM", "dependency"
Submitter:   Wolfgang Reissenberger, reissenb@informatik.uni-stuttgart.de
Date:        10/23/97
Version:     1.09.32
System:      sparc-solaris2.5, x-86-linux
Severity:    minor
Problem:     In a hierarchy of files, structures in several files use
             the same signature lying in an extra file. When CM tries
             to compile these structures, multiple occurences of the
             signature seemed to be detected, although they stem from
             the same source, and the case is uncritical. But CM stops
             reporting an error.
Code:        attached as tar.gz file
Transcript:  Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled]
             - CM.make' "t.cm";
             [starting dependency analysis]
             [scanning t.cm]
             [checking CM/sparc-unix/t.cm.stable ... not usable]
             [scanning etc/s1.cm]
             [checking etc/CM/sparc-unix/s1.cm.stable ... not usable]
             [parsing etc/s1.sml]
             GC #0.0.0.0.1.2:   (10 ms)
             [Creating directory etc/CM/DEPEND ...]
             [parsing div/s.sig]
             [Creating directory div/CM/DEPEND ...]
             [scanning pp/s2.cm]
             [checking pp/CM/sparc-unix/s2.cm.stable ... not usable]
             [parsing pp/s2.sml]
             [Creating directory pp/CM/DEPEND ...]

             !* CM error: t.cm: signature S was imported from both div/s.sig and div/s.sig
             - 

Comments:    If the signature S is filtered off by etc/s1.cm and
             pp/s2.cm, the error disappears.

 [Blume]
  That is the _real_ bug.  Since using ../div/s.sig in two different
  sources is never legal, it should be reported regardless.

 [Matthias, 10/23/97]
  Well, it's a "feature", but one might call it a bug.  CM does not
  permit the same SML source file to be listed in two or more different
  CM files.  Unfortunately, this requirement is not actively enforced.

  You should put the signature into its own group or library.  The same
  group or library can be imported from by more than one client group.
  But every source should have a unique group/library that it belongs to.

Fix: 
Test: *
Owner: Blume
Status: fixed in 110 [Blume, 11/25/97]
----------------------------------------------------------------------
Number: 1304
Title:       Type printing of exceptions on top-level
Keywords:    types, value restriction
Submitter:   Kjeld H. Mortensen (designCPN-support@daimi.aau.dk)
Date:        10/26/1997
Version:     109.32
System:      sparc-solaris2.5
Severity:    minor
Problem:     Raising exceptions on top-level results in a type error message
Code:        raise Overflow;
Transcript:
  Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled]
  - raise Overflow;
  stdIn:17.1-17.15 Error: nongeneralizable type variable
    it : 'Z
Comments:    Works fine in release 0.93
Fix: 
  Print warning instead of error message, with nongeneralized variables
  instantiated to fresh dummy types named X1, X2, ...
Test: -
Owner: dbm
Status: fixed in 110 [dbm, 11/3/97]
----------------------------------------------------------------------
Number: 1305
Title: translation of newlines in TextIO
Keywords: input/output, TextIO
Submitter: Dave Berry <daveb@harlequin.co.uk>
Date: 10/28/97
Version: 109.32
System: x86-win32
Severity: major
Problem: 
  We've just received a bug report from someone who is comparing
  MLWorks and SML/NJ for Windows 95.  He reports that
	  TextIO.output1(outstream, Char.chr 10)
  behaves differently on the two systems!  SML/NJ outputs a
  single ASCII newline character.  MLWorks outputs a carriage return
  and newline pair.  This is causing him problems.  We've told
  him to use BinIO instead.

  Clearly someone has misunderstood something.  The Basis Library
  is supposed to avoid problems of this kind.  I thought TextIO was
  supposed to map newline characters to <CR,LF> pairs -- am I
  mistaken?  Or have the people who ported SML/NJ to Windows 95
  made a mistake?
Code:
Transcript:
Comments:
 [jhr, 10/28/97]
  I guess that this is our bug.  My understanding is that the TextPrimIO
  structure is responsible for implementing new-line translation.  Note
  that this means that reading from a string does not do translation, and
  should be portable.
Fix:
Test:
Owner: Lorenz 
Status: fixed in 110
----------------------------------------------------------------------
Number: 1306
Title:       Refutable patterns and generalization
Keywords:    Pattern, integer constant, generalization
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        10/31/97
Version:     109.32
System:      Alpha
Severity:    Minor
Problem:     Should see "Error: nongeneralizable type variable" when
             pattern is refutable; with integer constants we don't
Code:        val (5, x) = (5, [])
Transcript:
- val (5, y) = (5, []);
stdIn:1.2-107.7 Warning: binding not exhaustive
          ((5 : int),y) = ...
val y = [] : 'a list
-
Comments:    For language pedants only!
Fix:         Class special constants as refutable
Test: bug1306.sml
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1307
Title: Illegal escapes in strings not recognized
Keywords: strings lexer
Submitter: Riccardo Pucella   riccardo@research.bell-labs.com
Date: 11/05/97
Version: 109.32
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: minor
Problem:
An illegal escape character in a string will raise a
"unclosed string" error instead of a "illegal escape"
error.

Code:

Transcript:
Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled]
- "another simple \k test";
stdIn:17.1-17.18 Error: unclosed string
stdIn:17.24-17.26 Error: unclosed string

Comments:

Fix:

Test: bug1307.sml
Owner: ?
Status: open
----------------------------------------------------------------------
Number: 1308
Title:       uncaught exception Representation in Version 109.32
Keywords:    "pp.sml", "modules"
Submitter:   Olivier Danvy, danvy@brics.dk
Date:        11/12/97
Version:     109.32
System:      linux, SGI
Severity:    minor
Problem:     an error is raised when priting a result
Code:        
----------
(* bug1308.2.sml *)

signature STO =
sig
  type store
  val update : (store -> 'a) -> 'a
end;

signature COMP =
sig
  type 'a lift
  val rap : 'a -> 'a lift
  val uplift : ('b lift) -> 'b lift
end;

functor F (structure S : STO
	   structure C : COMP)
: sig
    val x : S.store C.lift
  end =
struct
  val x = C.uplift (S.update (C.rap: S.store -> S.store C.lift))
end;

structure Sto : STO =
struct
  type store = string list * int list
  fun update f = f (["x"],[0])
end;

structure CPS : COMP =
struct
  type 'a lift = ('a -> Sto.store) -> Sto.store
  fun rap (v: 'a) (k: 'a -> Sto.store) = k v
  fun uplift (f: 'a lift) (k: 'a -> Sto.store) = f k
end;

structure R =
  F (structure S = Sto
     structure C = CPS);

val s2' = R.x (fn x => x);

----------
Transcript:  
----------
Standard ML of New Jersey, Version 109.32, October 1, 1997 [new runtime]
- use "bug1308.2.sml";
[opening bug1308.2.sml]
signature STO =
  sig
    type store
    val update : (store -> 'a) -> 'a
  end
signature COMP =
  sig
    type 'a lift
    val rap : 'a -> 'a lift
    val uplift : 'a lift -> 'a lift
  end
functor F : <sig>
GC #0.0.0.0.1.3:   (0 ms)
structure Sto : STO
structure CPS : COMP
structure R : sig val x : store lift end

uncaught exception Representation
  raised at: boot/Unsafe/object.sml:65.19-65.33
             print/ppobj.sml:354.20
             print/ppobj.sml:354.20
             print/ppobj.sml:354.20
             print/ppobj.sml:354.20
             util/pp.sml:554.6

----------
Comments:    Evaluating "val s2' = ImpCPS'.C p2 (["x"],[0]) Ans'.k_init"
	     yields the error above, but evaluating
	     "val s2' = Ans'.k_init (["x"],[43]);"
	     yields "val s2' = VAL (["x"],[43]) : Ans'.answer"
	     without raising an error.

Fix:         
Test: bug1308.1.sml, bug1308.2.sml, bug1308.3.sml (segmentation fault)
      bug1308.4.sml, bug1308.5.sml (PPObj: switch: none of the datacons matched)
Owner: Zhong
Status: fixed in 110 [Zhong, 11/17/97]
----------------------------------------------------------------------
Number: 1309
Title:       SML/NJ not safe for space
Keywords:    safe for space, tail-call optimization, memory leak
Submitter:   Henry Cejtin, henry@research.nj.nec.com
Date:        11/20/97
Version:     109.29
System:      Linux
Severity:    major
Problem:
The  following  two  programs  should  both  run  in  constant space but each
requires an unbounded amount of space.

Code:
        fun noop1 x = x;

        fun f (x: int, y: int): int*int = (y, x);

        fun spin1 (f: int*int -> int*int) = spin1 (noop1 f);

        fun noop2 x = x;

        fun spin2 (): int*int = noop2 spin2 ();

Transcript: Either of the following starts a non-terminating computation
	(which is correct) which uses an unbounded amount of space (which is
	incorrect).

		spin1 f;

		spin2 ();

Comments:

From  looking  at  the  generated  assembler  code,  the  problem is that the
polymorphic identity function must get a procedure which takes  arguments  in
the  generic  place (a single tuple) and returns results in the generic place
(again, a tuple), but the f function  takes  them  spread  in  registers  and
returns  them  the  same  way.   Thus  inside  spin1, f is first wrapped in a
procedure to make it obey the generic calling convention.  As a  result,  the
argument  to  spin grows bigger and bigger (and would be slower and slower if
used) on each iteration.  If you replace the definition of noop1 with
        fun noop1 (x: int*int -> int*int) = x;
then it runs in constant space.

A slightly more subtle problem with the wrapping code is that it  causes  the
procedure that was wrapped to be called from a non-tail position, even if the
result of the wrapping is called from a tail position.  This is what causes
        spin2 ();
to require unbounded space.

Again, if you replace noop2 with the type-specific version
        fun noop2 (x: unit -> int*int): unit -> int*int = x;
or you change the type of spin2 from
        uint -> int*int
to
        uint -> int
then it runs in constant space.

Note, this is really what was going on in bug number 1193.  In  that  report,
the code did
        handlers := ! handlers
where  handlers  was a ref cell holding a procedure.  What was going on there
was that the code was de-referencing handlers and then wrapping the result to
get  a  non-generic-calling-convention version of the procedure, and then was
wrapping that to convert it  back  to  a  generic-calling-convention  version
before  storing  it.   The  `fix'  seems to have been to make the cpsopt pass
smart enough to see that this pair of wrappers cancel and to eliminate  them.
This  fix  clearly  isn't sufficient since in either of the above cases which
fail, if noop1 and noop2 are unknown procedures, you are  going  to  have  to
wrap  the  argument  one  way,  and  then  wrap  the  result the inverse way.
Besides, as the second bad case shows, you can't wrap a procedure  to  change
the  way  it  delivers its results and preserve tail-call optimization (since
this really involves wrapping the continuation of the call).  It seems to  me
(definitely  quite unenlightened about SML/NJ) that this scheme just can't be
made to be safe for space.  Even if you believe that  the  identity  function
doesn't  have to return an object the same size as that which it was given as
an argument, wrappers that have  to  do  things  AFTER  the  procedure  being
wrapped returns are going to violate tail-call optimization.

If there are only a few calling conventions, then you can get away with using
a code pointer that knows how to  handle  the  generic  one  and  any  others
(essentially  by  having multiple entry points, either by using multiple code
pointers, or fixed offsets from `the'  code  pointer).   For  more  than  one
return convention you have to do the same thing with continuations.

Test: -
Owner: Zhong, Andrew
Status: open
----------------------------------------------------------------------
Number: 1310
Title: ML-Yacc fails to accept double backslash strings in .grm file
Keywords: ML-Yacc, parser, backslash
Submitter: Richard Boulton   rjb@dai.ed.ac.uk
Date: 11/20/97
Version: 109.32
System: Sparc SunOS 4.1.3_U1
Subsystem: ML-Yacc
Severity: minor
Problem:
ML-Yacc does not appear to correctly parse embedded ML code in the .grm
file when it contains literal strings in which two backslashes are used
to represent one backslash character.

Code:

%%

%name Bug
%term BSLASH | EOF
%nonterm start of bug
%pos Integer.int
%eop EOF
%noshift EOF
%pure
%verbose
%start start

%%

start : BSLASH (Bug "\\")

Transcript:
bug.grm, line 16: Error: unclosed string
bug.grm, line 16: Error:  eof encountered in action beginning here !
bug.grm, line 17: Error: syntax error found at EOF
? ml-yacc: uncaught exception ParseError

Comments:

Fix:
Test: 
Owner: Andrew, John, Emden?
Status: open
----------------------------------------------------------------------
Number: 1311
Title: odd secondary typing error after incorrect datatype decl
Keywords: typing
Submitter: John Reppy
Date: 11/19/97
Version: 109.32+
System: -
Severity: minor 
Problem: 
  After an improper datatype declaration containing free type
  variables on the rhs, but no type variable formal parameters on the
  lhs, an odd type error results involving UBOUND type variables.
Code:
  (* bug1311.sml *)

  structure A =
  struct
    datatype t = C of ('a * 'a)
    fun f (cons, C(x,y)) = C(cons x, cons y)
  end;
Transcript:
  - use "rbug.sml";
  [opening rbug.sml]
  rbug.sml:3.3-3.30 Error: unbound type variable in type declaration: 'a
  rbug.sml:4.27-4.43 Error: operator and operand don't agree [UBOUND match]
    operator domain: 'a
    operand:         'a
    in expression:
      cons y

Comments:
Fix: 
Test: bug1311.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1312
Title: CM.autoloading always returns false
Keywords: CM, autoloading
Submitter: Dave MacQueen
Date: 11/22/97
Version: 109.33
System: -
Severity: minor 
Problem: CM.autoloading always returns false, even after 
  "CM.autoloading (SOME true)" is executed.
Transcript:
  - CM.autoloading NONE;
  val it = false : bool
  - CM.autoloading (SOME true);
  val it = false : bool
  - CM.autoloading (SOME false);
  val it = false : bool
  - CM.autoloading (SOME true);
  val it = false : bool
  - CM.autoloading NONE;
  val it = false : bool
  - CM.autoloading (SOME false);
  val it = false : bool
  - CM.autoloading NONE;
  val it = false : bool
Comments:
Fix:
Test: -
Owner: dbm
Status: fixed in 110 [Matthias, 11/23/97]
----------------------------------------------------------------------
Number: 1313
Title: CM autoloader doesn't cope with <returnStr>.<resultStr>
Keywords: CM, autoloader, modules, functors
Submitter: Dave MacQueen
Date: 11/22/97
Version: 109.33
System: -
Severity: major 
Problem: CM autoloader doesn't cope with <returnStr>.<resultStr>
Code: (run in sml-cm)
  M.autoloading (SOME true);
  signature S = sig end;
  functor Foo (X:S) (Y:S) = X;
  structure C = Foo(struct end);

Transcript:
  - CM.autoloading (SOME false);
  val it = false : bool
  - signature S = sig end;
  signature S = sig end
  - functor Foo (X:S) (Y:S) = X;
  functor Foo : <sig>
  - structure C = Foo(struct end);
  stdIn:27.11-27.30 Error: structure C defined by partially applied functor
  - CM.autoloading (SOME true);
  val it = false : bool
  - signature S = sig end;
  signature S = sig end
  - functor Foo (X:S) (Y:S) = X;
  functor Foo : <sig>
  - structure C = Foo(struct end);
  <toplevel loop>: Undefined structure <resultStr> in path <returnStr>.<resultStr>
  stdIn:30.11-30.30 Error: structure C defined by partially applied functor
  - 
Comments:
 [dbm, 11/22/97]
  The message is generated in the function "lookup_path" in the function
  imports in cm/analysis/imp-exp.sml.  It seems that the CM syntax analysis
  used in the autoloader is not taking account of the introduction of
  <returnStr> and <resultStr> in the parsing of functor declarations
  (see AstUtil.fctRes, AstUtil.fsigRes, and AstUtil.fappRes and their use
  in parse/ml.grm.).  I think the main CM dependency analysis does take these
  derived forms into account.
 [Matthias, 11/22/97]
  CM doesn't know that <returnStr> etc. are special.  I would prefer if
  they weren't. Manuel Fahndrich has recently requested this hack to be
  eliminated from the parser (e.g., moved into the elaborator).  I 100%
  agree with him.  This would solve the problem at the root.
Fix: moved the <resultStr>, <returnStr> translations of functor declarations
  and functor application strexps to the elaboration phase.
Test: testing/modules/tests/262.sml
Owner: dbm, Matthias
Status: fixed in 110 [dbm, 11/23/97]
----------------------------------------------------------------------
Number: 1314
Title:       ml-burg loops on invalid character in input file
Keywords:    ml-burg ml-lex exceptions
Submitter:   manuel@cs.berkeley.edu
Date:        11/23/1997
Version:     109.31 and 109.32
System:	     sparc-solaris2.5
Severity:    minor
Problem:     
ml-burg loops on input files containing invalid characters.

Code:
% ml-burg test.burg
or

CM.make ();  (* in sml-109.32/src/ml-burg *)
doit "test.burg";

where test.burg contains the single character '@'.

Transcript:

Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled]
- OS.FileSys.getDir();
val it = "/disks/orodruin/aa/projects/sml-109.32/src/ml-burg" : string
- CM.make ();
[starting dependency analysis]
[scanning sources.cm]
[checking CM/sparc-unix/sources.cm.stable ... not usable]
[scanning ../smlnj-lib/Util/sources.cm]
[checking ../smlnj-lib/Util/CM/sparc-unix/sources.cm.stable ... ok - stable]
[scanning ../ml-yacc/lib/sources.cm]
[checking ../ml-yacc/lib/CM/sparc-unix/sources.cm.stable ... ok - stable]
[dependency analysis completed]
[recovering ../smlnj-lib/Util/CM/sparc-unix/hash-string.sml.bin... done]
[recovering ../smlnj-lib/Util/CM/sparc-unix/hash-key-sig.sml.bin... done]
[recovering ../smlnj-lib/Util/CM/sparc-unix/hash-table-rep.sml.bin... done]
[recovering ../smlnj-lib/Util/CM/sparc-unix/mono-hash-table-sig.sml.bin... done]
[recovering ../smlnj-lib/Util/CM/sparc-unix/hash-table-fn.sml.bin... done]
[recovering CM/sparc-unix/burg-ast.sml.bin... done]
[recovering ../ml-yacc/lib/CM/sparc-unix/base.sig.bin... done]
[recovering ../ml-yacc/lib/CM/sparc-unix/join.sml.bin... done]
[recovering ../ml-yacc/lib/CM/sparc-unix/lrtable.sml.bin... done]
[recovering ../ml-yacc/lib/CM/sparc-unix/stream.sml.bin... done]
[recovering ../ml-yacc/lib/CM/sparc-unix/parser2.sml.bin... done]
[recovering CM/sparc-unix/burg-gram.sig.bin... done]
[recovering CM/sparc-unix/burg-gram.sml.bin... done]
[recovering CM/sparc-unix/errormsg.sml.bin... done]
[recovering CM/sparc-unix/burg-lex.sml.bin... done]
[recovering CM/sparc-unix/parse.sml.bin... done]
[recovering CM/sparc-unix/burg.sml.bin... done]
[recovering CM/sparc-unix/main.sml.bin... done]
[introducing new bindings into toplevel environment...]
val it = () : unit
- Main.doit "test.burg";

Interrupt

Comments:    Produces no output. Looking at the code, the LexError
	     exception should be raised, but it never does. I even
	     modified the source to generate a message before raising
	     LexError, and it is NOT printed.

	     May be a bug in the generated lexer.

	     (Under 109.31, ^C produces a segmentation violation.)


Fix:	     
Test: -
Owner: Lal
Status: open
----------------------------------------------------------------------
Number: 1315
Title: bogus value created (probably representation bug)
Keywords: modules, functors, opaque signatures
Submitter: Matthias Blume
Date: 11/23/97
Version: 109.33
System: -
Severity: critical (can cause core dump) 
Problem: bogus value created

Code:
  signature ASIG =
  sig
    type g
    type n
    type 'a t
    val newG: unit -> g
    val newN: g -> n
    val nodes: g -> n list
    val empty: 'a t
    val add: 'a t * n * 'a -> 'a t
    val look: 'a t * n -> 'a option
    val id: n -> string
  end;

  structure A :> ASIG =
  struct
    type g = (int * int list) ref
    type n = g * int
    type 'a t = (n * 'a) list

    fun newG () = ref (0, [])

    fun newN (g as ref (n, l)) = let
	val n' = n + 1
	val l' = n' :: l
	val _ = print (concat ["ID of new node is: ", Int.toString n', "\n"])
    in
	g := (n', l');
	(g, n')
    end

    fun nodes (g as ref (_, l)) = map (fn n => (g, n)) l
    val empty = []

    fun add (t, n, x) = (n, x) :: t

    fun look (t, (_, ni)) = let
	fun sameNode ((_, ni'), _) = ni = ni'
    in
	Option.map #2 (List.find sameNode t)
    end

    fun id (_, ni) = Int.toString ni
  end;

  signature BSIG =
  sig
    structure A : ASIG
    datatype t = B of { g: A.g, nstring: A.n -> string }
    val mk: string list -> t
  end;

  structure B : BSIG =
  struct
    structure A = A
    datatype t = B of { g: A.g, nstring: A.n -> string }

    fun mk sl = let
	val g = A.newG ()
	fun loop ([], t) =
	    let
		fun nstring n =
		    valOf (A.look (t, n))
		    handle e => let
			val _ = print "!!!! BOGUS exception... "
		    in
			print (concat ["node ID is: ", A.id n, "\n"]);
			raise e
		    end
	    in
		B { g = g, nstring = nstring }
	    end
	  | loop (s :: ss, t) = let
		val n = A.newN g
	    in
		loop (ss, A.add (t, n, s))
	    end
    in
	loop (sl, A.empty)
    end
  end

  (* -------------------------------------------------- *)
  (* structure C = 			(* scenario 1 *) *)
  functor C (B: BSIG) =		        (* scenario 2 *)
  struct
    structure A = B.A

    fun show (B.B { g, nstring }) =
	app (fn n => print (nstring n ^ "\n")) (A.nodes g)

  end

  structure C = C (B)			(* scenario 2 *)
  (* -------------------------------------------------- *)

  (* run the sucker... *)
  val test = C.show (B.mk ["a", "b", "c"])

Transcript:
  - use "bug1315.sml";
  [opening bug1315.sml]
  signature ASIG =
    sig
      type g
      type n
      type 'a t
      val newG : unit -> g
      val newN : g -> n
      val nodes : g -> n list
      val empty : 'a t
      val add : 'a t * n * 'a -> 'a t
      val look : 'a t * n -> 'a option
      val id : n -> string
    end
  structure A : ASIG
  signature BSIG =
    sig
      structure A :
	sig
	  type g
	  type n
	  type 'a t
	  val newG : unit -> g
	  val newN : g -> n
	  val nodes : g -> n list
	  val empty : 'a t
	  val add : 'a t * n * 'a -> 'a t
	  val look : 'a t * n -> 'a option
	  val id : n -> string
	end
      datatype t = B of {g:A.g, nstring:A.n -> string}
      val mk : string list -> t
    end
  ID of new node is: 1
  ID of new node is: 2
  ID of new node is: 3
  !!!! BOGUS exception... node ID is: 401

  uncaught exception Option
    raised at: boot/option.sml:17.25-17.31
	       b1315.sml:68.15
Comments:
 [Matthias, 11/24/97]  
  If you use the line
  commented as "scenario 1", then everything works fine (structure C
  uses B directly).  If you comment out that line and remove the comment
  brackets around those labelled "scenario 2", then you will find
  strange behavior.  The only difference between scenario 1 and 2 is
  than the latter uses structure B through a functor argument.

  Under 109.33 on an UltraSparc, scenario 1 reports (aside from
  its usual chattering about defined signatures and structures):

  .
  .
  .
  ID of new node is: 1
  ID of new node is: 2
  ID of new node is: 3
  c
  b
  a


  This is the expected behavior.  Under scenario 2 I get:

  .
  .
  .
  ID of new node is: 1
  ID of new node is: 2
  ID of new node is: 3
  !!!! BOGUS exception... node ID is: 433

  uncaught exception Option
    raised at: boot/option.sml:17.25-17.31
	       bug.sml:63.10


  Clearly, there should never be a node with ID = 433 (because only 3
  nodes are created total, and they are numbered 1, 2, 3).  Looks like a
  representation bug to me...
 [dbm, 11/24/97]
  The opaque signature constraint in the declaration of A is also necessary.

Fix: -
Test: bug1315.sml
Owner: Zhong
Status: open
----------------------------------------------------------------------
Number: 1316
Title:       type checker loops on incorrect function declaration
Keywords:    types
Submitter:   Anton Schwaighofer <schwaigi@sbox.tu-graz.ac.at>
Date:        11/26/97
Version:     109.32
System:      sparc-solaris
Severity:    major?
Problem:
When you forget the brackets in the pattern
  fun f x::xs = x+f(xs)
SML 109.32 will not bring the correct error messages, but try to allocate
larger and larger amounts of memory without ever stopping.
Code:        fun f x::xs = x+f(xs);
Transcript:
Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload
enabled]
- fun f x::xs = x+f(xs);
stdIn:17.8-17.10 Error: infix operator "::" used without "op" in fun dec
stdIn:17.5-17.22 Error: data constructor :: used without argument in pattern
GC #0.0.0.0.1.1:   (10 ms)
GC #0.0.0.1.2.19:   (510 ms)
GC #0.0.1.2.3.27:   (760 ms)
GC #0.1.2.3.4.45:   (3090 ms)
GC #1.2.3.4.5.53:   (4020 ms)
.... and so on
GC #5.19.20.21.22.279:   (19320 ms)
...
GC #5.27.28.29.30.383:   (1510 ms)
/disk7_1/software/sml109.32/bin/sml: Error -- unable to map 69599232 bytes,
errno = 11
/disk7_1/software/sml109.32/bin/sml: Error -- unable to allocate to-space
for generati
on 5; trying smaller size
GC #6.28.29.30.31.391:  ^C (26950 ms)
Interrupt
/disk7_1/software/sml109.32/bin/sml: Error -- unable to map 244711424 bytes,
errno = 11
/disk7_1/software/sml109.32/bin/sml: Error -- unable to allocate to-space
for generation 5; trying small
er size
GC #7.29.30.31.32.392:   (430 ms)
- 

Comments:
  sml 0.93 brings the correct error messages:
  Standard ML of New Jersey, Version 0.93, February 15, 1993
  val it = () : unit
  - fun f x::xs = x+f(xs);
  std_in:2.8-2.9 Error: NONfix pattern required
  std_in:2.5-2.21 Error: data constructor :: used without argument in
  pattern
  std_in:2.1-2.21 Error: pattern and expression in val rec dec don't agree
  (circularity)
    pattern:    'Z -> 'Z
    expression: 'Z -> 'Y -> 'Z -> 'Z
    in declaration:
      f = (fn arg => (fn <pat> => <exp>))
  std_in:2.16 Error: overloaded variable cannot be resolved: +

 [dbm,12/1/97]
  Simpler example that doesn't involve the bad syntax is (bug1316.2.sml)

    fun f x z = x+f(z);

Fix: In basics/unify.sml, added an occurence check when instantiating
  a SCHEME tyvar (in function adjustType).
Test: bug1316.1.sml, bug1316.2.sml, bug1316.3.sml
Owner: dbm
Status: fixed in 110 [dbm, 12/2/97]
----------------------------------------------------------------------
Number: 1317
Title:       Error: Compiler bug: EntityEnv: lookEP.1
Keywords:    functors, modules
Submitter:   Elsa L. Gunter, elsa@research.bell-labs.com
Date:        12/5/97
Version:     109.33
System:      x86 - Linux 2.0.0
Severity:    minor
Problem:
  A compiler error is generated when the compiler tries to
  make a structure from a functor that couldn't be defined
  because it's output signature was missing.

Code:
  functor F () : FSIG = struct end 
  structure C =  F ()

Transcript:
  Standard ML of New Jersey, Version 109.34, December 2, 1997
  val use = fn : string -> unit
  - use "test/bugs/bug1317.sml";
  [opening test/bugs/bug1317.sml]
  test/bugs/bug1317.sml:4.16-4.20 Error: unbound signature: FSIG
  Error: Compiler bug: EntityEnv: lookEP.1

Comments:
Fix: when structure binding signature constraint does not elaborate
 (elabSig returns ERRORsig), proceed as though there was no signature
 constraint.
Test: bug1317.sml
Owner: dbm
Status: fixed in 109.35 [dbm, 12/6/97]
----------------------------------------------------------------------
Number: 1318
Title: incorrect sigmatch error in higher-order functor
Keywords: modules, functors, higher-order functors, signature matching
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 12/10/97
Version: 110
System: -
Severity: major
Problem: 
  Signature match error message gives wrong type names while matching
  a the body of a higher order functor with a result constraint.
Code: (bug1318.1.sml)
  funsig FSIG(type info) = 
  sig
    type node
    type info
    type tree
    val f : node -> info
  end;

  functor FUN(functor F : FSIG):
  sig
    type info
    type node
    val g : node -> info
  end = 
  struct
    type info = int * bool
    structure S = F(type info = info)
    type node = S.node
    val g = S.f
  end;
Transcript:
  - use "bug1318.1.sml";
  [opening bug1318.1.sml]
  funsig FSIG(<param>: sig type info end) :
	     sig
	       type node
	       type info
	       type tree
	       val f : node -> info
	     end
  bug1318.1.sml:11.9-22.4 Error: value type in structure doesn't match signature spec
      name: g
    spec:   ?.node -> ?.info
    actual: ?.S.tree -> ?.S.info

 Expected the last line to be "actual: ?.S.node -> ?.S.info", i.e. the
 type of S.f. If we comment out "type tree" in the body of FSIG, we get
 another strange result:

  - use "bug1318.2.sml";
  [opening bug1318.2.sml]
  funsig FSIG(<param>: sig type info end) :
	     sig
	       type node
	       type info
	       val f : node -> info
	     end
  bug1318.2.sml:10.9-21.4 Error: value type in structure doesn't match signature spec
      name: g
    spec:   ?.node -> ?.info
    actual: ?.S.info -> ?.S.node

 In this case the actual type looks like the type of S.f with domain and
 range reversed.

Comments:
  If we strengthen the spec

    type info

  in the body of FSIG to be
  
    type info = info

  then the functor FUN elaborates successfully.
  However, if we then add the "type tree" specification to the body
  of FSIG (as in bug1318.4.sml), the elaboration of FUN fails again
  as follows

  - use "test/bugs/bug1318.4.sml";
  [opening test/bugs/bug1318.4.sml]
  funsig FSIG(<param>: sig type info end) :
	     sig
	       type node
	       type info = info
	       type tree
	       val f : node -> info
	     end
  test/bugs/bug1318.4.sml:12.9-23.4 Error: value type in structure doesn't match signature spec
      name: g
    spec:   ?.node -> ?.info
    actual: ?.S.tree -> ?.S.info


 [Bjorner, 12/11/97: workaround]
  I just got rid of the functor argument to the functor
  and named the two instances of TreeFUN the same. I needed
  it for compiling with two different environment (we are
  in the transition from one representation of Tree to another
  and want to compile both).

 [dbm, 12/13/97]
  The bug appears first in 109.32, with the introduction of the
  <resultStr>, <returnStr> transforms and the rewrite of
  modules/epcontext.sml.

Fix:
Test: bug1318.1.sml, bug1318.2.sml, bug1318.3.sml, bug1318.4.sml
Owner: dbm
Status: fixed in 110.0.1 [dbm, 12/15/97]
----------------------------------------------------------------------
Number: 1319
Title: Real.toManExp on Intel
Keywords: Real.toManExp Intel
Submitter: Henry Cejtin   henry@research.nj.nec.com
Date: 12/05/97
Version: 109.32
System: x86 Any Unix 
Subsystem: SML basis library
Severity: minor
Problem:
For reals near the maximum possible, Real.toManExp returns incorrect
answers.
Code:
  Real.toManExp (7.9 * 2e307)

Transcript:
  Standard ML of New Jersey, Version 109.32, October 1, 1997 [CM; autoload enabled]
  - Real.toManExp (7.9 * 2e307);
  val it = {exp=0,man=1.58e308} : {exp:int, man:real}

Comments:
  I would prefer these to give you the IEEE exponent and mantissa.
  I.e., no fancy stuff for denormalized numbers.

Fix:
Test: bug1319.sml
Owner: jhr, Andrew
Status: open
----------------------------------------------------------------------
Number: 1320
Title: path name syntax used by cm when compiling to x86
Keywords: CM, win32, file path syntax
Submitter: Lorenz Huelsbergen
Date: 12/9/97
Version: 110
System: -
Severity: minor
Problem: 
  When compiling for win32, cm places / (instead of \) in the filenames
  in the various text files that sit in the bin directory.  Currently we
  use a script to patch this.  (It's been applied to
  /usr/local/sml/110/bin.x86-win32/) Perhaps cm should emit \'s when
  x-compiling to win32.
Comments:
Fix: added new function writeFileName that does the right thing for 
  Windows.
Owner: Matthias
Status: fixed in 110.0.1 [Matthias, 1/10/98]
----------------------------------------------------------------------
Number: 1321
Title: printing of datatype = datatype in signatures
Keywords: pretty-printing
Submitter: John Reppy   jhr@research.bell-labs.com
Date: 12/10/97
Version: 110
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: cosmetic
Problem:
  The spec "datatype t = t" gets printed as "type t = t".
Code:
  signature S = sig datatype bool = datatype bool end;
Transcript:
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - signature S = sig datatype bool = datatype bool end;
  signature S = sig type bool = bool end

Comments:
Fix:
Test: bug1321.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1322
Title: Functor application causes "Compiler bug: LambdaType: wrong TCs in tc_select"
Keywords: modules, functors, functor application, lambda types
Submitter: Andrew Kennedy   Andrew.Kennedy@persimmon.co.uk
Date: 12/11/97
Version: 110
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: major
Problem:
A fairly straightforward functor application falls over. The code worked
in previous versions of the compiler. The bug occurs under both CM and
"use".
Code: (* bug1322.2.sml *)

  signature MONAD = 
  sig
    type 'a T
    val unit : 'a -> 'a T
  end;

  structure IdMonad =
  struct
    type 'a T = 'a
    fun unit x = x
  end;

  functor StMonad(structure Monad : MONAD type State) =
  struct
    fun read (s: State) = Monad.unit(s,s) (* unit arg must be a pair *)
  end;

  structure StMonad = StMonad(structure Monad = IdMonad type State = int);

Transcript:
  - use "bug1322.2.sml";
  [opening bug1322.2.sml]
  signature MONAD =
    sig
      type 'a T
      val unit : 'a -> 'a T
    end
  structure IdMonad :
    sig
      type 'a T = 'a
      val unit : 'a -> 'a
    end
  functor StMonad : <sig>
  Error: Compiler bug: LambdaType: wrong TCs in tc_select

Comments:
 [dbm,12/13/97]
  The failure occurred between 109.23 and 109.24, i.e. with the
  introduction of the Flint intermediate language and the new 
  module elaborator.
Fix:
Test: bug1322.1.sml, bug1322.2.sml
Owner: Zhong, dbm
Status: fixed in 110.0.1 [Zhong, 1/7/98]
----------------------------------------------------------------------
Number: 1323
Title: "uncaught exception RegMap" on hppa
Keywords: code generation, RegMap, GpregNum
Submitter: Martin Elsman <mael@diku.dk>
Date: 12/12/97
Version: 110
System: hppa-hpux, alpha32-dunix, sparc-solaris, mipseb-irix5
Severity: critical
Problem: 
  I'm in the process of porting the ML Kit with Regions to SML/NJ
  version 109.32. However, when compiling a fairly large functor (2889
  lines) SML/NJ crashes with the following error message:
Code: simplified test case from Andrew (* bug1323.sml *)
  functor F (
	type code 
	val boo : bool option option
	val funcs : bool list
      ) : sig end =
  struct
    fun reset() = ()   
    val _ = reset() 

    val pairId = fn (a,b) => (a,b)

    val boolref = ref false
    fun h (a,b) = if !boolref then (a,b) else (a,b)

    fun lookup () =
      case boo of
	 SOME(SOME b) => b
	| _ => false

    fun f1 C = if lookup () then pairId C else C

    fun f2 C = C

    fun f (x, C) = if x then f1 C else f2 C

    fun g (x::rest) = h(f(x, g rest))

    val uc: unit * code = g funcs

  end

Transcript: (Sparc SunOS 5.5.1, SML/NJ 110)

  % sml
  use "bug.sml";
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - [opening bug.sml]
  bug.sml:6.1-30.4 Warning: match nonexhaustive
	    x :: rest => ...

  GC #0.0.0.0.1.5:   (10 ms)

  uncaught exception GpregNum
    raised at: cps/generic.sml:76.26-76.34

Comments:

 [dbm, 12/16/97]
  Could it be an MLRISC code generation bug?  Fails in a similar way
  on alpha32-dunix:
    ...
    [wrote CM/alpha32-unix/COMP_LAMB.sml.bin]
    [compiling CompLamb.sml -> CM/alpha32-unix/CompLamb.sml.bin]
    GC #1.3.6.10.40.1323:   (117 ms)
    GC #1.3.6.11.41.1368:   (245 ms)
    ... LOTS of GC messages ...
    GC #4.50.61.81.121.3226:   (125 ms)
    GC #4.51.62.82.122.3242:   (407 ms)

    uncaught exception RegMap
      raised at: util/intmap.sml:28.41-28.44
		 util/stats.sml:164.40
		 util/stats.sml:164.40
		 sched/recompile.sml:206.38-206.41


  But it fails on sparc-solaris as well!
    ...
    [compiling CompLamb.sml -> CM/sparc-unix/CompLamb.sml.bin]
    GC #1.2.3.16.35.1300:   (50 ms)
    GC #1.2.3.17.36.1354:   (70 ms)
    ... lots of GC messages ...
    GC #3.20.26.52.105.2966:   (70 ms)
    GC #3.21.27.53.106.2999:   (80 ms)

    uncaught exception GpregNum
      raised at: cps/generic.sml:76.26-76.34
		 util/stats.sml:164.40
		 util/stats.sml:164.40
		 sched/recompile.sml:206.38-206.41

  and on mipseb-irix!

    [wrote CM/mipseb-unix/COMP_LAMB.sml.bin]
    [compiling CompLamb.sml -> CM/mipseb-unix/CompLamb.sml.bin]
    GC #0.0.1.4.18.553:   (204 ms)
    GC #0.0.1.5.19.590:   (353 ms)
    ....
    GC #3.9.23.37.53.1466:   (187 ms)
    GC #3.10.24.38.54.1470:   (272 ms)

    uncaught exception GpregNum
      raised at: cps/generic.sml:76.26-76.34
		 util/stats.sml:164.40
		 util/stats.sml:164.40
		 sched/recompile.sml:206.38-206.41

  On rs6000-aix (vasa) compilation died (killed by the OS?) before
  an error message occurred.

 [Andrew, 12/18/97]
  I've made the test case for bug 1323 even smaller.
  The following fails on the sparc:

  functor F (
	type code 
	val ? : bool
      ) : sig end =
  struct
    fun reset() = ()   
    val _ = reset() 
    val pairId = fn (a,b) => (a,b)
    fun f1 C = if ? andalso ? then pairId C else C
    fun f2 C = C
    fun f (a,b) = if ? then f1 (a,b) else f2 (a,b)
    fun g () = 
	  let val ((),b) = f((),g())
	   in if ? then b else b
	  end
    val u : code = g ()
  end

  Note:  this is not directly related to the bug, but might be an 
  opportunity for optimization:

  Interestingly, if f is made monomorphic then it compiles successfully.
  Even more interesting is that if I put "local ... in" around 
  the function up to (but not including) f, it fails, but if
  f is in the local part, it succeeds.  This leads me to believe
  that monomorphic instatiation is performed for "local" but not
  for top-level vals in structures, even if they are not exported
  through the signature of the structure.  Is that true?


 [Andrew, 12/18/97]
  Here's an even smaller test case for 1323. (bug1323.2.sml)

  Uncomment the commented code, and the error changes from "Gpregnum" to
  Error: Compiler bug: Contract: UsageMap on 299

  which proves that the error is at CPSopt or earlier -- I strongly
  suspect earlier.

  functor F (type code) : sig end =
  struct
    fun id x = x
    val () = id()
    fun f (a,b) = id id id (a,b)
    fun g () : code  = 
	  let val ((),b) = f((),g())
	   in (* id id *) b
	  end
    val u = g ()
  end

 [dbm, 1/7/98]
  Partially fixed by Zhong's changes of 1/7/98.  bug1323.1.sml and
  the original DIKU code now work on all architectures, bug bug1323.2.sml
  still fails on hppa and alpha.

Fix: 
Test: bug1323.1.sml, bug1323.2.sml, bug1323.3.sml
  (bug1323.tar.Z in dist/smlnj/working/bugs)
Owner: Andrew, Zhong
Status: open
----------------------------------------------------------------------
Number: 1324
Title:       Equality check in where type
Keywords: modules, signatures, include, equality types
Submitter:   Martin Elsman (mael@diku.dk)
Date:        12/16/1997
Version:     SML/NJ 110
System:      hppa-hpux
Severity:    major

Problem:     

 The following signature declaration should not elaborate; but it does
 in SML/NJ 110. In rule (64) the requirement 
    
    /\'a(k).\tau admits equality, if t does

 is not checked properly (I presume.)

Code:

 signature K = sig
   type s
   include sig eqtype t end where type t = s
 end

Transcript:

 mael@frej> sml110
 Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
 - use "eq.sml";
 [opening eq.sml]
 signature K =
   sig
     type s
     type t = s
   end
 val it = () : unit
 - 

Comments:
 In functors with many formal arguments it is important that equality
 attributes be propagated correctly, as the user otherwise may have
 difficulties using equality in functor bodies.

Fix:        
Test: bug1324.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1325
Title:		raises exception in compiler while trying to print error message
Submitter:	Andrew Koenig, ark@research.att.com
Date:		12/15/1997
Version:	110
System:		Sparc-SunOS-4.1.1
Severity:	minor (unless the problem is more pervasive)

Problem:
  I gave the compiler an expression that I did not expect to type-check,
  to see what diagnostic message would result.  The compiler raised an
  internal exception while trying to print the diagnostic message.

Code:
  val x = Posix.FileSys.openf("/etc/passwd", Posix.Filesys.O_RDONLY, 0);

Transcript:
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - val x = Posix.FileSys.openf("/etc/passwd", Posix.Filesys.O_RDONLY, 0);
  stdIn:16.44-16.66 Error: unbound structure: Filesys in path Posix.Filesys.O_RDONLY
  stdIn:16.1-16.70 Error: operator and operand don't agree [literal]
    operator domain: string * ?.POSIX_FileSys.open_mode * ?.POSIX_FileSys.O.flags
    operand:         string * _ * int
    in expression:
  uncaught exception nonexhaustive match failure
    raised at: print/ppval.sml:120.41
	       util/pp.sml:554.6
	       elaborate/elabmod.sml:1567.47
	       elaborate/elabmod.sml:1573.4

Comment:
  I expect the problem to be that the third argument to openf is
  expected to have type Posix.FileSys.O.flags, but I gave it an integer.
  How am I supposed to say that I don't want any of the flags, anyway?

Fix:        
Test: bug1325.sml
Owner: dbm
Status: fixed in 110.0.1 [dbm, 12/16/97]
----------------------------------------------------------------------
Number: 1326
Title: nonexhaustive match failure in pretty printer
Keywords: printing, absyn, error messages
Submitter: Ed Osinski   osinski@cs.nyu.edu
Date: 12/16/97
Version: 110
System: Sparc SunOS 4.1.4
Subsystem: SML compiler
Severity: minor
Problem:
Dies while reporting errors in program.
Code:
  fun f x _ = []
    | f x _ = let val y = g ()
	      in  1
	      end

Transcript:
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - use "bug.sml";
  [opening bug.sml]
  bug.sml:2.25 Error: unbound variable or constructor: g
  bug.sml:1.13-4.9 Error: types of rules don't agree [literal]
    earlier rule(s): 'Z * 'Y -> 'X list
    this rule: 'Z * 'Y -> int
    in rule:
  uncaught exception nonexhaustive match failure
    raised at: print/ppabsyn.sml:419.34
	       util/pp.sml:554.6
	       elaborate/elabmod.sml:1567.47
	       elaborate/elabmod.sml:1573.4

Comments:
  The initial error messages are correct; the problem is the "match 
  failure".  This seems to be the smallest code to demonstrate the 
  error.
Fix:

Test: bug1326.sml
Owner: dbm
Status: fixed in 110.0.1 [dbm, 12/17/97]
----------------------------------------------------------------------
Number: 1327
Title: tycStamp secondary error
Keywords: secondary error, elaboration, modules, functors
Submitter: Mikolaj Konarski <mikon@mimuw.edu.pl>
Date: 12/30/97
Version: 110
System: -
Severity: minor 
Problem: 
  An unbound structure id results in a "Compiler bug: TypesUtil: tycStamp
  ERRORtyc" secondary error message.
Code:
  signature S1 =
  sig
    datatype t = U               
  end;

  signature S2 =
  sig
    structure A : S1
    datatype u = U of A.t
  end;

  signature S3 =
  sig 
    structure B : S2
  end;

  functor F1 (structure X : S1
	      structure Y : S2 where A = X)
      :> S3 where B = Y
   =
  struct
    structure B = Y
  end;

  functor F2 () =
  struct
    structure D = F1(structure X = struct datatype t = U end
		     structure Y = Z)
  end;

Transcript:
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - use "bug.sml";
  [opening bug.sml]
  signature S1 = sig datatype t = U end
  signature S2 =
    sig
      structure A : sig datatype t = U end
      datatype u = U of A.t
    end
  signature S3 =
    sig
      structure B :
	sig
	  structure A : <sig>
	  datatype u = U of A.t
	end
    end
  functor F1 : <sig>
  bug.sml:28.20 Error: unbound structure: Z
  bug.sml:27.17-28.22 Error: unmatched structure specification: Y
  Error: Compiler bug: TypesUtil: tycStamp ERRORtyc

Comments:
Fix: added a check for ERRORtyc in function doElem in function mapEPC
  in elabmod.sml.
Test: bug1327.sml
Owner: dbm
Status: fixed in 110.1 [dbm, 1/6/97]
----------------------------------------------------------------------
Number: 1328
Title:       non-legal respecifications and redeclarations
Keywords: reserved identifiers, signature specs, val decls   
Submitter:   Martin Elsman (mael@diku.dk)
Date:        12/19/1997
Version:     SML/NJ 110
System:      -
Severity:    minor
Problem:  

  Neither the signature declaration, nor the declaration should
  elaborate due to syntactic restriction: No datdesc, valdesc or exdesc
  may describe true, false, nil, :: or ref. No datdesc or exdesc may
  describe it.

Code:

  signature S = sig
    val true : int
  end

  datatype t = it

Transcript:

  mael@frej> sml110
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - signature S = sig val true : int end;
  signature S = sig val true : int end
  - 
  - datatype t = it;
  datatype t = it
  - 

Test: bug1328.1.sml, bug1328.2.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1329
Title:       Problem with realisation in where type
Keywords:    realisation, where type
Submitter:   Martin Elsman (mael@diku.dk)
Date:        12/19/1997
Version:     SML/NJ 110
System:      -
Severity:    major
Problem:

  The signature declaration below should not elaborate (I believe) but
  does under SML/NJ 110; the reason it should not elaborate is that when
  applying rule (64) then \varphi does not have the property that
  arity(t) = arity(\varphi(t)), hence \varphi is not a realisation. *)

Code:

  signature S = sig
    datatype 'a t = A of 'a
  end where type 'a t = int

Transcript:

  mael@frej> sml110
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - use "sig2.sml";
  [opening sig2.sml]
  signature S = sig type 'a t = int end
  val it = () : unit
  - 

Comments: 

  It is not obvious what damage such signatures could do to generation
  of code for functor bodies.
 
 [dbm, 1/7/98]
  This is not a problem of arity mismatch, since the "where" definition
  of t is of arity 1 like the specification of t in the signature body.
  We should probably check that the definition of t is a datatype
  (more precisely: eta-reduces to a datatype) and that this datatype
  is "compatible" with the spec (same arity, same constructor names,
  ...?).

Fix:

  One needs to check that \varphi is indeed a realisation; this
  is done correctly for type sharing, that is, the following
  signature declaration fails to elaborate: 

  signature S = sig
    type u
    datatype 'a t = A of 'a
    sharing type u = t
  end

Test: bug1329.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1330
Title:       Problem with type abbreviations in signatures
Submitter:   Martin Elsman (mael@diku.dk)
Date:        12/19/1997
Version:     SML/NJ 110
System:      hppa-unix
Severity:    major
Problem:     

  None of the signature declarations below elaborates under SML/NJ
  though they should according to the Definition. I have partly reported
  this problem earlier but I don't think it was recognized as a bug - so
  here it is again..

Code:        

  signature S = sig
    type t
    type s = t
  end where type s = int

  signature S = sig
    type t
    type s = t
    sharing type t = s
  end

  signature S = sig
    type s
    structure U : sig
      type 'a t
      type u = (int * real) t
    end where type 'a t = s
  end where type U.u = int

Transcript: 

  mael@frej> sml110
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - use "sig2.sml";
  [opening sig2.sml]
  sig2.sml:4.1-7.23 Error: where type defn applied to definitional spec: s
  - 

  mael@frej> sml110
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - use "sig2.sml";
  [opening sig2.sml]
  sig2.sml:13.1-17.4 Error: dependency cycle in instantiate
  - 

  mael@frej> sml110
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  - use "sig2.sml";
  [opening sig2.sml]
  sig2.sml:23.1-29.25 Error: where type defn applied to definitional spec: U.u
  - 

Fix:

  Treat type abbreviations as a derived form as specified in the
  Definition, and the problems should go away.

Test: bug1330.1.sml, bug1330.2.sml, bug1330.3.sml
Owner: dbm
Status: not a bug
----------------------------------------------------------------------
Number: 1331
Title:  eXene example code out of date
Keywords: eXene, widgets, examples
Submitter: Scholz, Enno   scholz@inf.fu-berlin.de
Date: 01/04/98
Version: 109.32 AND 110
System: Sparc Solaris 
Subsystem: Installation
Severity: major
Problem:
When I run sml-cm in the directory 
/home/bwana/scholz/Sml/src/eXene/examples/widgets,
I get the following error:

simple-with-menu.sml:53.7-53.16 Error: unbound structure: CIO in path CIO.print
simple-with-menu.sml:53.33-53.43 Error: unbound variable or constructor: makestring
simple-with-menu.sml:58.21-58.35 Error: unbound structure: CIO in path CIO.input_line
simple-with-menu.sml:58.36-58.46 Error: unbound structure: CIO in path CIO.std_in
simple-with-menu.sml:36.25-36.60 Error: operator and operand don't agree [tycon mismatch]
  operator domain: OS.Process.status
  operand:         unit
  in expression:
    RunCML.shutdown ()
 
!* CM error: compile: elaboration failed

Code:
Transcript:
Comments:
 [dbm] Example code needs to be updated.
Fix:
Test: -
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1332
Title:	     signature mistakenly rejected
Keywords: modules, signatures, where structure, sharing 
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        1/7/98
Version:     110
System:      x86-linux
Severity:    minor
Problem:     
  In the following, the signature BUG is rejected, with:
  Error: possibly inconsistent structure definitions at: B.Z

Code:        

   signature SIG =
   sig
      structure Z : sig end
   end

   signature BUG =
   sig
      structure A : sig end
      structure B : SIG where Z = A
      structure C : SIG where Z = A
      sharing B = C
   end

Transcript:  
Comments:    
Fix:         
Test: bug1332.sml
Owner: dbm
Status: open (not a bug?)
----------------------------------------------------------------------
Number: 1333
Title:       SML 110 CM sometimes keeps, sometimes drops top level defs
Keywords:    CM toplevel
Submitter:   Jeff Foster, jfoster@cs.berkeley.edu
Date:        1/12/98
Version:     110
System:      Sun Enterprise-5000 running Solaris 2.5.1
Severity:    minor
Problem:     When compiling a project using CM, top level definitions
	     are sometimes ignored and are sometimes compiled
Code:        Three files:

  (* sources.cm *)
  Group is
  top.sml
  util.sml

  ================
  (* util.sml *)
  structure Util =
  struct
    fun applyOpt f zero NONE = zero
      | applyOpt f _ (SOME x) = f x
  end

  ================
  (* top.sml *)

  fun parse filename =
      let val ind = TextIO.openIn filename
	  val {sourceMap,tree=result} = (GenFront.parse (ind, filename)
					 handle (Fail s) =>
					     (TextIO.closeIn ind;
					      raise Fail s))
	  val _ = TextIO.closeIn ind
      in
	  result
      end

  fun tc filename =
      let val p = parse filename
      in
	  app CType.declaration p
      end

Transcript:
  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload
  enabled]
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/sparc-unix/sources.cm.stable ... not usable]
  [parsing top.sml]
  top.sml:3.1-12.8: declaration not tracked by CM
  top.sml:14.1-18.8: declaration not tracked by CM
  [Creating directory CM/DEPEND ...]
  [parsing util.sml]
  [dependency analysis completed]
  [compiling util.sml -> CM/sparc-unix/util.sml.bin]
  [Creating directory CM/sparc-unix ...]
  [wrote CM/sparc-unix/util.sml.bin]
  [introducing new bindings into toplevel environment...]
  val it = () : unit

Comments:    Notice -- no error messages even though top.sml cannot
	     possibly compile.  Now if I make a simple change:

  (* top.sml *)

  structure A = TextIO                <---------------- added this

  fun parse filename =
      let val ind = TextIO.openIn filename
	  val {sourceMap,tree=result} = (GenFront.parse (ind, filename)
					 handle (Fail s) =>
					     (TextIO.closeIn ind;
					      raise Fail s))
	  val _ = TextIO.closeIn ind
      in
	  result
      end

  fun tc filename =
      let val p = parse filename
      in
	  app CType.declaration p
      end


It does the right thing now:

  Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload
  enabled]
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/sparc-unix/sources.cm.stable ... not usable]
  [parsing top.sml]
  top.sml:5.1-14.8: declaration not tracked by CM
  top.sml:16.1-20.8: declaration not tracked by CM
  [Creating directory CM/DEPEND ...]
  [parsing util.sml]
  [dependency analysis completed]
  [compiling util.sml -> CM/sparc-unix/util.sml.bin]
  [Creating directory CM/sparc-unix ...]
  [wrote CM/sparc-unix/util.sml.bin]
  [compiling top.sml -> CM/sparc-unix/top.sml.bin]
  top.sml:7.33-7.47 Error: unbound structure: GenFront in path
  GenFront.parse
  top.sml:19.6-19.23 Error: unbound structure: CType in path
  CType.declaration

  !* CM error: compile: elaboration failed

Comment:
  So top.sml is not being compiled if it doesn't export any module
  level names.  On the other hand, if the util.sml file is eliminated
  (from sources.cm), then top.sml does get compiled, and the error
  message about unbound structure Ctype is generated.

Fix:
  Probably CM should print a warning or message when a file like
  atom.sml will not be compiled, or when a file has no module-level
  declarations.
Test: -
Owner: Matthias, dbm
Status: fixed in 110.20 [Matthias]
----------------------------------------------------------------------
Number: 1334
Title:       problem with type checking abstype
Keywords:    abstype, type checking, sharing violation
Submitter:   Martin Elsman (mael@diku.dk)
Date:        01/14/1998
Version:     110.0.1
System:      hppa-hpux
Severity:    major
Problem:

   There is a problem with correctly propagation of type information
   through the with-part of an abstype-construct. The functor f below
   should propagate the type name associated with the type constructor t
   in the argument to the type name associated with the type constructor
   t in the result. 

Code:        

   signature A = sig type t end

   functor f (structure a : A) : A = struct abstype u = B with type t = a.t end end
   functor k (structure a : A
	      structure b : A
	      sharing type b.t = a.t) : A = struct type t = b.t end

   functor g (structure a : A) =
     struct
       structure b = f (structure a = a)
       structure c = k (structure a = a
			structure b = b)
     end

Transcript:

   mael@frej> sml-cm
   Standard ML of New Jersey, Version 110.0.1, January, 12, 1998 [CM; autoload enabled]
   - use "functors.sml";
   [opening functors.sml]
   functors.sml:12.19-13.24 Error: type sharing violation: b.t # a.t
   - 

Comments:    

   When I recognized the problem, I could easily lift the type
   declaration outside of the abstype-construct, to make the problematic
   module type-check.

Fix:
Test: bug1334.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1335
Title: nonexhaustive match failure in mips code generator
Keywords: mips, code generation
Submitter:      Lorenz Huelsbergen (lorenz@research.bell-labs.com)
Date:           1.13.98
Version:        110.0.1, 110, 109.35,...
System:         Mips/Irix, but not Sparc/Solaris
Severity:       critical
Problem:        CG exception
Code:           at MH, files in slocum:/usr/lorenz/tmp/mips-cg-bug.tar
Transcript:     

  $ uname -a
  IRIX slocum 5.3 11091811 IP19 mips
  $ /usr/local/sml/bin/sml-cm 
  Standard ML of New Jersey, Version 110.0.1, January, 12, 1998 [CM; autoload enabled]
  - CM.make ();

  ...

  asm.sml:2.5-824.8 Warning: match nonexhaustive
	    (lab as Label (_,offset),(relopt,r as ref NONE,line,section_pos),
	     entry_opt) => ...

  asm.sml:47.40-49.31 Warning: match nonexhaustive
	    (Byte,i) => ...
	    (HalfWord,i) => ...
	    (Word,i) => ...

  GC #0.0.0.1.5.125:   (54 ms)
  GC #0.0.0.1.6.140:   (44 ms)
  GC #0.0.0.1.7.151:   (82 ms)
  GC #0.0.0.1.8.165:   (75 ms)
  GC #0.0.0.2.9.187:   (144 ms)
  GC #0.0.0.2.10.213:   (20 ms)

  uncaught exception nonexhaustive match failure
    raised at: mips/mips.sml:790.39
	       util/stats.sml:164.40
	       util/stats.sml:164.40
	       sched/recompile.sml:206.38-206.41

Comments:
  seems to only affect mips
Fix: [Lal, 1/15/98]
  The problem was that in the function 'ibranch' it is necessary to
  implement signed comparisons on 32-bit word values. This problem
  affects both the mips and rs6000. The files affected are: 
  mips/mips.sml and rs6000/rs6000.sml.
Test: bug1335.sml
Owner: Lal
Status: fixed in 110.0.2 [Lal, 1/14/98]
----------------------------------------------------------------------
Number: 1336
Title: Alarming "Approximating!" message
Keywords: messages
Submitter: Andrew Kennedy   andrew@persimmon.co.uk
Date: 01/13/98
Version: 109.32, 110.0.7
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: cosmetic
Problem:
  The message "Approximating!" is displayed during compilation. I don't
  think that this is a bug but it's rather an alarming message 
  (approximating what? the semantics of my program?). 

Code: (from Allen Stoughton, 2/1/2001)
fun f x =
      let fun g y =
                let fun h _ =
                            if x = y orelse x = y orelse x = y orelse x = y
                              then x = y
                            else if x = y
                              then f(x + 1)
                            else if x = y
                              then g(x + 1) 
                            else if x = y
                              then h(x + 1)
                            else true
                in h 0 end 
      in g 0 end;

Transcript: (110.0.7)

  Approximating! 408 409
  val f = fn : int -> bool

Comments:
 [Matthias, 2/1/2000]
  This "bug" has recently been "fixed" (by me) -- there is no such
  message generated by the feedback-new.sml module which replaced
  feedback.sml.  (The quotation marks are there to indicate that
  the thing was not really a bug, and that I did not really fix
  anything.  I just cleaned up the code.)

Fix: commented out diagostic message in src/sml-nj/util/feedback.sml file
 in 110.0.x.  Also commented out in src/compiler/MiscUtil/util/feedback.sml
 in 110.32+, but this version seems to be using feedback-new.sml instead
 of feedback.sml (which should therefore be discarded/renamed).
Test: bug1336.1.sml
Owner: Lal
Status: fixed in 110.33 and 110.0.8
----------------------------------------------------------------------
Number: 1337
Title: exporfFn in CML produces large images
Keywords: exportFn, CML
Submitter: John Reppy
Date: 
Version: 110.0.1 (but not 110.0)
System: all?
Severity: major
Problem: 
  Some change made to the compiler (or CM) causes the heap images
  exported by RunCML.exportFn to include the whole compiler.  This
  was not a problem in 110.  Furthermore, the CML code did not change
  between 110 and 110.0.1.
Code:
  (SMLofNJ.Internals.CleanUp.clean SMLofNJ.Internals.CleanUp.AtExportFn;
   Unsafe.CInterface.c_function "SMLNJ-RunT" "exportFn"
     ("hi", SMLofNJ.Cont.isolate (fn ()=>()) ))
Transcript:
Comments:
Fix:
  Replace an unnecessary casts in the definition of Isolate.isolate.
Test: -
Owner: jhr, Zhong, Andrew
Status: fixed in 110.0.2 [Appel, 1/14/98]
----------------------------------------------------------------------
Number: 1338
Title: uncaught Unbound while compiling MLKit
Keywords: 
Submitter: Martin Elsman <mael@diku.dk>
Date: 1/14/97
Version: 110.0.1
System: ?
Severity: critical 
Problem: 
  uncaught Unbound exception while compiling MLKit
Code: (bug1338.sml)
  signature SIG4 =
  sig
    structure S : 
      sig type t 
	  structure A: sig structure B : sig val x : t end
		       end
      end
    type s 
    type t = s 
    sharing type t = S.t
  end;

  functor F(X : SIG4) = struct end;

Transcript:
  mael@frigg> sml-cm
  Standard ML of New Jersey, Version 110.0.1, January, 12, 1998 [CM; auto...]
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/hppa-unix/sources.cm.stable ... not usable]
  [scanning Common/common.cm]
  ...
  [compiling Common/Execution.sml -> Common/CM/hppa-unix/Execution.sml.bin]
  GC #15.348.482.876.2224.58936:   (50 ms)
  ...
  GC #15.352.489.883.2251.59658:   (20 ms)

  uncaught exception Unbound
    raised at: translate/transmodules.sml:80.33-80.43
	       translate/translate.sml:129.39
	       util/stats.sml:164.40
	       sched/recompile.sml:206.38-206.41

Comments:
 [dbm, 1/14/98]
  The code in bug1338.1.sml actually should be illegal, because the type
  t in the sharing constraint in SIG4 is rigid because of the
  definitional type spec for t.  There is some controversy about
  this, though, since a loose interpretation of the Defn of SML 97 would
  treat t as flexible because the right hand side is a simple flexible
  type.  However, that interpretation is certainly not in the spirit of
  the revised definition, which is to eliminate interaction between
  definitional type specs and type sharing specs.
Fix:
Test: bug1338.1.sml
Owner: Zhong, dbm
Status: fixed in 110.0.2 [Zhong, 1/15/98]
----------------------------------------------------------------------
Number: 1339
Title: overstrict structure consistency checking in instantiate?
Keywords: modules, signatures, opaque signatures, instantiate
Submitter: Mikolaj Konarski <mikon@mimuw.edu.pl>
Date: 1/15/98
Version: 110.0.1
System: -
Severity: minor 
Problem: 
  Compiler complains about possibly inconsistent structure definitons
  when instantiating an opaque signature when one of the structures
  being defined is empty.
Code:
  signature CAT = sig end;

  signature L_F =
  sig
    structure Cat : CAT
  end;

  signature TRANSLATOR =
  sig 
    structure Cat : CAT
    structure LF : L_F where Cat = Cat
  end;

  functor Translator
      ( structure Cat : CAT
	structure LF : L_F ) :> (* with `:' here it goes through *) 
				TRANSLATOR
				     where Cat = Cat
				     where LF = LF
				     =
  struct
    structure Cat = Cat
    structure LF = LF
  end;

Transcript:
  - use "b1.sml";
  [opening b1.sml]
  signature CAT = sig end
  signature CAT = sig end
  signature L_F = sig structure Cat : sig end end
  signature TRANSLATOR =
    sig
      structure Cat : sig end
      structure LF : sig structure Cat : <sig> end
    end
  b1.sml:17.9-27.4 Error: possibly inconsistent structure definitions at: LF.Cat
Comments:
 [dbm, 1/15/98]
  This is really a borderline case, where one can argue either way.  The
  "abstract" result of the functor Translator is computed by
  instantiating the signature TRANSLATER after it is modified by the
  where definitions.  Since the agrument structures Cat and LF are now
  known, the compiler cannot tell whether the specification of LF in
  signature TRANSLATOR, including the definition of it's substructure
  Cat, is satisfied.  However, since in theory the structure definition
  clause is just an abbreviation for implied type definition clauses,
  and Cat has no type components, one can argue that here the where
  clauses defining Cat have no effect.

  If Cat contained a formal type spec, then there certainly would
  be a potential inconsistency, and the error message would be
  justified.

Fix: 
Test: bug1339.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1340
Title: Segmentation fault on Sparc, x86, Alpha, and MIPS
Keywords: seg fault, words, vectors
Submitter: Drew Dean   ddean@cs.princeton.edu
Date: 01/30/98
Version: 110.0.2
System: Sparc Solaris 5.5.1
Subsystem: SML compiler
Severity: critical
Problem:
The attached program causes a seg fault on an UltraSparc (Solaris 2.5.1)
and x86 Linux (2.0 24)

Code:
structure segfault =
    struct
        open Word32
 
        fun F (x, y, z) = orb(andb(x, y), andb(notb x, z))
 
        fun <<< (x, s) =
            let val rs = Word31.-(0w32, s)
            in 
                orb(<<(x, s), >>(x, rs))
            end
        infix 5 <<<
        val sub = Vector.sub
        infix 8 sub
 
        fun hash (X, (a, b, c, d)) =
                 (a + F(b, c, d) + (X sub 0)) <<< 0w3
 
    end
Transcript:
caesar:~/research/phi% ~blume/Research/ML/0.2/bin/sml
Standard ML of New Jersey, Version 110.0.2, January 16, 1998 [CM; autoload enabled]
- use "foo2.sml";
[opening foo2.sml]
GC #0.0.0.0.1.5:   (0 ms)
structure segfault :
  sig
    type word = ?.word32
    val * : word * word -> word
    val + : word * word -> word
    val - : word * word -> word
    val < : word * word -> bool
    val << : word * Word31.word -> word
    val <<< : word * Word31.word -> word
    val <= : word * word -> bool
    val > : word * word -> bool
    val >= : word * word -> bool
    val >> : word * Word31.word -> word
    val F : word * word * word -> word
    val andb : word * word -> word
    val compare : word * word -> order
    val div : word * word -> word
    val fmt : StringCvt.radix -> word -> string
    val fromInt : int -> word
    val fromLargeInt : Int32.int -> word
    val fromLargeWord : word -> word
    val fromString : string -> word option
    val hash : word vector * (word * word * word * word) -> word
    val max : word * word -> word
    val min : word * word -> word
    val mod : word * word -> word
    val notb : word -> word
    val orb : word * word -> word
    val scan : StringCvt.radix
               -> (char,'a) StringCvt.reader -> (word,'a) StringCvt.reader
    val sub : 'a vector * int -> 'a
    val toInt : word -> int
    val toIntX : word -> int
    val toLargeInt : word -> Int32.int
    val toLargeIntX : word -> Int32.int
    val toLargeWord : word -> word
    val toLargeWordX : word -> word
    val toString : word -> string
    val wordSize : int
    val xorb : word * word -> word
    val ~>> : word * Word31.word -> word
  end
val it = () : unit
- segfault.hash(#[0w128, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0, 0w0], (0wx67452391, 0wxefcdab89, 0wx98badcfe, 0wx10325476));
Segmentation fault

Comments:
Also seg faults on x86 Linux (2.0.24), Alpha (DEC OSF/1 3.2), MIPS
(Irix 5.3).  Does not segfault on PA-RISC (HP-UX 9.05).

[From Zhong]
It seems that the vector constructor #[0w0 : Word32.word is not
implemented correctly in 110.0.2. In fact, just typing

    #[0w0 : Word32.word];

would cause the segmentation fault.

Fix:
  new translate/wrapping.sml
Test: bug1340.1.sml
Owner:  zsh
Status:  fixed in 110.0.3 [Zhong, 1/30/98]
----------------------------------------------------------------------
Number: 1341
Title:       configuration script error re: GLOBALS_HAVE_UNDERSCORE
Keywords:    configuration
Submitter:   Christopher League <league@cs.yale.edu>
Date:        01/17/1998
Version:     110
System:      x86-linux
Severity:    very minor
Problem:     I got a link error while building the runtime on some
              (but not all) Linux systems.  The config/install.sh
              script runs config/chk-global-names.sh to determine
              whether global names should have underscores.  On my
              system they do NOT, but the script said they DO.  Here
              is why.  The script compiles a program containing a
              `main' function, then runs `nm(1)' and greps for
              "_main".  The grep succeeds in finding the symbol
	      `_IO_switch_to_main_get_area', because "_main' is a
              substring.  So it mistakenly outputs
              -DGLOBALS_HAVE_UNDERSCORE.
Code:        
Transcript:
Comments:
Fix:          In config/chk-global-names.sh, I changed 
	              grep -q "_main"
              to
	              grep -q -w "_main"

              I don't know whether it is a "standard" option, but -w
	      causes grep to match whole words only.  So it fails to
              match `_IO_switch_to_main_get_area' but would still
              match `main' if that symbol were present.
Test: *
Owner: jhr
Status: fixed in 110.0.3
----------------------------------------------------------------------
Number: 1342
Title: heap image size.
Keywords: 
Submitter: Nikolaj   nikolaj@cs.stanford.edu
Date: 01/19/98
Version: 110.0.2
System: Sparc Solaris 
Subsystem: Concurrent ML
Severity: critical
Problem:
  The heap image size is now back to the days of 109.27.
  This used to be "fixed" to some extent in 109.32:

  Now:
   33790344 Jan 19 14:28 step-110.sparc-solaris

  Then:
   15123292 Dec 18 01:07 step-109.32.sparc-solaris

  We are using Compiler.PrettyPrint, but do not use much else
  that could justify the size. At least the size increase seems
  to be a bug introduced while fixing other bugs:

  1337. exporfFn in CML produces large images

  as reported in PATH-2.
Code:
Transcript:
Comments:
Fix:
Test: 
Owner: jhr
Status: fixed in 110.0.3?
----------------------------------------------------------------------
Number: 1343
Title:       building runtime on x86 using gcc 2.8.0 fails
Keywords:    
Submitter:   Mikael Pettersson (mikpe@sophia.inria.fr)
Date:        01/20/98
Version:     all
System:	     all x86 Unixen
Severity:    major
Problem:     

The problem is the pre-processing of runtime/mach-dep/X86.prim.asm
that is done to evaluate and substitute symbolic constants before
assembling prim.s --> prim.o.

Standard Unix x86 assembly syntax requires literals to be prefixed
with dollar signs. During pre-processing, it is necessary to
consider constructs such as "$REQ_SIG_RETURN" as two tokens,
replace REQ_SIG_RETURN by its numerical value, and finally
emit "$value" without any blanks separating the "$" and the value.

gcc has implemented an "-ansi" option which has had the effect
of passing the "-$" option to its pre-processor, which causes
it to _not_ consider "$" part of identifiers. Fine.

But in gcc 2.8.0, "-ansi" no longer causes "-$" to be sent to
the pre-processor, so no constant substitution occurs and
the assembler complains about invalid instruction syntax.

A "simple" fix would be to modify the definition of CPP in the
mk.x86-* makefiles to invoke gcc with -Wp,-$ in order to force
the desired behaviour. This actually has to be written '-Wp,-\$$$$'
to protect it from the several layers of makefiles and shell
commands. It's fragile and IMHO not The Right Thing.

Below you'll find a patch for runtime/mach-dep/X86.prim.asm that
should solve this problem permanently. I'm using it on my Linux box.
The idea is to replace symbolic literals "$NAME" with macro calls
"IMMED(NAME)". The latter evaluates NAME, then prefixes it with "$".
This should work with any ANSI/ISO-C pre-processor, not just gcc.


Code:	     
Transcript:  
Comments:    
Fix:	     

--- runtime/mach-dep/X86.prim.asm.~1~	Thu Nov 20 21:42:53 1997
+++ runtime/mach-dep/X86.prim.asm	Mon Jan 19 21:29:28 1998
@@ -7,6 +7,7 @@
 
 #include "ml-base.h"
 #include "asm-base.h"
+#define IMMED(X) CONCAT($,X)
 #include "ml-values.h"
 #include "tags.h"
 #include "ml-request.h"
@@ -172,7 +173,7 @@
  1:;									\
 	jb	9f;							\
 	lea	1b, temp;		/* temp holds resume address */	\
-	movl	$maskval, mask;						\
+	movl	IMMED(maskval), mask;					\
 	jmp	via CSYM(saveregs);						\
  9:
 
@@ -182,8 +183,8 @@
 
 ML_CODE_HDR(sigh_return_a)
 	movl	mlstate_ptr, temp
-	movl	$REQ_SIG_RETURN, request_w
-	movl	$RET_MASK, mask
+	movl	IMMED(REQ_SIG_RETURN), request_w
+	movl	IMMED(RET_MASK), mask
 	jmp	CSYM(set_request)
 
 /* sigh_resume:
@@ -193,10 +194,10 @@
 
 ENTRY(sigh_resume)
 	movl	mlstate_ptr, temp
-	movl	$REQ_SIG_RESUME, request_w
-/*	movl	$RET_MASK, mask
+	movl	IMMED(REQ_SIG_RESUME), request_w
+/*	movl	IMMED(RET_MASK), mask
  */
-	movl	$FUN_MASK, mask
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 /* pollh_return_a:
@@ -204,8 +205,8 @@
  */
 ML_CODE_HDR(pollh_return_a)
 	movl	mlstate_ptr, temp
-	movl	$REQ_POLL_RETURN, request_w
-	movl	$RET_MASK, mask
+	movl	IMMED(REQ_POLL_RETURN), request_w
+	movl	IMMED(RET_MASK), mask
 	jmp	CSYM(set_request)
 
 /* pollh_resume:
@@ -213,22 +214,22 @@
  */
 ENTRY(pollh_resume)
 	movl	mlstate_ptr, temp
-	movl	$REQ_POLL_RESUME, request_w
-/*	movl	$RET_MASK, mask
+	movl	IMMED(REQ_POLL_RESUME), request_w
+/*	movl	IMMED(RET_MASK), mask
  */
-	movl	$FUN_MASK, mask
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 ML_CODE_HDR(handle_a)
 	movl	mlstate_ptr, temp
-	movl	$REQ_EXN, request_w
-	movl	$EXN_MASK, mask
+	movl	IMMED(REQ_EXN), request_w
+	movl	IMMED(EXN_MASK), mask
 	jmp	CSYM(set_request)
 
 ML_CODE_HDR(return_a)
 	movl	mlstate_ptr, temp
-	movl	$REQ_RETURN, request_w
-	movl	$RET_MASK, mask
+	movl	IMMED(REQ_RETURN), request_w
+	movl	IMMED(RET_MASK), mask
 	jmp	CSYM(set_request)
 
 /* Request a fault.  The floating point coprocessor must be reset
@@ -240,8 +241,8 @@
 ENTRY(request_fault)
 	call    CSYM(FPEEnable)          /* Doesn't trash any general regs. */
 	movl	mlstate_ptr, temp
-	movl	$REQ_FAULT, request_w
-	movl	$EXN_MASK, mask
+	movl	IMMED(REQ_FAULT), request_w
+	movl	IMMED(EXN_MASK), mask
 	jmp	CSYM(set_request)
 
 /* bind_cfun : (string * string) -> c_function
@@ -249,22 +250,22 @@
 ML_CODE_HDR(bind_cfun_a)
 	CHECKLIMIT(FUN_MASK)
 	movl	mlstate_ptr, temp
-	movl	$REQ_BIND_CFUN, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_BIND_CFUN), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 ML_CODE_HDR(build_literals_a)
 	CHECKLIMIT(FUN_MASK)
 	movl	mlstate_ptr, temp
-	movl	$REQ_BUILD_LITERALS, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_BUILD_LITERALS), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 ML_CODE_HDR(callc_a)
 	CHECKLIMIT(FUN_MASK)
 	movl	mlstate_ptr, temp
-	movl	$REQ_CALLC, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_CALLC), request_w
+	movl	IMMED(FUN_MASK), mask
 	/* fall into set_request */
 
 ENTRY(set_request)
@@ -330,7 +331,7 @@
 	movl	request_w,creturn
 
 	/* Pop the stack frame and return to run_ml(). */
-	addl	$ML_FRAME_SIZE, %esp
+	addl	IMMED(ML_FRAME_SIZE), %esp
 	CALLEE_RESTORE
 	ret
 
@@ -364,7 +365,7 @@
 	jmp	do_gc		/* and handle event in the C runtime */
 	
 reset_limit:	/* reset limit ptr */
-	shll	$POLL_GRAIN_BITS,pfreq		/* mult by POLL_GRAIN_CPSI */
+	shll	IMMED(POLL_GRAIN_BITS),pfreq	/* mult by POLL_GRAIN_CPSI */
 	movl	allocptr,limitptr
 	addl	pfreq,limitptr
 #undef	pfreq
@@ -453,8 +454,8 @@
 #undef	temp2	
 
 	/* Pop the stack frame and return to run_ml(). */
-	movl	$REQ_GC,creturn
-	addl	$ML_FRAME_SIZE, %esp
+	movl	IMMED(REQ_GC),creturn
+	addl	IMMED(ML_FRAME_SIZE), %esp
 	CALLEE_RESTORE
 	ret
 
@@ -464,7 +465,7 @@
 
 #define temp2	%ebx
 	/* Allocate and initialize the ML stack frame. */
-	subl	$ML_FRAME_SIZE, %esp
+	subl	IMMED(ML_FRAME_SIZE), %esp
 	MOVE(	tempmem_w,  temp2, tempmem)
 	MOVE(	tempmem2_w, temp2, tempmem2)
 	MOVE(	ExnPtrOffMSP(temp),  temp2, exncont) 
@@ -558,15 +559,15 @@
 	CHECKLIMIT(FUN_MASK)
 	movl 	0(stdarg),temp               /* desired length into temp */
 	sarl	$1,temp			     /* untagged */
-	cmpl	$SMALL_OBJ_SZW,temp
+	cmpl	IMMED(SMALL_OBJ_SZW),temp
 	jge	3f
 
 #define	tmpreg	misc1
 	pushl	tmpreg
 
 	movl	temp,tmpreg		     /* build descriptor in tmpreg */
-	sall	$TAG_SHIFTW,tmpreg
-	orl	$MAKE_TAG(DTAG_array),tmpreg
+	sall	IMMED(TAG_SHIFTW),tmpreg
+	orl	IMMED(MAKE_TAG(DTAG_array)),tmpreg
 	movl	tmpreg,0(allocptr)	     /* write descriptor */
 	addl	$4,allocptr
 	movl	4(stdarg),tmpreg	     /* initial values */
@@ -585,8 +586,8 @@
 	CONTINUE
 3:
 	movl	mlstate_ptr, temp
-	movl	$REQ_ALLOC_ARRAY, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_ALLOC_ARRAY), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 	
 
@@ -596,7 +597,7 @@
 	movl 	stdarg,temp               /* desired length into temp */
 	sarl	$1,temp			  /* untagged */
 	shll	$1,temp			  /* size in words */
-	cmpl	$SMALL_OBJ_SZW,temp
+	cmpl	IMMED(SMALL_OBJ_SZW),temp
 	jge	2f
 
 #define	tmpreg	misc1
@@ -604,8 +605,8 @@
 
 	shrl	$1,temp			  /* size in reals */
 	movl	temp,tmpreg		     /* build descriptor in tmpreg */
-	sall	$TAG_SHIFTW,tmpreg
-	orl	$MAKE_TAG(DTAG_realdarray),tmpreg
+	sall	IMMED(TAG_SHIFTW),tmpreg
+	orl	IMMED(MAKE_TAG(DTAG_realdarray)),tmpreg
 	movl	tmpreg,0(allocptr)	     /* write descriptor */
 	addl	$4,allocptr
 	movl	allocptr,stdarg		     /* stdarg gets ptr to new array */
@@ -617,8 +618,8 @@
 	CONTINUE
 2:
 	movl	mlstate_ptr, temp
-	movl	$REQ_ALLOC_REALDARRAY, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_ALLOC_REALDARRAY), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 
@@ -629,7 +630,7 @@
 	sarl	$1,temp			     /* untagged */
 	addl	$3,temp			     /* round */	
 	sarl	$2,temp			     /* to words */
-	cmpl	$SMALL_OBJ_SZW,temp
+	cmpl	IMMED(SMALL_OBJ_SZW),temp
 	jge	2f
 
 #define	tmpreg	misc1
@@ -637,8 +638,8 @@
 
 	movl	stdarg,tmpreg		     /* build descriptor in tmpreg */
 	sarl	$1,tmpreg
-	sall	$TAG_SHIFTW,tmpreg
-	orl	$MAKE_TAG(DTAG_bytearray),tmpreg
+	sall	IMMED(TAG_SHIFTW),tmpreg
+	orl	IMMED(MAKE_TAG(DTAG_bytearray)),tmpreg
 	movl	tmpreg,0(allocptr)	     /* write descriptor */
 	addl	$4,allocptr
 	movl	allocptr,stdarg		     /* stdarg gets ptr to new str */
@@ -651,8 +652,8 @@
 	CONTINUE
 2:
 	movl	mlstate_ptr, temp
-	movl	$REQ_ALLOC_BYTEARRAY, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_ALLOC_BYTEARRAY), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 
@@ -663,7 +664,7 @@
 	sarl	$1,temp			     /* untagged */
 	addl	$4,temp			     /* round */	
 	sarl	$2,temp			     /* to words */
-	cmpl	$SMALL_OBJ_SZW,temp
+	cmpl	IMMED(SMALL_OBJ_SZW),temp
 	jge	2f
 
 #define	tmpreg	misc1
@@ -671,8 +672,8 @@
 
 	movl	stdarg,tmpreg		     /* build descriptor in tmpreg */
 	sarl	$1,tmpreg
-	sall	$TAG_SHIFTW,tmpreg
-	orl	$MAKE_TAG(DTAG_string),tmpreg
+	sall	IMMED(TAG_SHIFTW),tmpreg
+	orl	IMMED(MAKE_TAG(DTAG_string)),tmpreg
 	movl	tmpreg,0(allocptr)	     /* write descriptor */
 	addl	$4,allocptr
 	movl	allocptr,stdarg		     /* stdarg gets ptr to new str */
@@ -686,8 +687,8 @@
 	CONTINUE
 2:
 	movl	mlstate_ptr, temp
-	movl	$REQ_ALLOC_STRING, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_ALLOC_STRING), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 
 /* create_v_a : int * 'a list -> 'a vector
@@ -698,15 +699,15 @@
 	CHECKLIMIT(FUN_MASK)
 	movl 	0(stdarg),temp               /* desired length into temp */
 	sarl	$1,temp			     /* untagged */
-	cmpl	$SMALL_OBJ_SZW,temp
+	cmpl	IMMED(SMALL_OBJ_SZW),temp
 	jge	3f
 
 #define	tmpreg	misc1
 	pushl	tmpreg
 
 	movl	temp,tmpreg		     /* build descriptor in tmpreg */
-	sall	$TAG_SHIFTW,tmpreg
-	orl	$MAKE_TAG(DTAG_vector),tmpreg
+	sall	IMMED(TAG_SHIFTW),tmpreg
+	orl	IMMED(MAKE_TAG(DTAG_vector)),tmpreg
 	movl	tmpreg,0(allocptr)	     /* write descriptor */
 	addl	$4,allocptr
 	movl	4(stdarg),tmpreg	     /* list of initial values */
@@ -715,7 +716,7 @@
 	movl	0(tmpreg),temp		     	/* temp <- hd(tmpreg) */
 	stosl				        /* 0(allocptr++) <- temp */
 	movl	4(tmpreg),tmpreg	     	/* tmpreg <- tl(tmpreg) */
-	cmpl	$ML_nil,tmpreg		     	/* end of list */
+	cmpl	IMMED(ML_nil),tmpreg		/* end of list */
 	jne	2b
 
 	popl	tmpreg
@@ -724,8 +725,8 @@
 	CONTINUE
 3:
 	movl	mlstate_ptr, temp
-	movl	$REQ_ALLOC_VECTOR, request_w
-	movl	$FUN_MASK, mask
+	movl	IMMED(REQ_ALLOC_VECTOR), request_w
+	movl	IMMED(FUN_MASK), mask
 	jmp	CSYM(set_request)
 	
 /* try_lock: spin_lock -> bool. 
@@ -889,7 +890,7 @@
 	fldl	(temp)			/* Load it into temp. */
 
 	fscale				/* Multiply exponent by scalar. */
-	movl	$DESC_reald, (allocptr)
+	movl	IMMED(DESC_reald), (allocptr)
 	fstpl	4(allocptr)		/* Store resulting 

Test: 
Owner: jhr, Lal
Status: fixed in 110.0.3
----------------------------------------------------------------------
Number: 1344
Title: Unimplemented real conversions
Keywords: reals
Submitter: Emden R. Gansner   erg@research.att.com
Date: 01/20/98
Version: 110.0.2
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: minor
Problem:
  Real.toLargeInt and Real.toInt only partially implemented.
Code:
  For example,
  Real.toLargeInt IEEEReal.TO_NEGINF 1073741824.0;
  Transcript:
  - Real.toLargeInt IEEEReal.TO_NEGINF 1073741824.0;

  uncaught exception overflow
    raised at: boot/real64.sml:90.16-90.32
  - 

Comments:
Fix:
Test: bug1344.sml
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1345
Title: Char.toString(#"\n") error
Keywords: 
Submitter: Joe Turner   turner@cs.clemson.edu
Date: 01/21/98
Version: 1.10 (?) (latest)
System: Any/All Any Unix 
Subsystem: SML basis library
Severity: major
Problem:
The result of Char.toString(#"\n") is "\\n" (string of two characters:
   #"\\" and #"n". 

I categorized this as minor, but it is fairly major.  It seems to require
an ugly kluge to work around when reading from a text file.

Another problem is that file output on Dos platforms (Win95 at least)
outputs "\n" as a single character.  Perhaps this is intended, but it
is inconsistent with print("\n") on the same system.
Code:
Char.toString(#"\n");
Transcript:
- Char.toString(#"\n");
val it = "\\n" : string
Comments: [jhr, 1/23/97]
  I think that you must be confusing the semantics of Char.toString
  and String.str.  The toString functions are supposed to produce
  printable results; String.str converts a character to a one character
  string.
Fix:
Test: 
Owner: jhr
Status: not a bug
----------------------------------------------------------------------
Number: 1346
Title: Compiler bug: ModuleUtil: getStr: bad entity
Keywords: modules, secondary error
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 1/25/98
Version: 110.0.2
System: -
Severity: minor 
Problem: 
  I got the following compiler error when I passed the wrong thing to a 
  functor.
Code: ?
Transcript:
  [compiling NW/link1.sml (via: link1.sml@link.nw) -> NW/CM/x86-unix/link1.sml.bin]
  link.nw:7.46-7.74 Error: unmatched structure specification: Patterns
  link.nw:7.46-7.74 Error: unmatched structure specification: Constructor
  Error: Compiler bug: ModuleUtil: getStr: bad entity

  uncaught exception Error
    raised at: util/errormsg.sml:54.14-54.19
	       modules/sigmatch.sml:726.45
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:882.25
	       modules/sigmatch.sml:726.45
	       modules/sigmatch.sml:882.25
	       modules/sigmatch.sml:726.45
	       modules/sigmatch.sml:726.45
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:839.39
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:872.22
	       modules/sigmatch.sml:872.22
	       modules/sigmatch.sml:674.29
	       modules/sigmatch.sml:882.25
	       modules/sigmatch.sml:726.45
	       modules/sigmatch.sml:882.25
	       modules/sigmatch.sml:964.24
	       elaborate/elabmod.sml:1223.8
	       elaborate/elabmod.sml:1223.8
	       elaborate/elabmod.sml:1458.7
	       elaborate/elabmod.sml:1223.8
	       elaborate/elabmod.sml:1328.33
	       util/stats.sml:164.40
	       sched/recompile.sml:206.38-206.41

Comments:
Fix:
Test:
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1347
Title: Copying part of a recusive datatype gives constructors wrong types 
Keywords:    modules, datatypes
Submitter:   Perry Cheng (pscheng@cs.cmu.edu)
Date:        1/30/98
Version:     109.32
System:      Alpha - DUX4.0
Severity:    Major
Problem:     When one part of a recursive datatype is copied,
		the types of the constructors that are copied
		do not refer back to the original recursive datatype. 
Code:        

  signature INNER =
  sig
    datatype a = A
    and b = B of a
  end;

  signature OUTER =
  sig
    structure Inner : INNER
    datatype b = datatype Inner.b
  end;

  functor Test(structure Inner : INNER
	       structure Outer : OUTER
	       sharing Outer.Inner = Inner)
      =
  struct
    (* Both functions should typecheck but the second one does not. *)
    fun good (Inner.B(Inner.A)) = 5
    fun bad  (Outer.B(Inner.A)) = 5
  end;

Transcript:
  - use "bad.sml";
  [opening bad.sml]
  bad.sml:23.5-23.36 Error: constructor and argument don't agree in pattern 
  [tycon mismatch]
    constructor: ?.a -> Inner.b
    argument:    Inner.a
    in pattern:
      B A

Comments:
  Notice that the datatype above is not really recursive.
  if the datatype in INNER were not declared recursively,
  the problem goes away.  Of course, this doesn't 
  help when the datatype really is recursive.

Fix:         <optional - but you get extra credit!>
Test: bug1347.1.sml
Owner: dbm
Status: fixed in 110.0.2
----------------------------------------------------------------------
Number: 1348
Title: "Out of environment space" on Windows
Keywords: Windows
Submitter: Mitchell Wand <wand@ccs.neu.edu>
Date: 2/2/98
Version: 110
System: Windows
Severity: major
Problem: 
  I had written:

  > I downloaded SMLNJ 110 right out of the box, but when I go to start it I get
  > a DOS window that says:
  >
  > Out of environment space
  > Bad command or file name


  Analysis: on my system, at least, SMLNJ starts in a DOS window with the
  initial environment size set on "Auto".  Hence, when the script assigns an
  environment variable SMLNJ_HOME, the shell immediately runs out of environment
  space (hence the "Out of environment space" message).  Therefore the variable
  %SMLNJ_HOME% gets interpreted as the empty string, and so it tries to execute
  "bin\.run\whatver", which of course doesn't exist (hence the "bad command or
  file name" message)
Code:
Transcript:
Comments:
Fix:
  1.  Open up a file browser to look at 
  c:\Windows\Start Menu\Program Files\Standard ML of New Jersey\ .  

  2. Select "Standard ML of New Jersey" and select File|Properties to open up
  the property sheet for the shortcut.

  3. On the Memory tab, change the "Initial Environment" setting from "auto" to
  1024. 

  Suggestion: It would seem that the install scripts ought to be able to do this
  automatically.
Test:
Owner: Riccardo
Status: open
----------------------------------------------------------------------
Number: 1349
Title: segmentation faults on Linux
Keywords: 
Submitter: Roland Olsson <rolando@tor.hiof.no>
Date: 2/5/98
Version: 109.xx
System: x86/Linux
Severity: major
Problem: 
  I have used versions 109.xx for varying xx during the last year and a 
  half under LINUX 2.0.yy on a PentiumPro CPU. The entire time, there 
  has been a very low frequency bug that causes segmentation faults. 
  The frequency of crashes is about once per two weeks of CPU time, 
  which is seldom enough to make the bug rather acceptable.

  The bug doesn't seem to be related to VM growth as suggested by John 
  Reppy to me more than one year ago.

  I have now used gdb on run.x86-linux to try to track the problem and 
  have a live gdb session going right now with the following output so 
  far:

  Program received signal SIGSEGV, Segmentation fault.

  0x44c71072 in ?? ()

  (gdb) bt
  #0 0x44c71072 in ?? ()
  #1 0x40121f44 in ?? ()
  #2 0x42d70368 in ?? ()
  #3 0xff2424

  Cannot access memory at address 0x44c71072

  Can you please suggest some course of action that would enable the 
  bug to be traced? How likely is is that the bug does not exist in 
  110.zz?
Code:
Transcript:
Comments:
Fix:
Test:
Owner: Lal, jhr
Status: open
----------------------------------------------------------------------
Number: 1350
Title:       X86.prim.asm has a typo
Keywords:    runtime, assembly
Submitter:   Mikael Pettersson (mikpe@sophia.inria.fr)
Date:        02/05/98
Version:     110.0.3
System:	     all x86
Severity:    minor
Problem:
  One occurrence of MAKE_TAG in runtime/mach-dep/X86.prim.asm wasn't
  rewritten correctly to use the IMMED macro. The assembler won't complain;
  instead it will record "MAKE_TAG" as an external symbol in the object file.
  When the runtime system is linked, the linker notices that "MAKE_TAG"
  doesn't exist and quits with an error.

Code:
Transcript:
Comments:
Fix:

--- runtime/mach-dep/X86.prim.asm.~1~	Fri Jan 23 20:17:03 1998
+++ runtime/mach-dep/X86.prim.asm	Wed Feb  4 21:14:34 1998
@@ -605,7 +605,7 @@
 	shrl	IMMED(1),temp			  /* size in reals */
 	movl	temp,tmpreg		     /* build descriptor in tmpreg */
 	sall	IMMED(TAG_SHIFTW),tmpreg
-	orl	IMMED(MAKE_TAG)(DTAG_realdarray),tmpreg
+	orl	IMMED(MAKE_TAG(DTAG_realdarray)),tmpreg
 	movl	tmpreg,0(allocptr)	     /* write descriptor */
 	addl	IMMED(4),allocptr
 	movl	allocptr,stdarg		     /* stdarg gets ptr to new array */

Test:
Owner: jhr
Status: fixed in 110.0.3 [jhr, 2/5/98]
----------------------------------------------------------------------
Number: 1351
Title:       Datatype replication within abstypes
Keywords:    abstypes, datatype replication
Submitter:   Stephen Gilmore, stg@dcs.ed.ac.uk
Date:        2/11/1998
Version:     110
System:      sparc-solaris2.5
Severity:    minor
Problem:     Abstypes cannot be replicated in their bodies.
Code:        abstype A = B with datatype A = datatype A end;
Transcript:  - abstype A = B with datatype A = datatype A end;

	     uncaught exception nonexhaustive match failure
	         raised at: print/ppdec.sml:158.6
			    util/pp.sml:554.6
Comments:    The Definition of SML allows this.  The constructor
             should be exported but not the equality on the absytype.

Fix:
Test: bug1351.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1352
Title: Equality status of reals is compromised
Keywords: Equality, overloading, reals
Submitter: Andrew Kennedy  <Andrew.Kennedy@persimmon.co.uk>
Date: 02/13/98
Version: 110.0.3
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: minor
Problem:
  One can obtain equality on reals by forcing a type to admit both
  division and equality.
Code:
  fun f (x,y) = (x=y, x/y)
Transcript:
  - fun f (x,y) = (x=y,x/y);
  val f = fn : real * real -> bool * real
  - f (2.0, 2.0);
  val it = (true,1.0) : bool * real
  - f (2.0, 4.0);
  val it = (false,0.5) : bool * real

Comments:

Fix:
  The softInst function in softUnify in overload.sml has to check
  for the consistency of equality properties.
Test: bug1352.sml
Owner: dbm
Status: fixed in 110.9, 110.0.4
----------------------------------------------------------------------
Number: 1353
Title:       unnecessary(?) recompilation of grm.sml and lex.sml files
	     using sml as a batch compiler
Keywords:    CM,ML-Lex,ML-Yacc
Submitter:   Gergely Buday <gergoe@math.bme.hu>
Date:        16.2.1998.
Version:     110.0.3
System:      x86-linux
Severity:    minor
Problem:     I modify only the top-level code of my parser, but 
	     it does recompile grm.sml and lex.sml files.
	     It does this only if I use my script that reinvoke sml
	     and CM.make(). From an interactive session the problem does not
	     raise.
	     I do not supply my code since it does not depend on the code -
	     at least I suppose. 
Code:        

  ***********
  sources.cm
  ***********
  Group is

	  ml-yacc-lib.cm
	  tool.grm
	  tool.lex
	  doctool.sml 

  ***********
  my stupid script
  ***********
  run
  sml <<XXXX
  CM.make();
  SMLofNJ.exportFn("doctool",DocTool.main);
  XXXX
  echo 'sml @SMLload=doctool.x86-linux $*' >doctool
  chmod +x doctool
  ***************   
Transcript:  a lot of GC messages
Comments:    Maybe it's not a bug - it's a feature :-)

 [Matthias, 3/5/97]
  I was unable to reproduce bug 1353, so I checked back with Gergely
  Buday (who reported this problem).  He suggested that something was
  wrong with his script, so the bottom line is that probably there is no
  bug.
Fix:         <optional - but you get extra credit>
Test: -
Owner: Matthias
Status: not a bug
----------------------------------------------------------------------
Number: 1354
Title: spurious "possibly inconsistent structure definitions"
Keywords: modules, signatures, structure definition specs
Submitter: Ed Osinski <osinski@valis.cs.nyu.edu>
Date: 2/10/98
Version: 110.0.3
System: -
Severity: major 
Problem: 
  "possibly inconsistent structure definitions" occurs
Code:
Transcript:
  - use "tests/bug1354.1.sml";
  [opening tests/bug1354.1.sml]
  tests/bug1354.1.sml:33.1-39.4 Error: possibly inconsistent structure definitions at: UC.Type.Ir
Comments:
 [dbm, 8/13/98]
  The error message was generated in the buildStrClass/constrain
  function, which detects a secondary definition after a class already
  has a definition (classDef is SOME _).
  It appears to be safe to adopt a lenient policy of just ignoring
  secondary definitions (while generating a warning message).  This
  may allow more bogus signatures to be instantiated, but they
  will not be matchable.
Fix:
  In instantiate.sml, have constrain function (in buildStrClass) ignore
  secondary definitions on structure (and type) elements, and generate
  a warning about multiple defs.
Test: bug1354.1.sml, bug1354.2.sml, bug1354.3.sml
Owner: dbm
Status: fixed in 110.0.4 and 110.9
----------------------------------------------------------------------
Number: 1355
Title:       exportFn image size increase on alpha32x-osf1
Keywords:    
Submitter:   Mikael Pettersson, mikpe@sophia.inria.fr
Date:        02/18/98
Version:     110.2
System:	     alpha32x-osf1
Severity:    major
Problem:     sudden increase in size of exportFn images on alpha32x-osf1
Code:	     
Transcript:  

Comparing vanilla builds of 110.0.3 and 110.2:

bahia_1_ls -l 110.{0.3,2}/bin/heap/*.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2     640528 Feb  4 14:57 110.0.3/bin/.heap/ml-burg.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2     455240 Feb  4 14:52 110.0.3/bin/.heap/ml-lex.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2     761000 Feb  4 14:52 110.0.3/bin/.heap/ml-yacc.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2    7925928 Feb  4 14:57 110.0.3/bin/.heap/sml-cm.alpha32x-osf1
lrwxrwxrwx   1 mikpe    croap2         20 Feb  4 14:50 110.0.3/bin/.heap/sml.alpha32x-osf1@ -> sml-cm.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2     859664 Feb 18 15:17 110.2/bin/.heap/ml-burg.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2     604744 Feb 18 15:11 110.2/bin/.heap/ml-lex.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2    1033384 Feb 18 15:11 110.2/bin/.heap/ml-yacc.alpha32x-osf1
-rw-r--r--   1 mikpe    croap2   10404828 Feb 18 15:17 110.2/bin/.heap/sml-cm.alpha32x-osf1
lrwxrwxrwx   1 mikpe    croap2         20 Feb 18 15:02 110.2/bin/.heap/sml.alpha32x-osf1@ -> sml-cm.alpha32x-osf1

Comments:    

  On two other systems I've tested, sparc-solaris2 and x86-linux,
  the heap images have not increased at all (well, by less than 1%).
  Here we're suddenly seeing a 31%-36% size increase.
  (The SML code I'm working on now grew by 37% from 1208K to 1648K.)

  Since SPARC and x86 aren't affected, I supect something Alpha-specific
  in the code generator. The recent MLRISC changes perhaps?

 [Lal, 2/18/98]
  There is a major problem with the register allocator. The problem will
  also exist on the hppa. Correct code is currently generated by 110.2,
  except that it is very bad code. 

Fix: found
Test:
Owner: Lal, jhr, Zhong?
Status: open
----------------------------------------------------------------------
Number: 1356
Title: Inflexibility in installation and CM
Keywords: installation CM
Submitter: Emden R. Gansner   erg@research.att.com
Date: 02/20/98
Version: 110
System: Any/All Any Unix 
Subsystem: Installation
Severity: minor
Problem:
  The script config/install.sh assumes the system is built where it
  is going to be installed, and that once installed, the tree will never
  be moved. In certain environments, neither of these is true.

  Minimally, I'd like to be able to build the system in some directory
  with a given installation directory in mind. I could almost handle this
  with changes to install.sh, fixing the script to build the system, then
  change the absolute path names in the bin and lib directories. In
  addition, CM could be built with the installation path, but used to
  construct the system by setting CM_PATH in the script.

  Alas, the path of ml-yacc (for burg) is built into CM and cannot be
  overridden. (A CM_TOOL or CM_YACC environment variable would be nice.)
  So, we build CM twice, once to build the system, once for its final 
  installation.

  Everything then works fine, up until the final clause when autoloading
  is enabled. I'd like to build in the appropriate installed library
  paths, but CM wants to analyze the .cm files now and they haven't been
  installed yet. Here's where another indirection would be useful.

 [Blume, 5/5/98]
  When CM invokes one of the standard tools (Yacc, Lex, Burg, ...)
  it will now always first consult the corresponding environment
  variable (CM_YACC, CM_LEX, ...).  In effect, the tool
  locations are no longer hard-wired into CM (although
  defaults for these locations still do exist).
  This partially fixes bug #1356.  The remaining part of this bug
  has to do with autoloading.  To fix it would require a major
  reorganization of all of CM.  I believe that autoloading as 
  a feature is of rather limited utility so that such a big
  change is hard to justify.
  If the installation of SML/NJ is to be moved to a different
  location in the file system, then I would recommend building
  it with autoloading disabled.  A separate script could be
  provided for selectively enabling autoload *after* the move.

Code:
Transcript:
Comments:
Fix:
Test: 
Owner: Matthias
Status: fixed in 110.6 (partially: see Blume's comment)
----------------------------------------------------------------------
Number: 1357
Title: rebinding of constructors and exceptions not allowed
Keywords: rebinding, constructors, SML97
Submitter: Konrad Slind <Konrad.Slind@cl.cam.ac.uk>
Date: 2/20/97
Version: 110.0.3
System: -
Severity: minor 
Problem: 
  Quoting from the rule (26) on page 24 of the revised Definition:

     ... Also note that C + VE may overwrite identifier status. For
     example, the program 

	 datatype t = f; val rec f = fn x => x

     is legal. 

  Unfortunately, neither MoscowML or SML/NJ 110 allow this.

Code:
  datatype t = f; val rec f = fn x => x 

Transcript:
  - datatype t = f; val rec f = fn x => x;
  datatype t = f
  stdIn:16.25-16.38 Error: rebinding data constructor "f" as variable

Comments:
  There's a user-level workaround:

    - define a datatype with the problem constructor in a structure S;
    - give the datatype an abstract type in the signature of S
    - open S

  After this, the constructor has lost its constructor status and can be 
  redeclared. The following works in SML/NJ 110.

  datatype t = f; 

  local structure S :sig type mask 
			 val f: mask end = 
  struct
     datatype mask = f
  end
  in open S end;

  val rec f = fn x => x;
Fix:
  delete calls of checkBoundConstructor in elabVALREC(strict) and
  elabFUNdec in elabcore.sml
Test: bug1357.sml
Owner: dbm
Status: fixed in 110.0.4 and 110.9 [dbm, 8/14/98]
----------------------------------------------------------------------
Number: 1358
Title: bad error message line numbers in interactive system
Keywords: error message, line numbers, source
Submitter: Dave MacQueen
Date: 2/24/98
Version: 110.2
System: -
Severity: major 
Problem: 
  The line numbers produced for error messages in the interactive
  system are incorrect.
Transcript:
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled]
  - val nil x = [];
  stdIn:16.5-16.15 Error: constant constructor applied to argument in pattern:nil
  - val nil x = [];
  stdIn:1.5-2.10 Error: constant constructor applied to argument in pattern:nil
Comments:
Fix:
Test:
Owner: dbm, Andrew
Status: open
----------------------------------------------------------------------
Number: 1359
Title: unexpected diagnostic message
Keywords: messages, equality
Submitter: Allen Stoughton <allen@cis.ksu.edu>
Date: 2/24/98
Version: 110.0.3
System: -
Severity: minor 
Problem: 
  It's not that it produces an incorrect result, it's just that it
  issues the unexpected message
 
   int-equality used for ptr-equality

Transcript:
  > Standard ML of New Jersey, Version 110, December 9, 1997 [CM; autoload enabled]
  > - let fun g(n, f) = if f = f then (n, true) else f
  > = in g(0, (0, true)) end;
  > int-equality used for ptr-equality
  > val it = (0,true) : int * bool
Comments:
  A harmless diagnostic message that should have been deleted.
Fix:
Test: bug1359.sml
Owner: Zhong
Status: fixed in 110.0.6 and 110.7
----------------------------------------------------------------------
Number: 1360
Title: uncaught exception FPRegEA
Keywords: fwrap
Submitter: Edoardo S. Biagioni   esb@maru.ics.hawaii.edu
Date: 02/25/98
Version: 110.2
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: major
Problem:

Code:
signature EXTERN =
 sig
  type T
 end 

signature PRINTABLE =
 sig
  type T
 end 

signature KEY =
 sig
  include PRINTABLE
 end 

signature EXTERN_KEY =
 sig
  include EXTERN
 end 

signature EXTERNAL =
 sig
  include PRINTABLE
 end 

signature PROTOCOL =
 sig

  structure Address: KEY
  structure Pattern: KEY
  structure Connection_Key: KEY

  structure Outgoing: EXTERNAL

  type connection_extension
  type listen_extension
  type session_extension

  datatype connection = C of {send: unit -> unit,
			      abort: unit -> unit,
			      extension: connection_extension}

  datatype listen = L of {stop: unit -> unit, extension: listen_extension}

  datatype handler = H of Connection_Key.T
                  -> {connection_handler: connection -> unit,
	              data_handler: connection * unit -> unit,
	              status_handler: connection * unit -> unit}

  datatype session = S of {connect: Address.T * handler -> unit,
			   listen: Pattern.T * handler * unit -> listen,
			   extension: session_extension}

  val session: (session -> 'a) -> 'a

 end ;

functor Connection (structure Address: KEY
		    structure Pattern: KEY
		    structure Connection_Key: KEY
		    structure Outgoing: EXTERNAL
		    type connection_extension
		    type listen_extension
		    type session_extension
		    type connection_state
		    type protocol_state): PROTOCOL =
 struct

  structure Address = Address
  structure Pattern = Pattern
  structure Connection_Key = Connection_Key
  structure Outgoing = Outgoing

  type connection_extension = connection_extension
  type listen_extension = listen_extension
  type session_extension = session_extension

  datatype connection = C of {send: unit -> unit,
		     abort: unit -> unit,
	             extension: connection_extension}

  datatype listen = L of {stop: unit -> unit, extension: listen_extension}

  datatype handler = H of Connection_Key.T
                  -> {connection_handler: connection -> unit,
	              data_handler: connection * unit -> unit,
	              status_handler: connection * unit -> unit}

  datatype session = S of {connect: Address.T * handler -> unit,
		     listen: Pattern.T * handler * unit -> listen,
	             extension: session_extension}


   exception Y

   fun session _ = raise Y

 end;

functor Tcp (structure Lower: PROTOCOL): PROTOCOL=
 struct

  structure Tcp_Connection =
   struct

    structure Tcp_Key = struct type T = unit end
    structure Tcp_Address = struct type T = unit end
    structure Tcp_Pattern = struct type T = unit end
    structure Tcp_Host_Id = struct type T = unit end
    type host_id = unit
    type port = unit

    structure Outgoing = Lower.Outgoing
    type outgoing = Outgoing.T

    datatype tcp_connection_extension =
	Tcp_Connection_Extension of
	  {urgent_send: Outgoing.T -> unit}

    type session_extension = unit
    type protocol_state = unit
    type connection_state = protocol_state
    datatype transport_listen_extension =
	Listen_Extension of {local_port: port, additional: unit}
    type listen_extension = transport_listen_extension

    type connection_internals_record =
	{tcp_send: (unit -> unit) ref,
	 tcp_abort: (unit -> unit) ref,
	 urgent_send: (Outgoing.T -> unit) ref}

    datatype connection_internals = Connection_Internals of
				      connection_internals_record

    type connection_extension =
          (tcp_connection_extension * connection_internals) ref

    structure Conn =
      Connection (structure Address = Tcp_Address
		  structure Pattern = Tcp_Pattern
		  structure Connection_Key = Tcp_Key
		  structure Outgoing = Outgoing
		  type connection_extension = connection_extension
		  type listen_extension = listen_extension
		  type session_extension = session_extension
		  type connection_state = connection_state
		  type protocol_state = protocol_state)

   end					

  local
   structure Conn:
    sig
     structure Address: KEY
     structure Pattern: KEY
     structure Connection_Key: KEY
     structure Outgoing: EXTERNAL
     type listen_extension
     type session_extension
     datatype listen = L of {stop: unit -> unit, extension: listen_extension}
    end
   = Tcp_Connection.Conn
  in
    open Conn
  end

  structure Conn = Tcp_Connection.Conn

  structure Transport_Address = Tcp_Connection.Tcp_Address
  structure Transport_Pattern = Tcp_Connection.Tcp_Pattern
  structure Transport_Key     = Tcp_Connection.Tcp_Key

  structure Host_Id = Tcp_Connection.Tcp_Host_Id
  type host_id = Tcp_Connection.host_id
  type port    = Tcp_Connection.port

  local
    
    structure Export_Listen_Extension:
      sig
	datatype transport_listen_extension =
	  Listen_Extension of {local_port: port, additional: unit}
      end
    = Tcp_Connection
  in
    open Export_Listen_Extension
  end
  type additional_listen_extension = unit

  local
    structure Internals:
     sig datatype connection_internals =
	   Connection_Internals of Tcp_Connection.connection_internals_record
	 datatype tcp_connection_extension =
	   Tcp_Connection_Extension of 
	   {urgent_send: Outgoing.T -> unit}

     end = Tcp_Connection
  in
    open Internals
  end

  type connection_extension = tcp_connection_extension

  datatype connection = C of {send: unit -> unit,
			      abort: unit -> unit,
			      extension: connection_extension}
  datatype handler = H of Connection_Key.T
		  -> {connection_handler: connection -> unit,
		      data_handler: connection * unit -> unit,
		      status_handler: connection * unit -> unit}
  datatype session = S of {connect: Address.T * handler -> unit,
			   listen: Pattern.T * handler * unit -> listen,
			   extension: session_extension}

  exception Y

  exception Bad_Get_Tcb

  fun get_tcb _ = raise Bad_Get_Tcb

  fun add_to_window _ = raise Y

  fun start_user_timer _ = raise Y

  fun stop_user_timer _ = raise Y

  local

   fun match_ack actual registered = false

   val x = ref (SOME ())
   fun signal_send (send, ack) =
	case ! send of
	   NONE => ()
	 | _ => signal_send (send, ack)

  in 
   fun execute_actions (connection as Connection_Internals internals) =
	let fun loop () =
		  (signal_send (x, true);
		   loop ())	
       in loop ()
       end 

  end 

  fun tcp_send_packet (internals, packet, urgent) = raise Y

  fun close_or_abort _ = raise Y

  fun convert_connection _ = raise Y

  fun create_tcb (open_fun, key, conn_send) =
    let fun tcp_send _ = raise Y
	fun urgent_send _ = raise Y
	fun tcp_abort _ = raise Y
	val connection_internals =
	     Connection_Internals {tcp_send = ref tcp_send,
				   tcp_abort = ref tcp_abort,
				   urgent_send = ref urgent_send}
    in connection_internals
    end 

  fun do_connect (key, (conn as Conn.C {send, abort, extension}), open_fun) =
       let val internals = create_tcb (open_fun, key, send)
	   val Connection_Internals {urgent_send, ...} = internals
	   fun urgent_send_fun packet = (! urgent_send) packet
	   fun build_extension () =
		let val tcp_extension =
			   Tcp_Connection_Extension
			      {urgent_send = urgent_send_fun}
		in (tcp_extension, internals)
		end
       in extension := build_extension ()
       end
  fun no_op _ = ()
  val handler_exception_value = {connection_handler = no_op,
				 data_handler = no_op,
				 status_handler = no_op}

  fun tcp_handler (open_fun, tally_open, tally_close, H tcp_handler_fun) =
       let fun conn_handler_fun key =
		let val started = ref false
		    val tcp_connection_handler =
		         ref (no_op: connection -> unit)
		    fun start_connection conn =
			 if ! started then ! tcp_connection_handler
			 else
			  ((started := true;
			    do_connect (key, conn, open_fun);
			    let val {connection_handler, data_handler,
				     status_handler} =
				       tcp_handler_fun key
					 handle x => handler_exception_value
			    in tcp_connection_handler := connection_handler;
			       connection_handler
			    end)
			   handle x =>
				   (! tcp_connection_handler))
		    fun register conn =
			 if ! started then ! tcp_connection_handler
			 else
			  start_connection conn
		    fun conn_data_handler (conn as Conn.C {extension, ...},
					   packet) =
			 (register conn;
			  ())
		    fun conn_status_handler (conn as Conn.C {extension, ...},
					     status_value) =
			 (register conn;
			  ())
		    fun conn_connection_handler (connection as
						 Conn.C {send, abort,
							 extension}) =
			 (let val tcp_connection_handler = register connection 
			      val (tcp_extension,
				   Connection_Internals {tcp_send,
							 tcp_abort, ...}) =
				    ! extension
			      val tcp_connection = C {send = ! tcp_send,
						      abort = ! tcp_abort,
						      extension =
							 tcp_extension}
			  in tally_open ();
			     tcp_connection_handler tcp_connection;
			     tally_close ()
			  end)
		in {connection_handler = conn_connection_handler,
		    data_handler = conn_data_handler,
		    status_handler = conn_status_handler}
		end
       in Conn.H conn_handler_fun
       end

  fun tcp_session session_fn conn_session =  
       let val connection_count = ref 0;
	   fun tally_open () = connection_count := ! connection_count + 1
	   fun tally_close () =
		(connection_count := ! connection_count - 1;
		 if ! connection_count < 0 then () else ())
	   fun active_open (s, _, _) = s
	   fun tcp_connect (Conn.S {connect = conn_connect, ...})
			   (address, handler) =
		conn_connect (address,
			      tcp_handler (active_open, tally_open,
					   tally_close, handler))
	   fun tcp_listen (Conn.S {listen = conn_listen, ...})
			  (pattern, handler, count) = raise Y
	   fun tcp_extension (Conn.S {extension = conn_extension, ...}) =
		conn_extension
	   val tcp_session = S {connect = tcp_connect conn_session,
				listen = tcp_listen conn_session,
				extension = tcp_extension conn_session}
	   fun after_session () = ()
       in (session_fn tcp_session
	   before after_session ())
	  handle x => (after_session (); raise x)
       end

  fun session (session_fn: session -> 'a) =
       Conn.session (tcp_session session_fn)

 end 

*************
  (* another version from Stephen Weeks (3/27/98, x86-linux)
  val i = fn _ => 13
  val f : (unit -> 'a) * ('a -> int) -> int = fn _ => 14;
  functor G(type t) =
  struct
    val _ = f(fn () => (raise Bind) : t -> t,
	      i)
  end

Transcript:
  ...
	       listen:Pattern.T * handler * unit -> listen}
      val session : (session -> 'a) -> 'a
    end
  functor Connection : <sig>

  uncaught exception FPRegEA
    raised at: cps/generic.sml:98.67-98

Comments:
  An fwrap operation is being invoked on a lambda variable that is not 
  bound to a floating point type.
 [dbm, 12/6/99]
  Was marked as fixed in 110.4 [Zhong, 4/2/98].  Still broken on sparc/alpha in 110.24.
  (bug1360.1.sml and bug1360.2.sml result in "uncaught exception RegMap")

Fix: -
Test: bug1360.1.sml, bug1360.2.sml, bug1360.3.sml
Owner: Zhong
Status: open (alpha32-dunix)
----------------------------------------------------------------------
Number: 1361
Title: Equality between variables and constants in Word32.
Keywords: equality, word, literals
Submitter: George Russell   george@persimmon.com
Date: 02/27/98
Version: 110.2
System: Alpha Digital Unix 4.0 (564)
Subsystem: SML compiler
Severity: major
Problem:
Result of equality test is unexpected.
Code:
  val i = 0wx7fffffff : Word32.word;
  i = 0wx7fffffff ;
Transcript:
  Standard ML of New Jersey, Version 110.2, February 16, 1998 [CM; autoload enabled]
  - val i = 0wx7fffffff : Word32.word; 
  val i = 0wx7fffffff : Word32.word
  -   i = 0wx7fffffff ;
  val it = false : bool
Comments:
  Also happens on OSF3.2 but not x86-linux or sparc-solaris.

 [Lal, 2/27/98]
  Nearly, all operations on the alpha have a 32 bit variant, however
  comparisons don't. This is fine if everything is sign extended,
  because a LDL (Load Long) will sign extended into 64 bits and the
  upper bytes can be ignored. Overflows will generate a trap discarding
  incorrectly sign extended values, etc.

  The problem is that the code to load up 0wx7ffffff into a register
  does not have the correct sign extension. 

  So:
     val x = 0wx7fffffff : Word32.word;

  loads up 0wx7fffffff into a register and writes out the lower 32 bits
  even though the sign extension was wrong. 

  In comparing
	  x = 0wx7fffffff

  the problem shows up. I will try and get a fix for this into 110.3
  and as a patch for the release.

Fix:
Test: bug1361.sml
Owner: Lal
Status: fixed in 110.7.1 [George, 6/5/98]
----------------------------------------------------------------------
Number: 1362
Title: Real.toManExp o Real.fromManExp
Keywords: reals
Submitter: Daniel C. Wang   danwang@cs.princeton.edu
Date: 03/04/98
Version: 110 
System: Any/All Any Unix 
Subsystem: SML basis library
Severity: major
Problem:
  Bogus exponent returned from Real.toManExp causes Real.fromManExp to
  raise overflow.
Code:
Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled]
- Real.toManExp 0.0;
val it = {exp=~1022,man=0.0} : {exp:int, man:real}
- val id =  Real.fromManExp o Real.toManExp;
val id = fn : real -> real
- id 1.1
val it = 1.1 : real
- id 0.0;


uncaught exception overflow
  raised at: <file real64.sml.bin>
Transcript:
val it = {exp=~1022,man=0.0} : {exp:int, man:real}
- val id =  Real.fromManExp o Real.toManExp;
val id = fn : real -> real
- id 1.1
val it = 1.1 : real
- id 0.0;


uncaught exception overflow
  raised at: <file real64.sml.bin>
Comments:
  The basis definition is also ambigious about the actual semantics of these
  functions, so I'm not sure if these are really bugs or not. This probably 
  means there's a bug in the basis definition

 [dbm,3/4/98]
  See also bugs 1319 and 1228.
Fix:
(* Work Around *)
structure RealFix =
	    struct
		open Real
                val zero_r = 0.0
		fun toManExp x =
		    (if (Real.==(x,zero_r)) then {man=zero_r,exp=0}
		     else Real.toManExp x)
		fun fromManExp {man,exp} =
		    (if (Real.==(man,zero_r)) then zero_r
		     else (Real.fromManExp {man=man,exp=exp}))
	    end
Test: 
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1363
Title:       lexer doesn't detect EOF in string literals
Keywords:    compiler, lexer, EOF
Submitter:   Mikael Pettersson (mikpe@sophia.inria.fr)
Date:        03/06/98
Version:     110.2, probably many more
System:	     all
Severity:    minor
Problem:     lexer doesn't detect EOF in string literals
Code:	     
Transcript:  

brewer_1_echo -n 'val a = 5; "foo' | sml
Standard ML of New Jersey, Version 110.2, February 16, 1998 [CM; autoload enabled]
- val a = 5 : int
brewer_2_echo -n 'val a = 5; (*' | sml
Standard ML of New Jersey, Version 110.2, February 16, 1998 [CM; autoload enabled]
- val a = 5 : int
stdIn:17.12-17.14 Error: unclosed comment

Comments:    
Fix:	     

--- sml-nj/lex/ml.lex.~1~	Tue Feb 10 22:10:20 1998
+++ sml-nj/lex/ml.lex	Thu Mar  5 19:41:21 1998
@@ -39,11 +39,14 @@
       }
 type arg = lexarg
 type ('a,'b) token = ('a,'b) Tokens.token
-fun eof ({comLevel,err,stringstart,sourceMap, ...} : lexarg) = let
+fun eof ({comLevel,err,charlist,stringstart,sourceMap, ...} : lexarg) = let
       val pos = Int.max(!stringstart+2, SourceMap.lastChange sourceMap)
       in
 	if !comLevel>0
 	  then err (!stringstart,pos) COMPLAIN "unclosed comment" nullErrorBody
+	else if !charlist <> []
+	  then err (!stringstart,pos) COMPLAIN
+		   "unclosed string, character, or quotation" nullErrorBody
 	  else ();
 	Tokens.EOF(pos,pos)
       end	
Test: 
Owner: Andrew
Status: fixed in 110.3 [Zhong]
----------------------------------------------------------------------
Number: 1364
Title:       Mistakenly accepted datatype spec when signature matching.
Keywords:    datatype spec, matching
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        3/6/98
Version:     110.0.3
System:      x86-linux
Severity:    minor
Problem:     

  SML/NJ accepts the following program.  It should be rejected,
  because the specification requires type 't' to carry a
  constructor 'T', and it does not.

Code:        

  structure S :
  sig
     datatype t = T
  end =
  struct
     datatype u = T
     type t = u
  end;

Transcript:  
Comments:    
 [Zhong, 3/6/98]
  Dave, this bug is the side effect of your implementation 
  of "datatype replication". It works correctly in older versions,
  e.g. 109.24, etc. 
 [dbm, 8/14/98]
  The call of TU.unWrapDefStar in checkTycBinding in sigmatch.sml 
  is the cause of the bug.  At some point, replicated datatypes were
  represented as DEFtycs (eta-expansions of the original datatype),
  but this appears to have changed, and replicated datatypes are
  also bound as GENtycs.

  Note that the following variant of the above code (bug1364.2.sml) is legal.

    structure S :
    sig
       datatype t = T
    end =
    struct
       datatype u = T
       datatype t = datatype u
    end;

Fix:         
  Remove the call of TU.unWrapDefStar in checkTycBinding (sigmatch.sml).
  It is not necessary, because datatype replications are represented
  as GENtycs, not DEFtycs.
Test: bug1364.1.sml, bug1364.2.sml
Owner: dbm
Status: 110.9 [dbm, 8/14/98]
----------------------------------------------------------------------
Number: 1365
Title: datatype representation across functor boundary
Keywords: datatype representation
Submitter: Daniel C. Wang   danwang@cs.princeton.edu
Date: 04/13/98
Version: 110.x
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: 
Problem:
  There's a bug with the way the compiler is handling datatypes which
  carry unit as a value. The source code below reproduces the bug.
  I should get a list of all "A" but get one suprious "B" this seems to 
  happen only when passing a structure as a functor argument.

  I've verified this on 110.0.3 (Linux) and 110.5 (Solaris)
Code:
  signature S =
    sig
	type t
	datatype foo =
	    A of t | B 
	val a : unit -> foo
	val f : foo -> string
    end
    
  functor F(structure T:S) =
    struct
	fun f (T.A _) = "A"
	  | f (T.B) = "B"
    end

  structure S1 : S =
    struct
	type t = unit
	datatype foo = A of t
	             | B

	fun a () = A ()
	fun f (A _) = "A"
	  | f (B) = "B"
    end

  structure S2 : S =
    struct
	type t = int
	datatype foo = A of t | B
	  
	fun a () = A 1
	fun f (A _) = "A"
	  | f (B) = "B"
    end

  structure Test =
    struct
	structure T1 = F(structure T = S1)
	structure T2 = F(structure T = S2)

	val it = [(S1.f (S1.a()),T1.f (S1.a ())),
		  (S2.f (S2.a()),T2.f (S2.a ()))]
    end

Transcript:
  - use "broken.sml";     
  [opening broken.sml]
  GC #0.0.0.0.1.15:   (0 ms)
  signature S =
    sig
      type t
      datatype foo = A of t | B
      val a : unit -> foo
      val f : foo -> string
    end
  functor F : <sig>
  structure S1 : S
  structure S2 : S
  structure Test :
    sig
      structure T1 : <sig>
      structure T2 : <sig>
      val it : (string * string) list
    end
  val it = () : unit
  - Test.it;
  val it = [("A","B"),("A","A")] : (string * string) list

Comments:

Fix: 
Test: bug1365.1.sml
Owner: Zhong
Status: fixed in 110.6 and 110.0.4 [Zhong, 4/16/98]
----------------------------------------------------------------------
Number: 1366
Title:       opaque signatures and functor specs
Keywords:    opaque signatures, functor argument signatures
Submitter:   Manuel Fahndrich, manuel@cs.berkeley.edu
Date:        3/1/98
Version:     110
System:	     all
Severity:    major
Problem:     

Opaque signature matching of a structure containing a functor doesn't
handle the types of the functor arguments correctly. The functor
argument types cannot be made to match. It seems as if the compiler
uses the newly generated types in matching the functor argument
signature, instead of the transparent ones.

Code:	     

  structure Opaque :>
    sig
      type sort
      val base : sort
      functor Next(val s : sort) : sig val t : sort end
    end =
  struct
    type sort = int
    val base = 0
    functor Next(val s : sort) =
      struct
	val t = s + 1
      end
  end

Transcript:
/tmp/ml056YNw:1.1-22.6 Error: value type in structure doesn't match signature spec
    name: s
  spec:   int
  actual: ?.Opaque.sort

Comments:
  I don't know if this is supposed to work. If not, I'd
  like to know how opaque signature matching works with functor specs.

 [Zhong, 3/2/98]
  The above is actually not supposed to work. The reason is that
  functor signature matching follows the contravariant rule (just as when
  you perform subtyping on function types), so the argument structure of 
  the actual functor Next must have "less information" than that of the 
  abstract functor Next (in the signature).

  Unfortunately, under opaque signature matching, type "sort" in the functor 
  spec is an abstract type while type "sort" in the "actual" functor has type 
  "int", thus the above error message. 

  The above works under transparent signature matching, because "sort" in 
  the signature is equal to int as well.

 [Fahndrich, 3/2/98]
  Hmm, that's not a convincing argument. If it was solely due to
  contravariance, then the same reason would apply to functions, and it
  would be impossible to write

   structure Opaque :>
     sig
       type sort
       val base : sort
       val Next : sort -> sort
     end =
   struct
     type sort = int
     val base = 0
     fun Next (s : sort) = s + 1
   end

  There's gotta be more to it. Do you have an example that breaks
  the type system if what I expected to work is allowed?

 [Zhong, 3/2/98]
  Yes, theoretically, you could make your Next functor work, just handle
  it as the Next function above. But functor argument also contains
  type componentss in general, also, signature matching allows dropping 
  certain components, so the "subtyping" relationship in signature matching
  is real and more complex --- in contrast to the core-ML functions (which 
  have virtually none).

 [Fahndrich, 3/2/98]
  My example was the simplest possible. Of course I do want to use the
  generativity of types in my functor. To be more complete, there is one
  type T in the functor that I want to generate at each application:

  You still haven't told me why my example is disallowed. If I can match
  something using a transparent signature, then I should also be able to
  match it with an opaque signature, shouldn't I? Where are opaque
  signatures described? I thought they were a special feature of SML/NJ,
  but I can't find any info on it. Are opaque sigs part of the SML97
  definition? (I only have the original one).

      structure Opaque :>
	sig
	  type sort
	  val base : sort
	  functor Next(val s : sort) :
	    sig
	      type T
	      val t : sort
	    end
	end =
      struct
	type sort = int
	val base = 0
	functor Next(val s : int) =
	  struct
	    type T = string
	    val t = s + 1
	  end
      end

 [Fahndrich, 3/4/98]
  I talked to Mads Tofte about my problem. It turns out that this is
  part of SML/NJ's extension, even though not really a higher order
  functor. According to him, he sees no reason why my example shouldn't
  work. In particular, any structure that matches transparently should
  also match opaquely.

  Is there documentation about SML/NJ's signature matching procedure?

Fix:	     
Test: bug1366.1.sml
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1367
Title: *** Internal error: undefined sigTbl entry for signal 2 ***
Keywords: 
Submitter: George Russell   george@persimmon.com
Date: 03/10/98
Version: 110.2
System: Alpha Digital Unix 
Subsystem: SML compiler
Severity: minor
Problem:
  After an attempt at exportFn which failed because it wasn't
  able to open the file to write the image, the signals seem
  mucked up: EG

  > Signals.inqHandler Signals.sigINT;
  produces
  > *** Internal error: undefined sigTbl entry for signal 2 ***
Code:
  Please ask if you need more information.
Transcript:
Comments:
Fix:
Test: 
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1368
Title: 1+2 = 102 in IntInf
Keywords: IntInf parsing
Submitter: George Russell   george@persimmon.com
Date: 03/11/98
Version: 110.2
System: Alpha Digital Unix 
Subsystem: SML/NJ Library
Severity: minor
Problem:
1+2 = 102
Code:
  (IntInf.toString o valOf o IntInf.fromString) "1+2";
Transcript:
  (IntInf.toString o valOf o IntInf.fromString) "1+2";
  val it = "102" : string
Comments:
  I think NumScan is buggered.  I have been reworking all your IntInf
  code for my own purposes, cleaning it up somewhat and making it use
  Word32s throughout.  Do you want a copy?
Fix:
Test: bug1368.1.sml
Owner: jhr
Status: fixed in 110.6 (fix to be included in 110.0.4)
----------------------------------------------------------------------
Number: 1369
Title: Unbound exception on structure sharing violation
Keywords: modules, signatures, sharing, structure sharing
Submitter: Zhong Shao <shao-zhong@CS.YALE.EDU>
Date: 3/19/98
Version: 110
System: -
Severity: major 
Problem: 
  In 109.31, the compiler prints out:

      stdIn:39.24-39.39 Error: structure sharing violation: C # R

  which is correct, but starting from 109.32 (including 110), the
  compiler would raise Unbound exception ...
Code:
  signature COM =
  sig
    structure C: sig structure P: sig end end
  end

  signature SIG =
  sig
    structure R : COM
    structure C : COM
  end

  signature SIG2 =
  sig
    structure R : COM
    structure C : COM
    sharing C = R
  end

  functor AutoLoadFun (X : SIG2) = struct end

  functor H (S : SIG) =
  struct
    structure AutoLoad = AutoLoadFun (S)
  end

Transcript:
Comments:
Fix:
Test: bug1369.1.sml
Owner: dbm
Status: fixed in 110.6, 110.0.4
----------------------------------------------------------------------
Number: 1370
Title: op keyword pedantry  
Keywords: op 
Submitter: George Russell (george@persimmon.com)
Date: 26/03/1998
Version: 110.2
System:	Alpha/Digital Unix
Severity: (very) minor
Problem: op isn't parsed correctly
Code: val k=op Int.precision;
Transcript: (SML doesn't consider this a complete statement)
Comments:    
Fix:	     
Test: bug1370.sml
Owner: dbm, Andrew
Status: open
----------------------------------------------------------------------
Number: 1371
Title: signal-sysdep.h on HPUX10.01
Keywords: 
Submitter: Anthony Shipman   als@tusc.com.au
Date: 03/27/98
Version: 110.0.3
System: HPPA HPUX 10.01
Subsystem: Installation
Severity: major
Problem:
  The file src/runtime/mach-dep/signal-sysdep.h does not compile.

  The following link may be missing on some machines.  It was on mine.
  /lib/cpp.ansi -> /opt/langtools/lbin/cpp.ansi
Code:
Transcript:
Comments:
Fix:
  In src/runtime/mach-dep/signal-sysdep.h at line 306 insert 

    #ifdef SS_WIDEREGS /*if not on HPUX 10.01 */
    #endif

    around the block of defines for the sc_ symbols.

Test: 
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1372
Title: missing links in smlnj-110.0-3.i386.rpm
Keywords: rpm,linux,package
Submitter: Gergely Buday   gergoe@math.bme.hu
Date: 03/30/98
Version: 110.0.3
System: x86 Linux Red Hat 4.1
Subsystem: Installation
Severity: cosmetic
Problem:
  When I installed the package

    smlnj-110.0-3.i386.rpm

  I typed sml and nothing was started. The problem is
  /usr/share/smlnj/bin is not in the PATH. Obviously,
  it's trivial to make the symlinks, but rpms usually do that.
  See my fix for the problem. It's a matter of taste, but for me,
  links should go to /usr/local/bin.
     And, the documentation files are awaited to /usr/doc/smlnj-<version>.

Code:
Transcript:
  garfield:~$ rpm -ivh smlnj-110.0-3.i386.rpm
  ...
  garfield:~$ sml
  bash: sml: command not found                
Comments:
  Otherwise, thanks for building an rpm!
  It's easier to convince the sysadm to install that than to
  compile all the stuff :-)
 [Blume, 5/1/98]
  Since we don't even officially support the RPM package, I would suggest
  we drop bugs 1372 and 1373 from the list.  I don't have a Linux box
  with an older version of the C libraries, so there is nothing I can do
  about 1373.  Personally, I also don't like to have those links in
  /usr/local/bin that 1372 claims are "missing", so to me this is "not a
  bug".

Fix:
  ln -s /usr/share/smlnj/bin/.run-sml     /usr/local/bin/sml
  ln -s /usr/share/smlnj/bin/.run-sml     /usr/local/bin/ml-lex
  ln -s /usr/share/smlnj/bin/.run-sml     /usr/local/bin/ml-yacc
  ln -s /usr/share/smlnj/bin/.run-sml     /usr/local/bin/ml-burg
  ln -s /usr/share/smlnj/bin/.run-sml     /usr/local/bin/sml-cm                  
Test: 
Owner: Matthias
Status: not a bug
----------------------------------------------------------------------
Number: 1373
Title: smlnj-110.0-3.i386.rpm works only with libc.so.6
Keywords: rpm,linux, libc
Submitter: Gergely Buday   gergoe@math.bme.hu
Date: 04/01/98
Version: 110
System: x86 Linux <= Red Hat 4.2
Subsystem: Installation
Severity: minor
Problem:
  trying to install that rpm on a Red Hat 4.2,
  it complains about missing libc.so.6. Unfortunately,
  this can be cured only by upgrading to Red Hat 5.0.
  Or, if you put src.rpm on the ftp server. Would you like to do it?
  Me, and other 4.2 users would be happy.
Code:
Transcript:
Comments:
 [Blume, 5/1/98]
  Since we don't even officially support the RPM package, I would suggest
  we drop bugs 1372 and 1373 from the list.  I don't have a Linux box
  with an older version of the C libraries, so there is nothing I can do
  about 1373.  Personally, I also don't like to have those links in
  /usr/local/bin that 1372 claims are "missing", so to me this is "not a
  bug".
Fix:
Test: 
Owner: Matthias
Status: not a bug
----------------------------------------------------------------------
Number: 1374
Title:       Datatype replication causes nonexhaustive match error.
Keywords:    datatype replication
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:	     4/3/97
Version:     110.0.3
System:      x86-linux
Severity:    
Problem:     
  Ill-formed datatype declaration causes nonexhaustive match failure
  in elaborate/elabtype.
Code:        
  datatype t = T
  and u = datatype t
Transcript:  
  uncaught exception nonexhaustive match failure
    raised at: elaborate/elabtype.sml:232.43
Comments:    
Fix:         
  Added Repl case to preprocess function in elabDATATYPEdec (elabtype.sml).
Test: bug1374.1.sml
Owner: dbm
Status: fixed in 110.9, 110.0.4 [dbm, 8/14/98]
----------------------------------------------------------------------
Number: 1375
Title:       Word31.fromString disagrees with Basis Library specification
Keywords:    Word31.fromString
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        4/8/98
Version:     110.0.3
System:      x86-linux
Severity:    
Problem:     
 
  The expression:  Word31.fromString "0wa" 
  returns: SOME 0wxa
  
  I believe that it should return NONE, since the specification says
  that the string must be of the form: (0wx|0wX|0x|0X)?[0-9a-fA-F]+

  This behavior is confusing, since the expression: 0w123
  yields a different word than the expression: Word31.fromString "0w123"

  Here is another bug along the same lines:

    - Word31.fromString "100000000"; (* JHR: should return NONE *)

    uncaught exception overflow
      raised at: boot/num-scan.sml:136.50-136.58

Code:        
Transcript:  
Comments:    
  It seems strange to me that the syntax for arguments to fromString is
  not the same as (or a superset of) the syntax for constants in the
  language.   Is there a reason for this?
 [jhr, 4/9/98]
  We decided that we didn't want to deal with the "0x" and "0w" prefixes
  in the fromString functions, which forces a choice of radix.  Otherwise,
  fromString accepts a larger set (e.g., "-" is accepted as a sign).
Fix:         
Test: bug1375.1.sml, bug1375.2.sml
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1376
Title: cycle in datatype specs not detected
Keywords: signatures, sharing, equality, dependency cycle
Submitter: Zhong Shao <shao@rum.systemsz.cs.yale.edu>
Date: 4/4/98
Version: 110.4
System: -
Severity: major 
Problem: 
  bug109.sml now causes a "dependency cycle in instantiate" error
Code:
Transcript:
  signature EQSIG =
    sig
      type r
      datatype s = S of r
      datatype t = T of s
      sharing type t = r
    end
  bug109.sml:12.23-12.30 Error: operator and operand don't agree [equality type required]
    operator domain: ''Z * ''Z
    operand:         X.t * X.t
    in expression:
      x = x
Comments:
  Should report "dependency cycle in instantiate"
Fix:
Test: bug109.sml
Owner: dbm
Status: fixed in 110.5 [Zhong]
----------------------------------------------------------------------
Number: 1377
Title: OS.FileSys.tmpName differs in unspecified behaviour on Windows and Unix
Keywords: basis
Submitter: Andrew Kennedy   andrew@persimmon.co.uk
Date: 04/21/98
Version: 110.0.3
System: Any/All Any Unix 
Subsystem: SML basis library
Severity: minor
Problem:
  OS.FileSys.tmpName () differs between Unix and Windows in its behaviour
  when the current directory is not writeable. On Unix the /tmp directory
  is used so guaranteeing writeability, on Windows the current directory
  is used so that it raises an exception if this directory is not
  writeable. This should at least be mentioned in the basis spec. BETTER:
  use the temporary directory on Windows that is set by the environment
  variable TMP (also TEMP).
Code:
Transcript:
Comments:
 [jhr, 4/21/98]
  Note, OS.FileSys.tmpName does not create a file, just a filename.  I agree
  that the Windows implementation should probably use the standard temporary
  directory to generate these names, but this still not a guarantee that the
  file can be written.
 [Lorenz, 4/21/98]
  The implementation has been changed to call the win32 GetTempPath
  function to fill in the path slot for the GetTempFile function.
  >From the documentation we have, it's unclear where GetTempPath
  gets the path, but a good guess is that it looks for TMP,TEMP in the 
  environment.  This modification will be reflected in a release shortly.
Fix:
  fixed to use windows' notion of the temp directory
  as a prefix for the temp filename.
  Use environment variable TMP or TEMP on Windows systems.
Test: 
Owner: jhr, Lorenz
Status: fixed in 110.6, 110.0.4
----------------------------------------------------------------------
Number: 1378
Title: Incorrect behaviour of String.from{C}String on nonprintable chars
Keywords: basis
Submitter: Andrew Kennedy   andrew@persimmon.co.uk
Date: 04/21/98
Version: 110.0.3
System: Any/All Any Unix 
Subsystem: SML basis library
Severity: minor
Problem:
  According to the spec, String.fromString and String.fromCString should
  just "stop" when reaching a non-printable character or illegal escape
  sequence. In SML/NJ, they return NONE.
Code:
String.fromString "a\n"
Transcript:
- String.fromString "a\n";
val it = NONE : string option
Comments:
Fix:
Test: 
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1379
Title: CM write permission error when CM (unnecessarily?) recompiles lib sources
Keywords: "cm", "permissions", "openOut", "io", "dependencies"
Submitter: Rona Machlin   rona@saul.cis.upenn.edu
Date: 04/27/98
Version: 110.0.3
System: Sparc SunOS 5.5.1
Subsystem: Compilation manager (CM)
Severity: critical
Problem:
  CM seems to recompile library sources unnecessarily.  When the user
  doesn't have write permission to the existing bin, this error becomes
  critical.
Transcript:
  gradine:/mnt/saul/home/rona/arrays/work/tmpbug> sml-cm
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled]
  - CM.make();
  [starting dependency analysis]
  [scanning sources.cm]
  [checking CM/sparc-unix/sources.cm.stable ... not usable]
  [scanning /pkg/sml-110/lib/smlnj-lib.cm -> /pkg/sml-110/src/smlnj-lib/Util/sources.cm]
  [checking /pkg/sml-110/src/smlnj-lib/Util/CM/sparc-unix/sources.cm.stable ... not usable]
  GC #0.0.0.0.1.9:   (0 ms)
  [parsing /pkg/sml-110/src/smlnj-lib/Util/atom-binary-map.sml]
  [writing /pkg/sml-110/src/smlnj-lib/Util/CM/DEPEND/atom-binary-map.sml failed]
Comments:
 [Blume, 5/1/98]
  I don't think that 1379 is actually a bug in CM.  It more looks like a
  problem with the local library installation that Rona was using.
  Also, the error does not pertain to the writing of binfiles but to the
  writing of dependency files.  CM only does that if it finds a
  dependency file to be outdated.  My guess is that somebody "moved" the
  library by copying - something that may have messed up the time
  stamps...

Fix:
Test: 
Owner: Blume
Status: open
----------------------------------------------------------------------
Number: 1380
Title: Scan.[s]scanf does not allow ordinary [ character 
Keywords: library
Submitter: Emden R. Gansner   erg@research.att.com
Date: 04/28/98
Version: 110
System: Any/All Any Unix 
Subsystem: SML/NJ Library
Severity: minor
Problem:
  There is no escape mechanism for specifying literal [ characters
  in format strings. Actually, [ should be treated as a literal unless
  preceded by a % character, following the C conventions.
Code:
Transcript:
Comments:
Fix:
Test: 
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1381
Title: ml-yacc looping
Keywords: ml-yacc, EOF
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 2/5/98
Version: 110
System: -
Severity: major 
Problem: 
  [Mark Pichora <mpichora@Theory.Stanford.EDU>]
  I have discovered that parser2.sml (SMLNJ source file in ml-yacc)
  has a bug in it.  I can't pin the bug down more than to say that
  parser1.sml works well in its place (the version that has no
  error recovery).  For some reason the parser2.sml gets stuck
  sometimes when it finds an error in the input.  

  Have you noticed this problem at all in the other parsers
  used in STeP?  The bug is manifested by the parser2.sml 
  continually calling lex() even after seeing an EOF symbol
  when parser2.sml is doing error recovery.  I may look into
  the problem further, but for now parser1.sml does the job
  for the purposes of testing large files...

  [jhr]
  There is a bug in the error recovery that can send it into an
  infinite loop shifting EOF. 

  The workaround is to make add

    %noshift EOF

  to the grammar.

Code:
Transcript:
Comments:
Fix:
Test: tests.special/bug1381
Owner: Andrew?
Status: open
----------------------------------------------------------------------
Number: 1382
Title: space leak in CML
Keywords: continuations
Submitter: John Reppy   jhr@research.bell-labs.com
Date: 05/04/98
Version: 110.0.1
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: critical
Problem:
Changes in the way that the compiler handles continuations has
introduced a space leak in CML code, by breaking makeing
choice non-tail recursive.
Code:
  local
    open CML
  in
  fun test () = let
	val ch1 = channel ()
	val ch2 = channel ()
	fun rloop () = select [
		wrap (recvEvt ch1, fn _ => rloop()),
		wrap (recvEvt ch2, fn () => ())
	      ]
	fun sloop i = (send(ch1, i); sloop(i+1))
	in
	  spawn rloop;
	  sloop 0
	end
  fun doit () = RunCML.doit(test, SOME(Time.fromMilliseconds 100))
  end

Transcript:
- doit();
GC #0.0.0.1.4.105:   (20 ms)
GC #0.0.0.2.5.128:   (220 ms)
GC #0.0.1.3.6.151:   (310 ms)
GC #0.1.2.4.7.174:   (400 ms)
GC #1.2.3.5.8.197:   (570 ms)
GC #1.3.4.6.9.220:   (60 ms)
GC #1.4.5.7.10.243:   (70 ms)
GC #2.5.6.8.11.266:   (860 ms)
GC #2.6.7.9.12.289:   (70 ms)
GC #2.7.8.10.13.312:   (70 ms)
GC #2.8.9.11.14.335:   (70 ms)
GC #2.9.10.12.15.358:   (80 ms)
GC #2.10.11.13.16.381:   (80 ms)
GC #2.11.12.14.17.404:   (80 ms)
GC #2.12.13.15.18.427:   (70 ms)
GC #3.13.14.16.19.450:   (1500 ms)
GC #3.14.15.17.20.473:   (90 ms)
GC #3.15.16.18.21.496:   (80 ms)
GC #3.16.17.19.22.519:   (70 ms)
GC #3.17.18.20.23.542:   (70 ms)
GC #3.18.19.21.24.565:   (80 ms)
GC #3.19.20.22.25.588:   (80 ms)
...
Comments:
  This bug first appeared in 110.0.1 (it did not occur in 110.0.0) and
  is present in 110.0.3. Note that there were no changes to the CML
  source between 109.35 and 110.0.1.

Fix:

Test: tests.special/bug1382.sml
Owner: Zhong?
Status: fixed in 110.6, 110.0.4
----------------------------------------------------------------------
Number: 1383
Title:       Basis Library Specification of Char.toCString and String.toCString
Keywords:    toCString
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        5/7/98
Version:     110.0.3
System:      x86-linux
Severity:    
Problem:     

Char.toCString(chr 0) returns \0 instead of \000

This causes String.toCString to have strange behavior on strings
containing embedded null characters followed by integer digits.

For example,

  String.toCString("hello\000123there")

produces
  
  hello\0123there

which is a C string of length 12 instead of length 5.

I propose that the Basis Library specification be changed so that
Char.toString, when it returns an octal escape sequence, always
returns a sequence of three octal digits.

Code:        
Transcript:  
Comments:    
  Reppy and Berry have agreed; spec will change accordingly.
Fix:         
Test: bug1383.1.sml
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1384
Title: incorrect complaint about "inconsistent structure definitions"
Keywords: modules, signatures, where structure defns
Submitter: Mikolaj Konarski <mikon@mimuw.edu.pl>
Date: 5/8/98
Version: 110.0.3
System: -
Severity: major
Problem: 
  The following code should elaborate, but doesn't.
Code:
  signature CAT = sig datatype t = c end;

  signature L_F =
  sig
    structure Cat : CAT
  end;

  signature TRANSLATOR =
  sig
    structure Cat : CAT
    structure LF : L_F 
	where Cat = Cat
  end;

  functor Translator
      ( structure Cat : CAT
        structure LF : L_F 
	    where Cat = Cat ) :> TRANSLATOR
                                     where Cat = Cat
                                     where LF = LF
                                     =
  struct
    structure Cat = Cat
    structure LF = LF
  end;
Transcript:
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled]
  - [opening /home/m/Dule/bug.sml]
  signature CAT = sig datatype t = c end
  signature L_F = sig structure Cat : sig datatype t = c end end
  signature TRANSLATOR =
    sig
      structure Cat : sig datatype t = c end
      structure LF : sig structure Cat : <sig> end
    end
  /home/m/Dule/bug.sml:15.11-26.6 Error: possibly inconsistent structure definitions at: LF.Cat *)

Comments:
  Same as bug 1354
Fix: (see bug 1354)
Test: bug1384.1.sml
Owner: dbm
Status: fixed in 110.9, 110.0.4 [dbm, 8/13/98]
----------------------------------------------------------------------
Number: 1385
Title: functor defn including "where" structure defs shouldn't elaborate
Keywords: modules, signatures, functors, where structure
Submitter: Mikolaj Konarski <mikon@mimuw.edu.pl>
Date: 5/8/98
Version: 110.0.3
System: -
Severity: major
Problem: 
  Following code elaboarates, but shouldn't, since the definition spec
  in LF substructure of TRANSLATOR signature is not satisfied (Cat and LF.Cat
  in the functor argument are unrelated).
Code:
  signature CAT = sig datatype t = C end;

  signature L_F =
  sig
    structure Cat : CAT
  end;

  signature TRANSLATOR =
  sig
    structure Cat : CAT
    structure LF : L_F 
	where Cat = Cat
  end;

  functor Translator
      ( structure Cat : CAT
	structure LF : L_F ) : TRANSLATOR
				   where Cat = Cat
				   where LF = LF
				   =
  struct
    structure Cat = Cat
    structure LF = LF
  end;
Transcript:
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled]
  - [opening /home/m/Dule/bug2.sml]
  signature CAT = sig datatype t = c end
  signature L_F = sig structure Cat : sig datatype t = c end end
  signature TRANSLATOR =
    sig
      structure Cat : sig datatype t = c end
      structure LF : sig structure Cat : <sig> end
    end
  functor Translator : <sig>
  val it = () : unit *)
Comments:
 [dbm, 8/17/98]
  The basic bug is that signature matching is not verifying structure
  definitional specs.  bug1385.3.sml is a more direct example.
  
  After fix of 1354, the secondary definition of LF.Cat in the
  functor result is not detected and doesn't produce a warning
  because the result signature is not instantiated.  bug1385.4.sml
  is a variant that declares something like the functor result signature,
  and it generates a secondary definition warning.

Fix:
  In matchStr1 (sigmatch.sml), the call of matchDefStr in the STRspec
  case needs to be passed the element list for this specs signature, not
  the inherited sigElements from the containing signature.
Test: bug1385.1.sml, bug1385.2.sml, bug1385.3.sml
Owner: dbm
Status: fixed in 110.0.3, 110.9 [dbm, 8/17/98]
----------------------------------------------------------------------
Number: 1386
Title: redefinition of a type spec is not detected
Keywords: signatures, where type, where structure
Submitter: Mikolaj Konarski <mikon@mimuw.edu.pl>
Date: 5/8/98
Version: 110.0.3
System: -
Severity: major
Problem: 
  The code is incorrect, and should generate an error, but not the
  error that is currently generated.  The type Cat.cat in signature L_F
  is defined by the where type definition, and cannot be redefined
  (indirectly) but the "where Cat = Cat" definition in the parameter
  specification of the Translator functor.  This redefinition should
  have been detected, causing a different error, something like

    - signature S =
    = sig
    =   type t = int
    = end
    = where type t = int;
    stdIn:17.1-21.19 Error: where type defn applied to definitional spec: t
Code:
  signature CAT = 
  sig 
      eqtype cat 
      val c : cat
  end;

  signature L_F =
  sig
    eqtype t
    structure Cat : CAT
	where type cat = t
    val r : t
  end;

  functor Translator
      ( structure Cat : CAT
        structure LF : L_F where Cat = Cat ) =
  struct
      val w = (Cat.c = LF.r)
  end;
Transcript:
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998...
  - [opening /home/m/Dule/bug3.sml]
  signature CAT =
    sig
      eqtype cat
      val c : cat
    end
  signature L_F =
    sig
      eqtype t
      structure Cat :
	sig
	  type cat = t
	  val c : cat
	end
      val r : t
    end
  /home/m/Dule/bug3.sml:19.15-19.29 Error: operator and operand don't agree [tycon mismatch]
    operator domain: ?.cat * ?.cat
    operand:         ?.cat * ?.t
    in expression:
      Cat.c = LF.r *)
Comments:
 [dbm, 8/17/98]
  This is related to bug 1354.  The fix for that bug ignores the
  secondary redefinition of LF.Cat.c caused by the "where Cat = Cat"
  clause, generating a warning message.  This warning message is
  incorrect because of the "<empty spath>" used to describe the
  tycon spec in question.  It should be "cat", or "Cat.cat".  See bug 1420.
 
    test/bugs/bug1386.1.sml:17.9-22.4 Warning: multiple defs at tycon spec: <empty spath>
	(secondary definitions ignored)
    test/bugs/bug1386.1.sml:21.13-21.27 Error: operator and operand don't agree [tycon mismatch]
      operator domain: ?.cat * ?.cat
      operand:         ?.cat * ?.t
      in expression:
	Cat.c = LF.r

  the type error message is still generated because the redefinition
  of LF.Cat.cat does not take effect.
Fix: see bug 1354
Test: bug1386.1.sml
Owner: dbm
Status: fixed in 110.9, 110.0.4 [dbm]
----------------------------------------------------------------------
Number: 1387
Title: scanning hex numbers from strings
Keywords: StringCvt
Submitter: Satish Chandra   schandra@lucent.com
Date: 05/07/98
Version: 110 (Dec 7,97)
System: Mips Irix 6.4
Subsystem: SML basis library
Severity: minor
Problem:
  There seems to be a problem in scanning hex numbers from strings. (see 
  comments below).

Code:
  StringCvt.scanString (LargeInt.scan StringCvt.HEX) "0xffffffff";

Transcript:
  uncaught exception overflow
    raised at: boot/num-scan.sml:255.12-255.20
Comments:
  Same problem if you try to scan "0x80000000", which is LargeInt.minInt.
  However maxInt, i.e. "0x7fffffff" scans just fine. The problem appears
  only if the MSB of the word should be set.
Fix:
Test: bug1387.1.sml
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1388
Title:       SML/NJ does not follow Basis Library Spec on div, mod, quot, rem
Keywords:    div mod quot rem
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        5-7-98
Version:     110.0.3
System:      x86-linux
Severity:    major
Problem:     

  SML/NJ does not produce results that agree with the Basis Library
  Spec when div, mod, quot, or rem is applied to (minInt,~1).  Here is
  a table of expressions, the result that SML/NJ returns, and my
  understanding of what the Basis Library Spec says.

  Expression                                 SML/NJ       Basis Library Spec
  ----------------------------------------   ----------   --------------------

  Int31.div(Option.valOf Int31.minInt, ~1)   Overflow     Overflow
  Int31.mod(Option.valOf Int31.minInt, ~1)   Overflow     0
  Int31.quot(Option.valOf Int31.minInt, ~1)  Overflow     Overflow
  Int31.rem(Option.valOf Int31.minInt, ~1)   Overflow     0

  Int32.div(Option.valOf Int32.minInt, ~1)   Div          Overflow
  Int32.mod(Option.valOf Int32.minInt, ~1)   0            0
  Int32.quot(Option.valOf Int32.minInt, ~1)  Div          Overflow
  Int32.rem(Option.valOf Int32.minInt, ~1)   Div          0

Comments:    
 [dbm,5/11/98]
  Different incorrect results returned on mipseb and sparc.
Fix:         
Test: bug1388.1.sml
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1389
Title: core dump on Sparc/Solaris
Keywords: code generation
Submitter: Steve Brackin <brackin@arca.com> (Elsa Gunter, John Reppy)
Date: 5/14/98
Version: 110.0.3
System: sparc-solaris
Severity: critical (core dump!)
Problem: 
  HOL and SML code showing a problem in hol90.10 and/or smlnj110.0.3, in
  the form of gzipped, uuencoded text, is enclosed.  It might be related
  to your earlier problem with swap space, but maybe not -- I get the
  problem on a Sun Ultra 1 running Solaris 2.5.1 with 286,560 1024-blocks
  of swap space.

  After you uudecode and gunzip the appropriate sections of this note,
  you should have the files bgny.sml, decide.sml, and main.hsc.  If you
  put all three of these files in one UNIX directory, go there, and type

  hol90 < bgny.sml

  where "hol90" invokes hol90.10 made with smlnj110.0.3, then this
  produces a hol90 executable named phol.sparc-solaris.  If you then type

  hol90 -u ./phol.sparc-solaris < main.hsc

  then this outputs the standard HOL90 banner, the messages

  Creating theory main

  Declaring theory "main"

  Theory "bgny" already consistent with disk, hence not exported
  Bus Error - core dumped
  Killed

  Files bgny.sml and decide.sml together define a HOL90 implementation of
  the BGNY belief logic and functions for automatically constructing
  proofs in this logic of desired properties of particular cryptographic
  protocols;  they are two of the three pieces of the Automatic
  Authentication Protocol Analyzer (AAPA).  File main.hsc defines a
  theory over the BGNY logic of the main-sequence protocol from
  CyberCash, Inc, a series of messages sent between customer software,
  merchant software, and CyberCash, for making secure and authenticated
  credit-card purchases.  File main.hsc was produced by a specification
  translator, the third piece of the AAPA;  you do not need to have this
  translator, since how it produced main.hsc is irrelevant to the
  hol90.10/smlnj110.0.3 problem.

  The thing about these files that's most likely to be relevant is that
  they're huge;  CyberCash's main-sequence protocol is the largest, most
  detailed, protocol to ever be formally modeled and analyzed.  None of
  my other examples caused a core dump.  But all of my examples,
  including the main-sequence protocol one, ran successfully under
  hol90.8 and smlnj109.  All my examples also ran significantly faster
  under hol90.8/smlnj109 -- 15.9 rather than 21.3 seconds in a typical
  small example.  The computations I will need to perform in the future
  will probably be much more demanding than even the main-sequence
  protocol example;  I will use a much more detailed logic for making
  inferences, and my company hopes to develop the AAPA into a commercial
  product.  I'd appreciate anything you could do to find and fix the
  problem that's causing the core dump, and if possible to also speed up
  the computations.

Code:
  See /home/sml/Dev/hol-bug
Transcript:
Comments:
 [jhr, 5/14/98]
  With help from Elsa, I've been able to reproduce the HOL
  core-dump bug on our Sparc/Solaris machine.  I ran the HOL
  preprocessor by hand and then fed it into the HOL image
  running under the debugger.  The bug looks like
  a compiler bug.

  (gdb) run @SMLload=phol < main.out
  Starting program: /usr/local/sml/110.0.3/src/runtime/objs/run.sparc-solaris @SMLload=phol < main.out
  ...
  GC #3.42.49.76.213.47451:   (10 ms)
  GC #3.42.49.76.214.47479:   (10 ms)
  GC #3.42.49.76.215.47522:   (0 ms)

  Program received signal SIGBUS, Bus error.
  0xef362c30 in ?? ()
  (gdb) where
  #0  0xef362c30 in ?? ()
  #1  0xedda3cd8 in ?? ()
  #2  0x17e54 in RunML (msp=0x4dcc0) at ../kernel/run-ml.c:84
  #3  0x17cfc in LoadML (loadImage=0xeffffc1f "phol", heapParams=0x4d1e8)
      at ../kernel/load-ml.c:38
  #4  0x161f0 in main (argc=2, argv=0xeffffacc) at ../kernel/main.c:76
  (gdb) disassemble  0xef362c20  0xef362c40
  Dump of assembler code from 0xef362c20 to 0xef362c40:
  0xef362c20 <_END_+4012989004>:  add  %g6, 4, %l5
  0xef362c24 <_END_+4012989008>:  add  %g6, 0xc, %g6
  0xef362c28 <_END_+4012989012>:  ld  [ %i1 + 0xff8 ], %o3
  0xef362c2c <_END_+4012989016>:  mov  0x82, %o5
  0xef362c30 <_END_+4012989020>:  ld  [ %o3 + 0xc ], %o2	<==== CORE DUMP HERE
  0xef362c34 <_END_+4012989024>:  mov  1, %o4
  0xef362c38 <_END_+4012989028>:  st  %o4, [ %g6 + 4 ]
  0xef362c3c <_END_+4012989032>:  st  %o5, [ %g6 ]
  End of assembler dump.

  The value of $o3 looks a lot like an object descriptor:
  (gdb) print /x $o3
  $5 = 0x82

  The register %i1 is pointing into the allocation space.

  I don't have any ideas about how to track this down.

Fix:
Test: (/home/sml/Dev/hol-bug)
Owner: Lal, jhr?
Status: obsolete (new MLRISC sparc code generator)
----------------------------------------------------------------------
Number: 1390
Title: incorrect parsing of sigb sequences
Keywords: parsing, grammar, signatures, where type, shift-reduce conflict
Submitter: Gerhard Schneider <gesc@ps.uni-sb.de>
Date: 5/15/98
Version: 110.0.3
System: -
Severity: minor 
Problem: 
  When implementing a parser for SML 97 we've found
  what we consider to be a discrepancy between the
  language definition and the implementations we have
  at our disposal.

  SML/NJ & MLWorks are able to parse this

  signature X =
      sig
	  type i;
	  type j;
	  val f : i -> j;
      end
  where type i = int
  where type j = real;

  SML/NJ parses but MLWorks fails

  signature X =
      sig
	  type i;
	  type j;
	  val f : i -> j;
      end
  where type i = int and type j = real;

  Both SML/NJ and MLWorks fail

  signature X =
      sig
	  type i;
	  type j;
	  val f : i -> j;
      end where type i = int
    and Y =
      sig
	  type t;
      end;  

  The question is:
  Is this a bug in the definition (Figure 19 in Appendix A),
  in the imlementations or have we misunderstood this?

  Furthermore, since this doesn't seem to be of practical
  importance, why has this derived form been included in the
  definition.
Code:
Transcript:
Comments:
 [dbm, 5/15/98]
  You could characterize this as an example of poor syntax design
  (I would).  We didn't realize until too late that the addition
  of the "where type" construct introduced another shift-reduce
  conflict into the LALR1 (approximate) grammar.  More precisely, in

    signature X =
	sig
	   type i;
	   type j;
	   val f : i -> j;
	end where type i = int
      and ...

  the "and" can be followed either by another type definition or by
  another signature declaration.  The yacc-style parser used in SML/NJ
  resolves the shift-reduce conflict by shifting the "and", which is why
  the version followed by a second type definition parses, but the one
  followed by a second signature declaration doesn't.  I would have
  prefered to fix this problem by dropping the useless

    signature S1 = ...
      and S2 = ...

  form.

  This has to be categorized as a bug in SML/NJ, but a fairly
  low priority one.  Someday we may fix it.  In the meantime, just
  write

    signature S1 = ...
    signature S2 = ...

Fix:
Test: bug1390.1.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1391
Title: Compiler bug - TransTypes: unexpected wildcard-type in toTyc
Keywords: datatype replication
Submitter: Edgar Lederer   lederer@ifi.unibas.ch
Date: 05/20/98
Version: 110.0.3
System: Sparc Solaris 
Subsystem: SML compiler
Severity: major
Problem:
  The bug occurs when using datatype replication.
  See source code and transcript.
Code:
  signature SIG1 =
  sig
    datatype ('a,'b) dt = C of ('a,'b) dt
  end

  signature SIG2 =
  sig
    structure Struct1 : SIG1
    datatype dt = datatype Struct1.dt   (* datatype replication *)
  end

  signature SIG3 =
  sig
    structure Struct2 : SIG2
    val f : (unit, unit) Struct2.Struct1.dt -> unit   (* OK! *)
  (*
    val f : (unit, unit) Struct2.dt -> unit           (* Problem! *)
  *)
  end

  functor Fun (structure Struct2 : SIG2) : SIG3 =
  struct
    structure Struct2 = Struct2
  (*
    fun f (Struct2.Struct1.C _) = ()   (* OK! *)
  *)
    fun f (Struct2.C _) = ()           (* Problem! *)
  end

Transcript:
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM; autoload enabled]
  - use "bug.sml";
  [opening bug.sml]
  Error: Compiler bug: TransTypes: unexpected wildcard-type in toTyc

Comments:
Fix:
 [dbm] corrected bogus definition of mkStrict in typesutil.sml.
Test: bug1391.1.sml
Owner: dbm, Zhong
Status: fixed in 110.7.? and 110.0.4 [dbm, 6/16/98]
----------------------------------------------------------------------
Number: 1392
Title: bad regions for "match nonexhaustive" messages
Keywords: error messages, regions, match nonexhaustive
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 5/20/98
Version: 110.0.2
System: -
Severity: medium 
Problem: 
  The source location given for `match nonexhaustive' error messages
  appears to be the structure containing the offending function, rather
  than the function itself.  It would be more useful if the offending match
  were isolated more precisely.
Code:
Transcript:
  Standard ML of New Jersey, Version 110.0.3, January 30, 1998
  - use "tests/bug1392.1.sml";
  [opening tests/bug1392.1.sml]
  tests/bug1392.1.sml:4.1-14.4 Warning: match nonexhaustive
	    nil => ...

  structure S :
    sig
      val f : 'a list -> int
      val x : int
      val y : int
      val z : int
    end
  val it = () : unit
Comments:
Fix:
Test: bug1392.1.sml, bug1392.2.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1393
Title:       Overflow in std_out, memory leak while printing?
Keywords:    PervEnv/IO
Submitter:   Nikolaj S. Bjorner nikolaj@cs.stanford.edu
Date:        May 20'th 98
Version:     110.5
System:      sparc-solaris2.5
Severity:    critical
Problem:     After running printing to std_out for some hours
	     with diagnostic information I got the following feedback:

  uncaught exception Io: output failed on "<stdOut>" with exception overflow
  /step/sml/bin/sml-cm: Fatal error -- Uncaught exception Io with <unknown> raised at PervEnv/IO/text-io-fn.sml:444.14-444.56

Code:        Perhaps a simple program that keeps printing to std_out
	     will work. 

Comments:
 [Bjorner, 5/20/98]
  I noticed that my test program also requires more and
  more memory as it runs and suspect that this problem
  is connected with the exception. (this could naturally also
  be my bug...)

 [jhr, 5/20/98]
  Most likely, you are writing out more than 2^30 characters of
  data, which would result in an overflow in the file position
  counter.  I guess we can use Int32.int for this counter, but
  that only doubles the time before you will get a crash.

  I don't think that the memory leak is connected to this exception.
  If you were running a CML program, I would say that it is probably
  a space leak that was introduced in 110.2 (we now have a fix for
  it).

Fix:         
Test: 
Owner: jhr
Status: not a bug (?)
----------------------------------------------------------------------
Number: 1394
Title:	"*" not allowed as record label pattern abbreviation
Keywords:    record label
Submitter:   Stephen Weeks <sweeks@research.nj.nec.com>
Date:        5/19/98
Version:     110.0.3
System:      x86-linux
Severity:    minor
Problem:     

  SML/NJ complains with a parse error on the following:

  - val {*} = {* = 13};
  stdIn:2.2-2.7 Error: syntax error: deleting  RBRACE EQUALOP LBRACE
  stdIn:32.1-32.7 Error: syntax error: deleting  ASTERISK EQUALOP INT

  However it accepts the following:

  val {* = op *} = {* = 13};

  I believe the Definition says that both are legal.

Code:        
Transcript:  
Comments:    
 [Weeks, 5/27/98]
  I've changed my mind on the first example.  I think SML/NJ agrees with
  what the Definitinon says, although it's error message is misleading.
  According to p. 57,

  val {*} = {* = 13} 

  is a derived form for

  val {* = *} = {* = 13}

  This is not a valid program, since * is infix.  However, the following
  program is valid, and SML/NJ rejects it.

  nonfix *
  val {*} = {* = 13} 
Fix:         
Test: bug1394.1.sml
Owner: dbm, Andrew
Status: open
----------------------------------------------------------------------
Number: 1395
Title: OS.FileSys.modTime fails for open file on Windows 95.
Keywords: basis, OS.FileSys.modTime, file system, file modification time
Submitter: Andrew Kennedy   Andrew.Kennedy@persimmon.co.uk
Date: 05/13/98
Version: 110
System: x86 Windows 95 
Subsystem: SML basis library
Severity: minor
Problem:
  On all systems (including Windows NT) except for Windows 95, 
  OS.FileSys.modTime succeeds when applied to a file that is currently
  open. On Windows 95 it raises an exception.
Transcript:
  - OS.FileSys.modTime "myfile";
  val it = TIME {sec=888240358,usec=0} : Time.time
  - val f = TextIO.openIn "myfile";
  val f = - : TextIO.instream
  - OS.FileSys.modTime "myfile";

  uncaught exception SysErr: modTime: cannot get file time
   raised at: boot/Win32/os-filesys.sml:27.27-27.71
Comments:
  If the bug cannot be `fixed', then 
  (1) The basis documentation should be amended
  (2) The exception should be changed to "file is open"
Fix:
Test: 
Owner: jhr, Lorenz
Status: open
----------------------------------------------------------------------
Number: 1396
Title: uncaught exception ltUnbound (secondary error)
Keywords: Flex records
Submitter: Andrew Kennedy   andrew@persimmon.co.uk
Date: 05/27/98
Version: 110.6
System: Any/All Any Unix 
Subsystem: SML compiler
Severity: medium
Problem:
  Compiler bug error message follows "unresolved flexible record" error 
  message. 
Code:

Transcript:
  - fun x y = 1;
  val x = fn : 'a -> int
  - x # y; 
  stdIn:38.3-38.6 Error: unresolved flexible record
    pattern: {y=y,...}
  **** hmmm, I didn't find the variable 82

  uncaught exception ltUnbound
    raised at: FLINT/kernel/ltybasic.sml:284.32-284.41
	       FLINT/plambda/flintnm.sml:569.23
Comments:
Fix:
Test: bug1396.1.sml
Owner: Zhong
Status: open
----------------------------------------------------------------------
Number: 1397
Title: Compiler bug caused by "val rec lazy" declaration
Keywords: lazy sml, val rec lazy, compiler bug
Submitter: Matthias Blume <blume@CS.Princeton.EDU>
Date: 5/27/98
Version: 110.6
System: -
Severity: major 
Problem: 
  A "val rec lazy" declaration of a cyclical lazy list produces
  "Compiler bug: TransTypes: unexpected wildcard-type in toTyc".
Transcript:
  Standard ML of New Jersey v110.6 [FLINT v1.41], May 21, 1998 [CM&CMB]
  val it = () : unit
  - Compiler.Control.lazysml := true;
  val it = () : unit
  - datatype lazy l = Nil | Cons of int * l;
  datatype l = Cons of int * l ?.susp | Nil
  type l = ?.l ?.susp
  - val rec lazy ones = Cons (1, ones);
  GC #0.0.0.0.1.1:   (0 ms)
  Error: Compiler bug: TransTypes: unexpected wildcard-type in toTyc
Comments:
Fix:
  Corrected paths (e.g. "InLine.:=" instead of ":=") in defining
  assignVar and bangVar in Semant/elaborate/elabcore.sml.
Test: tests.lazy/bug1397.1.sml
Owner: dbm
Status: fixed in 110.7.2 [dbm, 6/12/98]
----------------------------------------------------------------------
Number: 1398
Title: bus error in using Compiler.Profile
Keywords: profiling, bus error
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 5/22/98
Version: 110.0.3?
System: ?
Severity: major 
Problem: 
  In an attempt to use Compiler.Profile to get some idea of
  performance and memory usage I encountered the following
  error:

  GC #2.10.19.54.3484.638472:   (0 ms)
   %time cumsec #call  name
  Bus error (core dumped)

  when trying to invoke: 

	  Compiler.Profile.reportAll TextIO.stdOut

  It had been called for the 1022'nd time before the error happened.
  Before then it would routinely print something like:

   %time cumsec #call  name
   78.80  52491    16  Test.<tempStr>.dp.dp.simplify.simplify
   19.28  65337     0  Minor GC
    1.20  66142     0  Run-time System
     .70  66611     0  Major GC
     .00  66611     1  Test.<tempStr>.dp.dp
     .00  66611     1  Test.<tempStr>.dp.dp.axioms
     .00  66611     0  Compilation
     .00  66611     0  Other
     .00  66611     0  Test.<tempStr>.debug.debug
     .00  66611     0  Test.<tempStr>.debug.debug.axioms
     .00  66611     0  Test.<tempStr>.debug.debug.simplify.simplify
     .00  66611     0  Test.<tempStr>.getEq.getEq
     .00  66611     0  Test.<tempStr>.getEq.getEq.anon

  This happened in a compilation done entirely without CML.
  I have also noticed some problems in using Compiler.Profile.reportAll
  when TextIO is bound to CML (but this could be expected I take).
  I was wondering if there were any ways to also monitor memory usage
  in some systematic way too. Did Tolmach's debugger support anything like
  that (well at first I found the concept of a debugger for ML somewhat 
  weird: programs are "just correct" as soon as they are type-checked, but
  not knowing whether to find particular memory problems one place or
  the other it may be useful.)

Comments:
Fix:
Test:
Owner: Andrew?
Status: open
----------------------------------------------------------------------
Number: 1399
Title: Overloaded operations done before type is known.
Keywords: integers, alpha, arithmetic
Submitter: George  Russell   george@persimmon.com
Date: 06/03/98
Version: 110.6
System: Alpha Digital Unix 4.0B
Subsystem: Installation
Severity: minor
Problem:
  This code raises Overflow when it shouldn't.
Code:
  val m : Int32.int = 2147483647
  val a : Int32.int = 2147
  val q = m div a;
Transcript:
  Standard ML of New Jersey v110.6 [FLINT v1.41], May 21, 1998 [CM; autoload enabled]
  - use "/tmp/test";
  [opening /tmp/test]

  uncaught exception overflow
    raised at: <file int32.sml.bin>

Comments:
 [dbm, 6/3/98]
  Note that the bug only appears if input is a single declaration.  In
  other words, nothing goes wrong if it is broken down into three separate
  declarations:

    - val m : Int32.int = 2147483647;
    val m = 2147483647 : Int32.int
    - val a : Int32.int = 2147;
    val a = 2147 : Int32.int
    - val q = m div a;
    val q = 1000225 : Int32.int

Fix:
Test: bug1399.1.sml
Owner: Lal
Status: fixed in 110.7.1 [George, 6/5/98]
----------------------------------------------------------------------
Number: 1400
Title: Prettyprinter bug
Keywords: prettyprinter, constructor shadowing, multiple declarations
Submitter: Matthias Blume   blume@cs.princeton.edu
Date: 06/04/98
Version: 110.6.3
System: Sparc Solaris 
Subsystem: SML compiler
Severity: minor
Problem:
  When defining a variable and -- within the same compilation unit --
  a datatype constructor by the same name, then the pretty printer
  seems to get confused.

Code:
  val a = 0
  datatype t = a;

Transcript:
  - val a = 0
  = datatype t = a;
  val a = <PPDec.getVal failure>
  datatype t = a

Comments:

Fix:

Test: bug1400.1.sml
Owner: dbm
Status: open
----------------------------------------------------------------------

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