[MLton] MLton and Moby

[Matthew Fluet]

> Does this mean that someone could actually try hooking MLRISC as a
> backend for MLton?  That would be nice to see.  We could use it both
> as another data point for the x86 and for new ports.

Yes, that was part of my motivation.  But, (current) documentation on how
to write MLRISC backends is a little sparse, so I wanted to check how it
worked with a current system.

> >   sequential withtype exapansions: a few.  All but one of them could be
> > 	rewritten as a sequence of type definitions and datatype
> > 	defintions.  One example of this is the code generated by
> >         the ASDLgen tool.  Hence, the ASDLgen does not generate SML.
>
> It would be nice to pass this information back to the ASDLGen authors
> and encourage them to fix the problem.

Well, as far as I can tell, ASDLgen hasn't been touched in 3 years or so,
so it might be a moot point.

> > While I know MLton won't support "where <str> = <str>" in the future, I
> > toyed with the idea of hacking something together so that I could get
> > MLton to print out the complete, elaborated signature for a signature
> > identifier, so that I could see all the types, rather than hunt thorugh
> > the sources by hand.
>
> This shouldn't be too hard.  The problem is how to display the sharing
> in interfaces, which really requires the introduction of new signature
> names.  And that problem may only be bad for MLton-style deep
> structure code, so it could be ignored at first.

I don't quite follow this.  What is the issue?