[MLton] SML/NJ (possible) bug report

[Matthew Fluet]

Number: *
Title:       compiler bug reported on inconsistent signature
Keywords:    where, where type, signature
Submitter:   Matthew Fluet (fluet@cs.cornell.edu)
Date:        01/02/04
Version:     110.44
System:	     x86-linux
Severity:    minor/cosmetic
Problem:

A combination of where and where type clauses can give rise to a signature
with inconsistent constraints.  The inconsistency is not reported (as a
type error) at the time of the signature definition.  Attempting to match
a structure against such a signature gives a type error (correct, as no
structure can satisfy both of the constraints), but also gives an "Error:
Compiler bug:" message.

I'm not sure whether the failure to give an earlier type error is a bug;
it depends upon the exact semantics of a where clause (which I can't find
documented on the SML/NJ site).  The "Error: Compiler bug:"
message suggests a unanticipated corner case.

Code:

signature T = sig type t end;
structure R = struct type t = int end;
signature T = sig type t end;
structure R = struct type t = int end;
structure S = struct type t = bool end;
signature SIG =
  sig
    structure T : T where type t = R.t
  end
  where T = S;

structure A : SIG =
  struct structure T = R end;
structure B : SIG =
  struct structure T = S end;

Transcript:

Standard ML of New Jersey v110.44 [FLINT v1.5], November 6, 2003
- signature T = sig type t end;
signature T = sig type t end
- structure R = struct type t = int end;
structure R : sig type t = int end
- structure S = struct type t = bool end;
structure S : sig type t = bool end
- signature SIG =
= sig structure T : T where type t = R.t
= end where T = S;
signature SIG = sig structure T : sig type t = t end end
- structure A : SIG =
= struct structure T = R end;
stdIn:7.1-8.27 Error: structure def spec for T not matched
- structure B : SIG =
= struct structure T = S end;
stdIn:1.1-9.27 Error: type t does not match definitional specification
Error: Compiler bug: ModuleUtil: unexpected binding in extractInfo

Comments:

The same behavior appears if SIG uses a definitional type specification:

signature SIG2 =
  sig
    structure T : sig type t = R.t end
  end
  where T = S

On the other hand, there are appropriate type-error messages for:

signature SIG3 =
  sig
    structure T : T where type t = R.
  end
  where type T.t = S.t

It is my understanding that SIG and SIG3 are supposed to be equivalent.

Fix:	     <optional - but you get extra credit>
Test: *
Owner: *
Status: *