[MLton] free type variables in datatype decs

Ken Friis Larsen ken@friislarsen.net
Thu, 03 Feb 2005 21:12:27 +0100


Matthew Fluet wrote:
> Perhaps.  But it appears that MLton is going out of its way to choose a 
> solution at odds with every other SML compiler.  And, there is very little 
> practical benefit of MLton's behavior over the no-free-type-vars solution.

This is not exactly true.  If you give Moscow ML 2.01 the program

val id = fn x =>
    let
       datatype z = Z of 'a
       val unZ = fn Z x => x
    in
       unZ (Z x)
    end;

Then it will accept the program but gives you the following warning:

!       datatype z = Z of 'a
!                         ^^
! Compliance Warning:
! The phrase, although accepted as a Moscow ML extension,
! is not supported by the Definition of Standard ML:
! the type variable
!   'a
! should be a parameter of the datatype binding

[Unless you start Moscow ML with the flag -orthodox, in which case all 
such warnings are treated as errors; or similar if you start Moscow ML 
with flag -liberal, in which case all such warnings are suppressed.]

Likewise if you give Moscow ML the program:

> Note, that the example given in mlton.org/FunctionalRecordUpdate
> 
> fun << ({a, b, c}, (f, z)) =
>    let
>       datatype t = A of 'a | B of 'b | C of 'c
>       fun g h z =
>          {a = case h z of A a => a | _ => a,
>           b = case h z of B b => b | _ => b,
>           c = case h z of C c => c | _ => c}
>    in
>       f {a = g A, b = g B, c = g C} z
>    end

You'll get the above warning three times, one for each of the 
constructors A, B, and C.

And if you try to give it Andreas' example:

   datatype t = C of 'a
   fun cast x = case C x of C x' => x'
   val ouch = 1 + cast "string"

Then you get the error:

! Toplevel input:
! ..datatype t = C of 'a
!   fun cast x = case C x of C x' => x'
!   val ouch = 1 + cast "string"
! Unguarded type variables at the top-level


I'll leave it to Claudio to explain why it is sound :-)

Thus, I think that MLton's behaviour is perfectly reasonable.


Cheers,

--Ken