Debian version of MLton

[Stephen Weeks]

> I want to tell you that the very idea that CVS went in and changed some files
> fills me with complete and total disgust for this stupid system.  I AM  going
> to  set it up here, but this is incredibly stupid.  That and the fact that it
> will not preserve time stamps indicates that it is horrible in my opinion.

You are pointing out two problems that I agree with.  However, you are ignoring
the tremendous productivity benefits that Matthew and I have observed (new to
me, maybe not to Matthew) over the last 5 weeks since switching to CVS.  We have
been very succesful in simultaneously jumping around changing many parts of the
compiler (sometimes even the same file) with almost no coordination.  As MLton
gets larger and more complex, it is essential to remove me as bottleneck through
which all changes must pass.  It is clear to me now that we are already at the
point, and probably have been there for some while.  CVS has also been very
useful in letting each of us work on some larger project (for Matthew the new
codegen, for me the new SSA backend), while still being able to make smaller
changes elsewhere and exporting (e.g. what I did for Norman) all while keeping a
working stable version of MLton around.

In my five weeks of experience, the drawbacks of CVS (changing files, no time
stamps) aren't even close to offseting the benefits.  By orders of magnitude.
Also, I point out that changing file stuff can be turned off with flags and
there are even more precise time stamps available via CVS logging -- i.e. the
timestamp of every commit is there.

I also would like to revisit the issue of whether the .cvsignore files are part
of the source.  I would like to include them, so that others who use CVS (like
Barak) don't have to recreate them.

> Oh, I was going to ask you about his comment on  making  MLton  (and  how  it
> `requires'  MLton  to already be installed).  Please remember to do something
> so that MLton can be made no matter what SML compiler  you  have.   I  figure
> that  probably  the  easiest way is to just go to a 2-stage compile.  For the
> first stage, where you use some unknown SML compiler, you  supply  stubs  for
> all  the  MLton  specific features you use (GC, size, timing, etc.)  Then you
> use that result in the next stage, using  the  MLton  specific  versions.   I
> guess  that this would mean that the save-world thing isn't done in the first
> stage.
> 
> The result would still be a compiler that is written in MLton instead of SML,
> but at least it would be clear how to bootstrap up from SML to MLton.

I plan on doing this for SML/NJ and MLton.  For other SML compilers, it doesn't
really matter since they are not capable of compiling MLton due to performance
problems.

> On  an unrelated note, I mentioned to Rico about the Debian thing and then we
> talked for about an hour on how  to  lay  out  code  in  ML  to  satisfy  his
> aesthetic  senses.   He  is  thinking  of  using MLton for some serious work-
> related stuff, which would be very fine.

Sounds great.   Keep us updated.