[MLton] the next public release

[Matthew Fluet]

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

A wiki seems fine.  I'll admit that I don't use them much on any site.

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

Fair enough.

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

Maybe by analogy with target-map, we should provide
  $lib/path-map
and optionally support
  .mlton/path-map