[MLton] CM hacking

[Daniel C. Wang]

Stephen Weeks wrote:
{stuff deleted}
> We do not want CM as the compilation management interface for MLton.
> We currently support CM for two reasons: to make it easier for people
> to port from SML/NJ and to have an interim project-management system
> until we get our own system in.  Have a look at the thread I sent
> earlier for an idea of what that will look like.  Or, if you are
> familiar with ML Kit PM files, it is closest to that.
> 
> There are a number of reasons why CM is unnaceptable: implicit file
> ordering, inability to export types and values, weak language for
> scoping imports and exports, unnecessary features, frequent changes,
> out of our control ...  I could think of more given time and study of
> the CM manual.

So I have some sympathy about the unstable feature changes of CM, but to me 
it's clear that CM is the only compilation management system for SML that 
has been "field tested" and has an existing installed base.

> So, the possible benefits that I see of the work you are thinking of
> doing are
> 
> 1. A better interim solution than cmcat when cmcat isn't sufficient. 
> 2. Allow people to develop easily with both SML/NJ and MLton, using CM
>    as the project management mechanism.

My hidden agenda is to remove the last reason for me to use SML/NJ and CM is 
by far the only real reason I haven't ditchted it yet! Also, while CM is 
imperfect.. I see no reason to attempt to reinvent the wheel.  All, the 
various quirks of CM are at times annoying, but none of them have ever been 
a show stopper for me personally. An many times CM has helped me solve 
problems that otherwise would have required me to change code in third party 
libraries which I didn't want to touch.

Some of the complaints you brought up, particularly the difficulty of 
understanding the order of effects are concrete complaints that I think, can 
be addressed by fixing CM rather than starting over from scratch. As you 
point out CM seems to be a moving target... there is no reason not to move 
it in a direction that makes it better.

The ultimate goal will be a subset of CM that runs and compiles without 
changes on MLton and SML/NJ. I think, building a prototype system is perhaps 
less work that it seems. Once a prototype exists it will be easier to 
understand the merits of CM vs whatever compilation management system MLton 
finally decides on.