[MLton] MLton and Moby

[Stephen Weeks]

> For no better reason than to see if it could be done, I "ported" John's
> latest Moby release to MLton.  Also, I wanted an application that used
> MLRISC to verify that the "port" of MLRISC to MLton was working. 

It's great to see both Moby and MLRISC working with MLton!

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.

> Scattered troughout both the SML/NJ Library and Moby sources were various
> SML/NJ-isms:
...
>   withtype in signatures: Somewhat common; probably the most annoying
> 	deviation to deal with, as it is obvious what it's meaning should
> 	be.  Is there a reason that the Definition disallows it?

I don't think so.

>   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.

>   where <str> = <str>: the most common; very prevelant in the MLRISC
> 	sources and in the Moby MLRISC interface code.  It can be pretty
> 	painful to expand out all the flexible types in the respective
> 	structures.  Furthermore, many of the implied type equalities
> 	aren't needed, but it's too hard to pick out the right ones.  One
> 	particularly bothersome idiom in the MLRISC sources was the
> 	following:
> 		signature CELLS_BASIS
> 		structure CellsBasis : CELLS_BASIS
> 	(that is, a signature and a global structure constrained by that
> 	signature).  Fairly common are signatures like:
> 		sig
> 		  ...
> 		  structure CB : CELLS_BASIS = CellsBasis
> 		  ...
> 		end

Maybe it would be easier than expanding the wheres to remove
"structure CB: ..." from the signature, replace all occurences of CB
within the signature with CellsBasis, and add "structure CB =
CellsBasis" where necessary.  Writing "= CellsBasis" is pretty much
removing any parametricity so I don't think this loses anything.

> 	However, I don't know if it's worth refactoring the MLRISC code.
>         Many of these "where <str> = <str>" constraints are repeated,
>         so I spent a lot of time cut-n-paste-ing.

It would be worth it to inform the MLRISC authors of this nonstandard
code, and all your patches, in the hope that they will fold in the
changes so that others can use MLRISC with MLton.  It would be a real
shame to fork MLRISC.

> 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.