[MLton] library naming

[Stephen Weeks]

The MLton/SML world is in a very different state than the C++ world,
and a library project has very different requirements.  Given our size
and the lack of libraries the most important thing is to not introduce
barriers to entry for library authors.  If I, as a seasoned SML and
MLton developer, feel a barrier, you can bet that many others will.
The main aim of my naming proposal was to give people a place to work
without any worries about review processes, stepping on others toes,
etc.  I feel completely comfortable starting work on a library at
"com/sweeks/basic/unstable".  I feel an insurmountable hurdle to
creating "basis-replacement/unstable", let alone come up with a better
name than "basis-replacement".  I also think it's too much of a hurdle
to require discussion of the name, motivation, scope, or anything else
before starting work on a library.  I'm not against such thoughts or
discussions, I just don't want to introduce hurdles.  Such discussion
will happen eventually for some libraries, but not for all, and
there's no way to know in advance which and no reason to prevent
people starting work.  Not making code public misses out on the chance
to share and the chance to collaborate.  Having a namespace of your
own on a public server encourages sharing.

Perhaps the name "mltonlib" for the root of the project is the wrong
name, for a number of reasons.  It really isn't a library.  I do want
the infrastructure to support an "ad-hoc collection of various
people's libraries".  I would be happy to have anyone's library in
there.  For example, I am aware of three OpenGL wrappers and two GTK
wrappers in SML.  I don't think it is worth spending time trying to
decide which is the right one and anointing it with a toplevel name.
I think they should all go in, and let evolution sort out the
"winners".  I view as completely separable problems from building up a
library collection the decision about what gets distributed with MLton
and what makes a usable (robust, complete, consistent) library.

The naming proposal was aimed at even removing the barrier of
requiring SVN commit access (although I intend to be liberal with
that).  It allows people to work on libraries in another repository
and not worry about stepping on toes.  Further, it allows users to
draw code from different repositories and combine them into one local
repository, and greatly reduce the chance of conflicts.

On top of this somewhat anarchic structure it will at some point make
sense to create collections of libraries (like boost) that work well
together and to use peer-review processes.  But there may be many such
projects, and I would like to allow them all.

Vesa could start one such project today at 

  com/ssh/boost

where he could impose stringent requirements on library authors.  That
project would even be free to cobble together pieces from other
libraries, such as from

  com/sweeks/basic

But it will never get the chance if I never put anything there.