we should not be incestuous

[Stephen Weeks]

> But  this  is  really terrible.  MLton source should not depend on MLton.  It
> should be straight ML. 

First, to be clear, we're only talking basis library, not language, here.
Second, I agree with you, and believe it already is (as much as possible).

> Also, when I program, in general I  do  not  want  to
> program  in MLton dialect of ML, I want to program in standard ML.  This kind
> of `incestuousness' is really not a good thing.

There are really two problems, stemming from two ways in which the library
standard sucks.
1. The standard allows too much flexibility, making portable code
   hard/impossible to write.
2. The standard does not have enough functionality.

Because of suck #1, it is not possible to build a version of MLton that will
compile with any SML compiler.  The only solution is to have per compiler stubs.
With appropriate stub code, you can compile MLton with itself or with another
SML compiler.  It is easy enough to generate the stub code if you hand me an SML
compiler.  Because of suck #2, MLton uses the MLton structure (in some minor
ways).  Again, as we do with SML/NJ, this can be avoided by per compiler stub
code.

> This seems to me to really be a strong argument for what I mentioned  before:
> when  you  compile  using  MLton  there is NO MLton structure.  You just have
> standard ML.  If you want more, you have to add an entry  to  your  .cm  file
> which consists of something like
>     $MLton/mlton.cm
> or  something  like  that.  Then their should be a flag for the `-stop f' and
> `-stop sml' arguments which makes this be the approriate set of stub files.

Amusing that you arguing for removing one MLton extension (the existence
of the MLton structure) by augmenting another MLton extension (CM file
support).  I don't see a major difference.  Either way, the program being
compiled is using the nonstandard MLton structure.  It's just a question of
whether the MLton structure is available by default or not.  I don't think that
matters.  The current approach already makes it very clear since your code is
standard iff you do not use the MLton structure.

> (This reminds me: the man page for MLton with the latest RPM thinks  that  it
> is `-stop m' instead of `-stop sml'.)

OK.  It's on the todo list.

> What are you using out of the MLton structure?

I think the only stuff that gets used is
	MLton.debug
	MLton.isMLton
	MLton.random  (soon to be renamed MLton.randomSeed)
	MLton.size
	MLton.GC.collect
	MLton.RUsage.rusage
It's not so easy to tell, because MLton relies on my huge library, which uses
all of the MLton structure (of course with appropriate stubs in SML/NJ).

> As  to  making  RPMs that will work for Red Hat 6.* machines, I don't believe
> that you can.  The problem of the shared libraries is  no  big  deal  because
> that  can  be  worked  around by using i386-glibc21-linux-gcc, which is a gcc
> which calls the C compiler with the right libraries to make executables  that
> use the older shared libraries.  Unfortunately, the problem of the actual RPM
> itself is different.  Around here I keep some machines running  Red  Hat  6.*
> just so that I can build old RPMs.

OK.  You'll be in charge of the 6.* rpms when the time comes.