[MLton] export-filter-like technique

[Vesa Karvonen]

Quoting Stephen Weeks <sweeks at sweeks.com>:
> I saw the following technique used in the extended basis in lieu of
> using an MLB export filter.
> 
>   local
>      ...
>   in
>      public/export.sml
>      public/export-mlton.sml
>   end
> 
> where, e.g. public/export.sml, looks like
> 
>   type ('a, 'b) emb = ('a, 'b) emb
>   type ('a, 'b) iso = ('a, 'b) iso
> 
>   signature ARRAY = ARRAY
>   signature CHAR = CHAR
>   ...
> 
>   structure Array : ARRAY = Array
>   structure Char : CHAR = Char
>   ...
> 
> It seems like a nice technique because it allows one to write specs if
> one wants, and neatly sidesteps our discussion about extending MLBs
> for val and type exports.  It's more wordy than export filters, but as
> a practical matter I'm not sure it matters at all, since the amount of
> work to write down the exports of a library are very small relative to
> the total amount of work that goes into a library.

I wrote the export filters basically by running mlton -show-basis and
editing the result (by hand this time).  I'll probably write a small
shell script that does the necessary editing automatically.

In addition to allowing type, exception, val specs/bindings, expressing
export filters as ordinary SML source files has a couple of more
advantages:

- They are probably immediately readable to a slightly larger set of SML
programmers.

- Externals tools (like document generators) probably need not know (or
need to know less) about the compiler specific build files.

- It is more portable.  SML/NJ's CM system seems to support it (I'm
working on an initial port to SML/NJ) and I think that MLKit's
implementation of the ML Basis System will also support it (I plan to
attempt porting to MLKit after finishing initial SML/NJ port).

So, expressing export filters as SML'97 code means that export filters
need to be expressed only once (as long as the exports aren't compiler
specific, of course).

--Vesa Karvonen