[MLton] extended basis library

[Andreas Rossberg]

Stephen Weeks wrote:
> 
> The syntax/semantics for vals is obvious, I think.  But there are some
> issues for types.

FWIW, we had exactly the same issues in the design of import specs in 
Alice ML. Basically, they are signature specs, but for convenience, the 
annotated classifiers of these specs may be dropped (if the imported 
component is available at compile time). As you observed, for types (and 
exceptions) the ML syntax is suboptimal because it is not entirely clear 
what to view as the classifier.


> Would we require type arity to be specified as in
> SML:
> 
>   type 'a t
> 
> I think that is the wrong way to go, and inconsistent with what we do
> for everything else (why specify the kind of types, if we don't
> specify the type of values or the signature of structures, or ....).
> Similarly, I think rebinding of types should not follow the (ugly, to
> my eye) SML syntax that requires one to duplicate the arity specs.
> So, for a unary type constructor one should write
> 
>   type t = u
> 
> and not
> 
>   type 'a t = 'a u

That's exactly what we did for Alice ML. An import with type arguments 
(or with manifest definition) is considered a "full" spec, while

   type t

is considered unannotated and hence looked up by the compiler. That is, 
it may be higher-order. (It is unfortunate that this approach leaves no 
syntax to give a full spec for an abstract type of ground kind, though.)

Similarly, Alice ML allows type definitions to drop the eta expansion, i.e.

   type l = list

is OK.

Note that SML actually allows (or requires) this in other places, e.g. 
for datatype replication - you *have to* write

   datatype l = datatype list

Likewise with sharing constraints. So I think it is perfectly consistent 
to allow it for type synonyms.


> The issue with datatypes is whether a type binding exposes the
> constructors or whether we require a separate syntax (like SML).  I
> think that the latter makes sense, so that one must write
> 
>   datatype list
> 
> to export the list type constructor and its constructors, while
> 
>   type list
> 
> would export only the type constructor.

Again, this is precisely what we do in Alice ML for imports.


> As to exceptions, the syntax is certainly confusing because of the
> conflict with SML, but the logical analog of what we've done is to
> have
> 
>   exception E
> 
> mean, effectively, 
> 
>   exception E = E
> 
> That is, an exception is not being constructed, only exposed.

This problem does not occur in Alice ML, because imports use 
*specification* syntax, where the latter is not valid anyway. (Actually, 
there once was an experimental extension to allow "manifest exception 
specs", but since it wasn't terribly useful to warrant the complication 
we dropped it. But at that point, the former form was considered 
unnannotated.)

- Andreas