[MLton-devel] intInf ??

Matthew Fluet fluet@cs.cornell.edu
Thu, 12 Jun 2003 09:29:03 -0400 (EDT)


> [dimock@localhost compiler]$ mlton elab-trans-mlton.cm
> FLINT/trans/matchcomp.sml:245.6-245.15 Error: unify: type constructors not equal   t1: int
>    t2: intInf
> compilation aborted: type check reported errors

The "intInf" type is an artifact of MLton's poor front-end type checking.
Essentially, type-checking is done after unrolling all type synonyms down
to datatypes or primitive types.  The primitive type of arbitrary
precision integers is "intInf" and the basis library declares IntInf.int =
intInf.

> The code compiles under SML/NJ.  The line causing the error message is:
>
> 	    INT32pcon (LN.int32 s)
>
> where s        : IntInf.int
>       LN.int32 : IntInf.int -> Int32.int
>       INT32pcon: Int32.int -> pcon

Check elab-trans-mlton.cm to see where the IntInf structure is coming
from.  Notice that the SML/NJ Library includes an IntInf structure and so
does MLton's Basis Library.  It is quite possible that one of those
IntInf.int's is from MLton's Basis and the other is from SML/NJ's library.
Here's a sample program that simulates what may be happening:

structure X : sig
		val x: IntInf.int
	      end =
struct
  val x = IntInf.fromInt 1
end

structure IntInf : sig
		     type int
		     val toString : int -> string
		     val fromString : string -> int
		   end =
struct
  datatype int = T of {sign: bool, digits: Int32.int list}
  val toString = fn T {sign, digits} => ""
  val fromString = fn _ => T {sign = false, digits = []}
end

val _ = IntInf.toString X.x

Note that we should get a type error, since X.x is the Basis Library
primitive and IntInf.int is a datatype.  Compiling yields:

[fluet@lennon temp]$ mlton-stable z.sml
z.sml:20.9-20.24 Error: unify: type constructors not equal
   t1: int
   t2: intInf
compilation aborted: type check reported errors

So, you can see that the error message is less than illuminating, because
it doesn't say which structure the types are coming from.

I'm pretty sure something like this is going on.  Note that SML/NJ doesn't
define an IntInf in it's basis library, it is only in the SML/NJ library.
So, I would expect all uses of IntInf.int in the SML/NJ compiler to be
coming from the SML/NJ Library.  The fact that you are seeing one coming
from MLton's basis library probably means that the order in the .cm file
is wrong.  Note that MLton's support for .cm files is quite rudimentary --
really, it just reads in the files in the order they appear in the .cm
file, no dependency checking is done.  I would expect all the files from
smlnj-lib/Util to appear before any files from compiler/.

> Looking at the http://sml.sourceforge.net/Basis/int-inf.html and at
> http://www.standardml.org/Basis/int-inf.html I see an "int" type (from
> include INTEGER) but no "intInf" type.  (I assume that one of these
> sites is the last word on the basis library.)

I think that those two sites are mirrors of one another.  Presumably, the
"last word" on the basis library will be the published book, although the
publication date is invariably a year away no matter when I've checked it.
(Even so, the authors haven't responded to some
criticisms/errors/clarifications on the spec, and I sincerely hope that a
more open development process could be instituted after the publication.
But, that's another discussion entirely.)

> I tried compiling with -basis 1997, but I get a different error in
> less time compiling that way (ElabData/types/tuples.sml:26.3-31.6
> Error: structure Vector in signature but not in structure).

The MONO_ARRAY (and MONO_VECTOR) signatures changed from basis 1997 to
basis 2002.  Under basis 1997, a MONO_ARRAY had a
structure Vector : MONO_VECTOR component, but under basis 2002, it simply
has a type vector component.

> (I am using a copy of MLton that I got from mlton-20030312-1.i386.rpm)

That should be fine.  You can always find newer, experimental releases at:
http://www.mlton.org/experimental/
There have been a few bug fixes since the last stable release, but nothing
that affects front-end type checking.

Hope that helps.

-Matthew



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel