[MLton] cvs commit: exposed the types of {Int,Word}{8,16,32,64} using where

[Stephen Weeks]

> I think that the Basis spec is still ambiguous about the following point,
> but I feel that the following should not type-check:
> 
> val f = LargeInt.~ o IntInf.~
> val x = (LargeInt.fromInt 1) + (IntInf.fromInt 1)

I don't disagree.  I would like to point out an implementation
challenge that this poses.  We would like to overload constants at all
the integer types.  E.g., we would like the following to type check.

val _ = 0: LargeInt.int
val _ = 0: IntInf.int

But, we want the following to fail.

val _ = 0: LargeInt.int + 0: IntInf.int

The problem is that in order for the compiler to overload "0" at some
type, it must actually know about the type -- i.e. it must be built in
to the compiler and the type information must be available at the
point "0" is overloaded.  Since in MLton LargeInt.int and IntInf.int
are the same underneath, if we wish the above "+" to fail, then we
must make the types different, either using datatypes or opacity.
Using datatypes is out, because the compiler doesn't know about them.
Using opacity is also problematic, because we would like the
following program to fail.

structure S:> sig type t end = 
   struct type t = LargeInt.int end
val _ = 0: S.t

In short, the problem is that we want the type checker to sometimes
look at the underlying type when we write the constant, but never when
we do +.


Hmmm.  It occurs to me that the same solution that we use for
overloaded operators, which seems to work fine with keeping
LargeInt.int and IntInf.int different, may work here.  That is, we
could add some new declaration,

_overload_const {int|real|word} as <ty> [and <ty>]*

Then, in overloads.sml, we could write

_overload_const int 
as Int.int
and Int8.int
and Int16.int
and Int32.int
and Int64.int
and IntInf.int
and LargeInt.int
and FixedInt.int
and Position.int

With this in place, and some manual overloading of constants in the
basis library, we could use :> to match the integer structures.