[MLton] library naming

[Vesa Karvonen]

[Apologies, my comments below are less coherent and contain more
redundancy than I'd like, but I don't have the time to edit them.]

Quoting Stephen Weeks <sweeks at sweeks.com>:
[... http://mlton.org/pipermail/mlton/2006-October/029177.html ...]

I think you make good points, but I still think that starting with even a
brief introduction to the library is better than just commiting it more or
less silently.

When I start work on a library I definitely have some motivation and try
to define a scope (preferably as small as possible) for the library.  I
often welcome/invite naming suggestions from others.  I don't think that
it is really a hurdle (an *artificial* barrier) to need to think about or
elaborate on such issues.  I think that if one is not able to articulate
on such issues then the library concept (if one even exists) is not yet
ready for publication.

I think that encouraging people to write a brief introduction to their
library is not a significant barrier to entry.  The point of introducing
libraries is to encourage others to take a look at the library, invite
feedback, and, most importantly, open the door for collaboration.  I think
that without an introduction most libraries will go unnoticed, unused, and
won't get any contributions from others.  Such an introduction would also
be a crucially important first step towards documenting the library.

The intention behind having a minimal submission process isn't to choose
the right library among peers and give it special status.  Rather, the
point is to encourage collaboration.

About the OpenGL bindings.  Coming up with a directory structure to hold
multiple different OpenGL bindings (or, for example, multiple parser
combinator libs) shouldn't really be that difficult.  OTOH, I don't know
about the OpenGL wrappers specifically, but, in general, it is much better
to have a single good wrapper than several half-baked ones (and possibly
have separate higher-level libs on top of lower level bindings).

Different people focus on different design aspects and have different
requirements in mind when they design libraries.  When those people
discuss the issues (often through critique) it tends to lead to superior
designs.  And I still don't mean to disallow multiple alternative
approaches.  We should definitely make sure that people feel welcome to
submit their work and that there is room for alternative approaches.

What I'm getting at is that without having those discussions you don't
even know what the alternative approaches are.  Even if the alternatives
are different enough that a merge doesn't make sense, having the
discussions tends to improve the designs through having a much a better
understanding of the design and requirements spaces.

About the "basis-replacement".  Perhaps you are too ambitious.  I would
definitely feel anxious about submitting or starting to develop a complete
replacement for the basis library by myself.  I would probably feel less
anxious about suggesting replacements for some subsets of the basis
library.  Also, I would probably feel much more confident about such a
project after introducing it briefly (say a *maximum* of one page of text
listing the core ideas) on the MLton list and getting feedback on the
ideas, possibly encouragement for the work, or even contributions.

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" :).
Also, while the approach does technically enable sharing (and
collaboration), it doesn't necessarily encourage it.  IOW, I fear that
a "project hosting" service doesn't make a significant (enough) impact.

As a case in point, I have done roughly 3 different kind of parser
combinator (PC) library drafts in SML.  I'm pretty sure that many people
have done at least a couple of PC libs for personal use.  If I would
google a bit, maybe send a few e-mails, I'd probably be able to get the
sources to many such libs.  The problem is that most of those really are
just toys (have no way to report good error messages, hold on to the entire
input (space leak), have a cumbersome or otherwise odd notation (subjective))
and aren't really suitable for anything serious.  Having a few dozen
half-baked PC libs in an easily accessible place doesn't really improve
things.  Someone needs to bite the bullet and start a serious PC lib design
(I'm working on a translation of Parsec).  While such a project isn't a
monumental effort it could definitely benefit from collaboration.  Still
there are several approaches to PC lib design (deterministic, backtracking,
arrows, monads, ...) and there is room for several serious PC libs.  But I
just don't see much benefit in having slightly easier access to a dozen
half-baked PC libs.

However, I admit that there is value in a project hosting service and I
agree that it may, over time, lead to production of well-crafted, high-quality
libs.  I just fear that the loose social framework makes progress very slow.
I doubt that it is possible to produce truly high-quality libraries without
having the design discussions.  The sooner the communication happens the
better.

-Vesa Karvonen