[MLton] MLton library project

[Stephen Weeks]

> Well, if you mean that whether new libs are allowed to depend on old
> libs or not, then I would say that it should definitely be allowed.

I agree.

> From a theoretical POV, I definitely prefer the many small MLBs
> approach, but it has a number of practical drawbacks.  First of all
> you then need to write all those little MLBs and that can be a lot
> of tedious work and requires lots of small files (i.e. it is quite
> verbose).

Yeah.  This is yet another argument that convinces me that we should
allow SML topdecs inside MLBs.  Then one could write a single file
that expresses both the code and its import dependencies, e.g.

local 
  foo.mlb
in
  structure Bar = 
    struct
       ... Foo.x ...
    end  
end

> Also, compile time with MLton seems to increase (significantly) with
> that approach.

That is disappointing to hear.

> I don't know the exact reasons for this, but I'd guess that the
> necessary namespace / environment management (although probably
> quick) isn't free.

> The mechanism for saving and restoring bases for MLBs is based on
> taking snapshots of the environment, which I don't believe is all
> that efficient. It is the same mechanism that saves and restores the
> environment for functors.

Matthew's explanation seems right to me.  The mechanism for saving and
restoring the toplevel environment takes time proportional to the size
of the environment.  The implementation of environments used for type
checking predates the implementation of MLBs.  In that world, the only
time environments were saved/restored was at functor
definition/application.  So, I decided to use an imperative data
structure that was fast in the common case, but slow for snapshots.
With MLBs, and many small MLBs especially, environment snaphots are
much more common.  It would be worth re-implementing environments to
be more (or perhaps completely) functional, at least functional enough
so that one could make snapshots free.  I suspect that would
completely solve the performance problem.