[MLton] CM hacking

Daniel C. Wang danwang@CS.Princeton.EDU
Thu, 04 Mar 2004 22:15:52 -0500


Stephen Weeks wrote:
>>So I have some sympathy about the unstable feature changes of CM,
{stuff deleted}
> 
> 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
{stuff deleted}

Here are a things that your proposal does not address that CM does that I 
will miss in order of most painful omission to least..

  1. The option to compute dependencies automatically and not list files  in 
order!
  2. Integration of external tools such as mllex and mlyacc
  3. OS independent names for file path naming
  4. Conditional compilation

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

I'm not at all discouraged, I think this discussion motivates me even more 
to go ahead and try to build the system.

So here are some fixes to CM that can address some of your concerns. First 
is explicit syntax in group and library files that forces CM to compile and 
elaborate a certain set of files in a predetermined order this should be an 
easy feature to add. Relaxing the toplevel binding rules in files that are 
compiled in a fixed order.

I think the rest of your complaints are issues about the surface syntax 
rather than the the semantics of CM. (i.e. you can still do what you want in 
CM just in an ugly way.) At this point, I stop caring because I can probably 
with a little work parse whatevery favoriate syntax you want and build up a 
CM configuration that has the same effect as the syntax for .mlb files.

Anyway, I suspect you are undersetimating how all these extra little details 
  are going to creap up on you. Just integrating mllex and mlyacc is going 
to muck things up. At some point you'll find yourself reimplementing all 
those ugly features in CM that are there because they turned out to be useful.

Okay, I think this conversation has been useful and I understand the 
direction you want to go in. Anyway, I know what I'm doing this weekend now. :)