Re: [Caml-list] [ANN] The Missing Library

[John Goerzen <jgoerzen@complete.org>]

On Sat, Apr 24, 2004 at 12:08:15AM +0200, Basile STARYNKEVITCH wrote:
> On Fri, Apr 23, 2004 at 04:10:03PM -0500, John Goerzen wrote:
> > > I'm getting bored of this song. What about this one :
> > > "The number of extlibs is a symptom of the problems with the
> > > community of OCaml users" ?
> 
> > You view it as a problem that some in the OCaml community would like to
> > see a more featureful and easy to use standard library?  Why?
> 

[ snip ]

> I think that the standard library is actually rather perhaps too big,
> than too small!

If you are advocating splitting bits of the standard library into a
centrally-maintained community resource, that makes a lot of sense to
me.  If you are repeating the argument that "feh, task x can be
trivially done with less than 10 lines of code!", then I disagree
completely.  Which is it? :-)

> It is a pity that 2 libraries named ExtLib exist, and it is certainly
> not the fault of OCaml team (I tend to believe that one of the ExtLib
> named library is nearly dormant, and I invite the author of this
> library to rename it).

I agree.

> especially when compared to the US or to Japan), I don't think that it
> is the goal of INRIA to code lots of external libraries, or even to
> manage the naming of many packages, which is a very labor-consuming

I have never asked that they do that, nor do I expect them to.  However,
we have a somewhat unfortunate situation.  INRIA does, for whatever
reason, maintain a large OCaml library -- probably the largest in
existance and certainly the most widely distributed.  This same library
is, in the opinion of some, lacking in features which INRIA has for
plenty of understandable reasons (lack of time, etc.) not implemented.

Now we are stuck.  If I were to write "John's unix" or "John's str",
they would be incompatible with the standard unix or str.  Code using
modules written for one could not just automatically use modules written
for another.  (I assume there are some exceptions here, but probably not
many.)

So I think there are three good ways to move forward:

1. INRIA devotes more resources to the library;

2. INRIA becomes much more active with accepting patches from people
   in the community and communicates better with the community;

3. INRIA splits off Unix (and perhaps others such as dbm, labltk, etc)
   for the community to maintain.  INRIA could, at their option,
   bundle snapshots of these community efforts with various OCaml
   releases to ensure no loss of functionality with a standard install.

> INRIA is not a big commercial company like Sun. So the goals of INRIA
> w.r.t. Ocaml are not similar to the goals of Sun w.r.t. Java. And the

I'm not sure that is a bad thing :-)

> Everyone can contribute to Ocaml by developping libraries, and
> advertising them (e.g. thru the Hump). If there is a name clash, it

What what do you say to the compatibility problems I've raised?

To be sure, there are yet technical obstacles, such as difficult
installation and build systems, but from the recent discussion on those,
I am accepting that they will be resolved.

> should be socially resolved, and it is not a research goal to solve it
> (this is why it is not INRIA's job to solve such conflicts, and
> solving such "managing" or "social" problems is extremely time
> consuming, hence very costly).

I agree again.  Let the community do its thing.  But if they are to do
that, you must let them by not insisting on bundling dated software with
the standard distribution.

> In my opinion, the standard library should be kept small, and should
> contain only the functions commonly needed to the compiler and to all
> the Ocaml software produced by INRIA in relation to the OCaml language
> (e.g. compilers and similar tools). The standard library should
> certainly not becomes the union of all useful OCaml modules (from the
> Hump - which is more a Bazar, while the core Ocaml software, including
> the standard library, is a Cathedral).

I have no problem with that CPAN-like approach.  Personally, I prefer
Python's approach, but CPAN works too :-)  Of course, there's nothing
stopping INRIA from taking compatibly-licensed stuff from the community
and bundling it with OCaml.

> Regarding standard libraries, they should be kept small, because they
> have to be learnt with the language. I believe that one of Common Lisp
> problems (and perhaps source of failure) is the huge size of its
> standard library, which is intimidating.

I'm not sure about CL, but I can heartily echo that sentiment with Java.
Regardless of the final outcome of the library, it should be
well-planned.

> Again, everything above is my own opinion, not those of INRIA (where I
> happen to work currently) - I am not paid to talk for INRIA! But I
> think that there is too much criticism w.r.t. to the work on Ocaml
> done at INRIA. "C'est la rançon du succès" (I leave this last sentence
> in French).

Please don't take my messages that way; I do not mean them like that at
all.  I understand completely how INRIA has constraints like everyone
else and am not complaining that they don't put more resources to it.

I do think the state of affairs is bad.  I think we need to fix it.  And
I think that INRIA has to be involved in that fix, even if their
involvement ends with saying "Here, have at it; this is no longer part
of OCaml" or "Here, have at it; we'll sync with your CVS when we make a
release" or something along those lines.  I'm not asking INRIA to solve
all the world's problems.  Just to decide whether or not they want to
:-)

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners