mosml as a front end for MLton

[Stephen Weeks]

> The mosml front-end is a pretty straightforward multipass thing, and I
> believe it's quite efficient. 
...
> But I don't think you should copy and extensively modify the front-end
> until Claudio and I have taken a close look at the data structures in
> the new type inference (Types.sml and Elab.sml).  There's too much
> copying going on there, but that should be solvable.  Only we have to
> do some other work in the near future.

I just attempted to compile MLton using mosml (with some appropriate stubs for
different basis libraries).  The sources consist of 381 files, the largest of
which is about 4,200 lines, with a total of about 60,000 lines.  I have let it
run for about 4.5 hours.  At this point the process size is about 280M and about
200 files have been processed.  The directory containing the .ui and .ui files
is about 300M, almost all due to .ui files.

The slowdowns and large sizes are almost certainly due to signature
representation.  The programming style used in MLton will lead to very large
representations if not enough sharing is done.  I know there are hacks in
SML/NJ's and MLton's elaborators to share whenever possible.  These are
sufficient to make compiling MLton practical.  I agree with your assessment that
you need some more work on mosml's elaborator to improve this.

So, my conclusion is for now that it is infeasible to use the mosml frontend for 
MLton.  But we'll see if sometime in the future it becomes possible.

Thanks for your help.