using mosml as a frontend for MLton

[Stephen Weeks]

Just to update you guys, I received the following reply to an email I sent to
Peter Sestoft.

> > Thanks for the reply.  BTW, the reason I am playing around with mosml (other
> > than benchmarking) is that I am considering cannibalizing its frontend as a
> > possible replacement for MLton's frontend.  
> 
> Interesting.  Alternatively, replace mosml's backend with mlton's :-)
> 
> > I am curious if you have any thoughts on doing this.  The main thing
> > I am worried about is performance (both run time and space).  But I
> > am also interested to hear your thoughts on the simplicity and
> > suitability of the IL that the frontend generates.  Thanks for any
> > info.
> 
> The intermediate language is a standard untyped lambda language
> extended with let, exception handlers etc.  Maybe it's a problem in
> your setting that it's untyped -- I haven't studied MLton internals.
> 
> The mosml front-end is a pretty straightforward multipass thing, and I
> believe it's quite efficient.  Since it's used in the mosmlc batch
> compiler (not only in the interactive system) it should be possible to
> tack it onto a different compiler and runtime system.  There are some
> calls to C functions in the runtime, but I think they are mostly
> rather harmless.  There's some stuff having to do with separate
> compilation and mosml .ui (and .uo) files, which of course have a
> rather specific format.
> 
> 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.
> 
> Peter