[MLton] library naming

[Vesa Karvonen]

Quoting Matthew Fluet <fluet at cs.cornell.edu>:
[...]
> Relative to what has been done in MLton in the past, the Boost process 
> seems to:
> 
>   * require a relatively polished library before an author begins the
>     submission process

Not necessarily.  Many (if not most) libraries there have been developed
(almost from scratch based on some initial idea) or refined considerably
(based on an existing library) after the initial query of interest.
However, if one wants to submit a library, one should really have a vision
(motivation, scope) of what the library is all about as well as be able to
describe it through concrete snippets of code (usage examples, interface
specifications, prototype implementation).

>   * deny CVS access to new authors until their library is reviewed and
>     accepted

That's true...

>   * require a separate repository (Sandbox Vault) for work-in-progress

...but then there is the Sandbox repository (for collaborative development
before review) and the Vault (for sharing files - particularly at the
early stages of submission).

> The first two points seem to set a barrier to entry for new authors. 
> (Which is perhaps what they are designed to be.)

I think that the barrier for entry in Boost is set relatively high for a
number of reasons (C++ is a very difficult language and there are a
lot of C++ programmers with highly varying programming skills and
understanding of the language).  I believe that we don't need to set the
barrier that high, but some minimal barrier is necessary.  At the very
least, I would definitely expect (require) new authors (and that includes
me) to take the time to describe their library (motivation, scope,
examples) and initiate some discussions before rushing to get SVN access
and commit stuff into the repository.  As the number of people actively
involved at this point is quite low, and many are probably quite busy, I
would expect that it will be difficult to get feedback on library designs.
So, I think that we'll have to settle for less discussion than what would
be ideal (IMO) and allow more room for libraries to mature in the
repository.

> The third point seems to be an unnecessary level of indirection.  In
> particular, it seems to make tracking the revision of a work-in-progress
> somewhat harder.

I agree.

> I wonder if Stephen's suggestion wasn't an attempt at supporting 
> work-in-progress libraries in the same repository as reviewed-and-accepted 
> libraries.

Ok, maybe I somewhat misinterpreted the intention.  I'm not opposed to
having libraries in various stages of development in the same repository.
But, like I hinted, I think that it would be wise to discuss new
libraries, even briefly, before starting development.  For example, the
name/path Stephen gave as an example/suggestion

 mltonlib/com/sweeks/basic/unstable
                     ^^^^^

makes me think that there might be some overlap with stuff that many
potential contributors (including me) have (or perhaps the name could
be more specific).  A brief description of (particularly the scope of)
the library would be nice.

-Vesa Karvonen