[MLton] free type variables in datatype decs

[Stephen Weeks]

> But it appears that MLton is going out of its way to choose a 
> solution at odds with every other SML compiler.

Being different is definitely a strike against this behavior.

> And, there is very little practical benefit of MLton's behavior over
> the no-free-type-vars solution.

I don't entirely agree here.

> Note, that the example given in mlton.org/FunctionalRecordUpdate
...
>       datatype t = A of 'a | B of 'b | C of 'c
>
> can be rewritten as
...
>       datatype ('a, 'b, 'c) t = A of 'a | B of 'b | C of 'c
> 
> without recourse to lifting the datatype to the top-level.  You retain the 
> benefit of a local datatype declaration and use.  The only thing you lose 
> is preventing use of the datatype at types other than the type-vars of the 
> function.

An annoyance of disallowing the simpler declaration is that every
occurrence of "t" in the scope of the datatype must now be rewrite
"('a, 'b, 'c) t".  Unnecessary verbosity, plus, if the type parameters
change, then changing every occurrence can be a pain.

The expansion is exactly what MLton does internally.  One thing
speaking in favor of this construct is that it has such a simple
semantics, and it can be explained to programmers without referring to
the technicalities of the Definition.


Currently, I lean slightly toward accepting this construct, but I
could go either way.  I don't think the Definition makes the choice
clear, and there are other arguments on both sides.  Here's what I
see.

Allow free variables in datatypes:

 + MLton 20041109 does it, so taking it out might break existing
   programs.  
 + Because local datatypes are allowed, programmers will naturally use
   it, and wonder why it's not there if it's not.
 + Simple semantics, understandable to programmers.
 + Extra concision in some situations.

Disallow free variables in datatypes:

 + Simple syntactic rule.
 + Other SML compilers do it.  Hence, the usual portability arguments
   apply.