[MLton] cvs commit: mlb integration

Stephen Weeks MLton@mlton.org
Fri, 30 Jul 2004 09:55:27 -0700

> but then infix status, overload status, unqualified types (like unit,
> bool, ref), polymorphic-equality, etc. are not provided by MLton Lib (in a
> naive translation of lib/mlton/sources.cm).

We can certainly handle infix status and unqualified types from within
SML.  But you're right in that polymorphic equality and overloads
can't be handled within SML.

> In any case, we may well want to provide a $(SML_LIB)/basis/pervasive.mlb.

Yes, this makes sense (but see below).

> or write lib/mlton/sources.mlb as
> local
>  ...
> in
>  ...
>  $(SML_LIB)/basis/pervasive.mlb
>  rebind.sml
> end
> where rebind.sml has
>   type int = Int.t
>   type word = Word.t
>   ...

I like a solution like this that allows users of MLton lib to refer to
a single mlb.  (This example also shows why we might want to expose
type and value decs in mlbs, or possibly even whole topdecs, suitably

Another possibility is to have an mlb or (two) to export the stuff
that can't be expressed in the language.


Then people can export exactly what they want without having to use