[MLton] library naming

[Stephen Weeks]

> I think that Vesa sees it as a Boost like focused project: well-crafted, 
> high-quality libraries.
> 
> I think that Stephen sees it as a SourceForge like public service: hosting 
> and exposure of work-in-progress libraries.
...
> Inevitably, I think that Vesa's model would emerge from Stephen's, as a 
> way of selecting high-quality libraries that others may depend upon.

That is a concise and accurate summary of how I would like to start
and what I hope will happen.

I think that Vesa also makes a number of good points, and I agree with
his goals.  I support anything we can do to encourage (but not
require) collaboration, written descriptions, and discussion of
library concepts, designs, naming issues, etc.  The MLton list is
clearly the place where such discussion will take place for now.
Although my guess is that at some point it will be useful to create a
separate MLton-library mailing list.  I am willing to do so whenever
we think the noise of library discussion is too much for this list or
the noise of this list is preventing potential members of the library
list from joining.  I also want to remind people of the MLton-commit
list

  http://mlton.org/mailman/listinfo/mlton-commit

which is useful to follow "silent" :-) commits.  Whenever we think
it's necessary, it will be easy enough to split out a separate list
for library commits.  I will strongly encourage library developers to
join that list.  

I disagree with Vesa in that I think it will be useful to allow people
to publish code even if they can't or don't want to spend the time to
explain the concept to us.  There are indeed tens if not hundreds of
parser combinator libraries out there.  It would be great to be able
to see some of them, read them, and be able to easily point to them in
discussions leading up to the ultimate one (or two or three) such
libraries.

In the end we want high-quality libraries, and a single good library
is indeed better than several half-baked ones.  But seeing several
half-baked ones is better than seeing nothing, and will get us to the
high-quality ones faster.  We can build the infrastructure to identify
the high-quality libraries on top of the mishmash later.  We might use
something like "mltonlib/com/ssh/boost" or perhaps a wiki page, like
mlton.org/ParserCombinatorm, to explain the design space.  Let's see
what develops.

One point Vesa makes I would like to discuss further.

> There are some aspect that I don't like about the "give everyone a
> versioned home directory" approach.  I feel that it creates a much
> stronger sense of ownership and that can discourage collaboration. I
> don't know about others, but I'm generally somewhat reluctant to
> contribute to projects "owned" by some random company (like
> "com/ssh" :).

Could you elaborate on the reason for your reluctance in our
particular case?  Hopefully we will make it abundantly clear to
contributors and users the license under which all the code will be
released.  I could even add a note in repository at, say,

  mltonlib/trunk/LICENSE

explaining things and pointing to http://mlton.org/License.