[MLton] CM hacking

[Stephen Weeks]

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

Somewhat agreed -- though the ML Kit's system has seen some use.

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

Good to hear.  Out of curiosity, does this mean that you use another
SML for fast recompilation or that you can tolerate MLton's compile
times for the program sizes you have?

> Also, while CM is imperfect.. I see no reason to attempt to reinvent
> the wheel.
...
> 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.

In this case, I don't see the difference between "starting over" and
"fixing CM".  The language that I proposed has features that aren't
compatible with CM and it is unlikely that the SML/NJ project will
change CM to make it compatible.  The language that I proposed shares
many things with CM and PM, so it can be viewed as "fixing CM" or
fixing PM.  Or it can be viewed as starting from scratch.  I don't see
that it matters which view you take, since in the end it is different
than CM.

Please read the proposal and the following discussion.
	
	http://www.mlton.org/pipermail/mlton/2003-July/014395.html

If you want, you can think of my proposal as CM with the following
fixes:

* file order is explicit
* a clear semantics that unambiguously describes a whole program
* groups can be nested within a single file
* toplevel values and types can be exported from groups
* additional syntax for renaming

My proposal retains the following features of CM:

* grouping of related files
* names in any name space can be hidden/exported
* separate delivery of 3rd party libraries (as source) without
  changing the code
* dependencies between files can be computed

Another thing I'd like you to take away from reading my proposal is
that this is *not* a difficult thing to implement from scratch.  I bet
I could get a first cut running in less than one week.  My feeling is
that a lot of the complexity of the CM implementation is irrelevant
for this system and for MLton, and the time spent in separating out
CM, porting it, and ripping out the useless parts is more than
re-implementing the proposal from scratch.  That's why I'm not doing
what you propose -- but it's no reason why you shouldn't.

Another reason why I don't want to think of MLton's system as a
modified CM is that I don't want historical constraints or an attempt
to maintain compatibility with the latest SML/NJ CM to interfere with
making the best compilation management system possible for MLton.
MLton is a very different point in the design space of compilers than
SML/NJ and its needs and users' needs are different than those of
SML/NJ.

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

I agree that prototypes are a good thing.  And it will be helpful to
have one if you build it.  Perhaps it will morph into MLton's future
compilation management system.  And having a CM implemented in
portable SML will be nice too.


Please don't let any of this discourage you from building the
prototype.  I just want you to understand the direction that I think
MLton is headed.