[MLton] the next public release

[Stephen Weeks]

> I've been thinking for a while that the User's Guide and/or the
> website should have a "MLton Philosophy" section.  For example, I
> don't see anywhere in the documentation a statement along the lines
> of "(Strict) adherence to the Definition of Standard ML is a driving
> principle in the development of MLton."

I agree this should be stated, but I'm not sure it belongs in the User
Guide.  I think it belongs more in the hacker/developer guide.  And,
since that doesn't exist, and doesn't seem likely to be created
anytime soon, that brings up another thing I've been thinking about
lately.  What do people think about adding a wiki to mlton.org?  The
idea is that it would mostly focus on developers initially -- we could
hopefully use it to organically grow a developer guide.  And we could
start with a philosophy page.

In addition to the benefit of having contributors besides me and
Matthew, I am thinking that having a bit less structure than the usual
document will encourage the addition of disconnected facts and we can
grow the structure around them.  It will also give us a place to
migrate explanations sent to the mailing list that would be useful to
organize more permanently.

Other things that I can see migrating to the wiki are the papers,
projects, and users web pages.

> It would also be helpful to clarify the fine line we seem to walk in
> relation to other SML compilers (SML/NJ in particular).  For example, we
> would like to support NLFFI, but we (seem to) adamantly oppose or-patterns
> and vector literals.  We have non-trivial language extentions (threads,
> signals, weak pointers, finalizers, etc.), but they are "o.k." because
> they live in the MLton structure.

I would like to see this clarified as well, since I am no longer sure
about the line either.  It was pretty clear when we compiled whole
programs of SML 97 + the basis.  But you're right, since we have
exposed our FFI, added lots of nonstandard structures, and now
extended the language via mlbs, the line is no longer clear.

> I wonder how useful to end-users it would be if we gave hints for
> using the SML/NJ library.  I don't think it is "fair" to deliver a
> whole pile of SML/NJ library code with MLton (even though I know
> their license allows it).

I don't have any problem with delivering a MLton-ized version of
SML/NJ lib.  On focus of mine these days (and I guess this is
something else that belongs in the philosophy section) is on making
MLton users' lives easy.  And I think its much easier for them to get
a working lib as part of our package rather than make them download
another system and do a song and dance with tgzs and diffs.  This also
goes well with another long-term goal, which is to make MLton a
standalone SML development system, with no need for another one.

> Should we provide a convenient way for users to add additional
> environment variables, without polluting their process
> environement?; for example, we could read in a $(HOME)/.mlton-env
> file with user specific environment/path pairs.

This sounds good to me.  I agree with you and with Henry that using a
file is better than polluting the process env.  I wonder if we should
call the file .mlton, or possibly even have a .mlton/ directory, with
an eye toward future extensions.

> We could also provide a global mlton-env that sets SML_LIB (and
> others).

Sounds good.

> Alternatives to SML_LIB might be:
>   MLTON_LIB -- although that may conflict with a future library
>   MLTON_ROOT
>   MLTON_HOME
> For some reason, I like getting MLton in there.

Fine with me.