[MLton] MLton Library project.

Stephen Weeks sweeks at sweeks.com
Wed Dec 20 12:15:52 PST 2006


> Somewhere, however, I seemed to lose the pulse of what actually got 
> decided.  I've searched on the MLton.org wiki, but haven't found a 
> summary of what was decided, what processes are instituted, etc.  Is 
> there such a summary, and if so, where can I find it?

I don't know of one.  Here's my understanding.  

We have a directory in the MLton repository that is intended to
collect libraries.

  svn://mlton.org/mltonlib

Libraries are kept in the trunk directory, and are grouped according
to domain name, in the Java package style.  For example, Vesa, who
works at ssh.com, has been putting code at:

  svn://mlton.org/mltonlib/trunk/com/ssh

I, owning sweeks.com, have been putting code at:

  svn://mlton.org/mltonlib/trunk/com/sweeks

A "library" is a subdirectory of some such directory.  For example, my
basis-library replacement library is at

  svn://mlton.org/mltonlib/trunk/com/sweeks/basic

We use "transparent per-library branching" to handle library
versioning.  Each library has an "unstable" subdirectory in which work
happens.  When one is happy with a library, one tags it by copying it
to a stable version directory.  Stable libraries are immutable -- when
one refers to a stable library, one always gets exactly the same code.
No one has actually made a stable library yet, but, when I'm ready to
tag my library, I was thinking that I would do something like copying

  svn://mlton.org/mltonlib/trunk/com/sweeks/basic/unstable

to

  svn://mlton.org/mltonlib/trunk/com/sweeks/basic/v1

So far, libraries in the MLton repository have been licensed under
MLton's BSD-ish license. 

  http://mlton.org/License

We haven't decided on whether that will be a requirement to be in the
repository or not.  For the sake of simplicity (a single license) and
encouraging widest use of code, I would certainly like to encourage
contributors to use that license.  But it may be too strict to require
it.

If someone wants to contribute a new library to our repository or to
work on an old one, they can ask for commit rights to our SVN.  If
people want to work in their own repository, they can do so -- that's
the point of using domain names to prevent clashes.  The idea is that
a user should be able to bring library collections in from many
different repositories without problems.  And those libraries could
even work with each other.

At some point we may want to settle on an MLB path variable for the
root of the library project.  Or, we could reuse SML_LIB, and migrate
what we currently keep there into the library infrastructure -- that
seems like the way to go to me.

> If there's a particular email I missed that did summarize this
> information, I'll be happy to put it on the MLton.org wiki if
> someone will tell me where it ought to go.

A logical place would be 

  http://mlton.org/Libraries

However, that page is already in use.  I think it would be best if
that page became the page for the library project, and if many of the
libraries currently there were integrated into the project
infrastructure.



More information about the MLton mailing list