Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
The OCaml Community (aka back from the Developer Days)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-28 (21:48)
From: blue storm <bluestorm.dylc@g...>
Subject: Re: [Caml-list] Alterlib? (was "Re: The OCaml Community")
a) doesn't seem to be an option :
the INRIA won't include in stdlib things they don't want to maintain,
and they don't want to maintain anything more.

I don't think point c) is a really good idea : most people are quite
comfortable with Stdlib now. Do you have *really* good reasons to
create an interface-incompatible library ?
I don't think so : lots of people have expressed concern for the lack
of something in the Stdlib, but i haven't seen anybody actually
complaining about one of the provided functions (except for the
tail-rec thing, wich isn't an incompatible change).
If all the change you want to make are compatible (either addition of
plain new functions/modules, or interface-compatible changes of
existing ones), then i think the "overriding" model of Extlib is fine.
What does -nopervasives give us in that case ?

On 1/28/08, Dario Teixeira <> wrote:
> > My understanding is that the benefits would come from having a richer,
> > community developed "official" OCaml distribution.  So the stdlib
> > would stay in place, but extra items would be included as well.  For
> > example, package ExtLib and some commonly useful Camlp4 extensions
> > along with the distribution .tar.gz/.exe/.dmg.  If I understood the
> > meeting transcription in IRC, the official OCaml folks at INRIA would
> > bless this as the proper way to get and install OCaml once the
> > community structure is in place.
> Hi,
> For compatibility reasons, Stdlib must be part of any standard Ocaml
> distribution for the foreseeable future.  However, this does not
> necessarily mean that the only community solution must be to provide
> an ExtLib that complements Stdlib.  If it is felt that Stdlib+Extlib
> does not fit well together (different conventions, etc), there is
> always the option of creating "from scratch" a self-contained Alterlib
> that incorporates everything you would wish from a standard library.
> (note that I've written "from scratch" between commas because a lot
> of code from Extlib and other open-source libraries could be reused).
> Users who have heavily invested in Stdlib could continue using it;
> others, however, could very well choose to ditch it altogether and
> make sole use of Alterlib (with "-nopervasives", of course).
> In short, here are the options:
> a) modify Stdlib to suit the community's needs (complicated due
>    to copyright issues and because INRIA does not have the manpower
>    to effectively maintain all the additions);
> b) keep Stdlib and put all the community's needs into Extlib
>    (in a sense this the current situation; has the advantage of
>    being straightforward; has the disadvantage that the APIs
>    might not always go well together);
> c) keep stdlib for compatibility reasons (INRIA's tarball must
>    always include it), but provide a community built Alterlib
>    that reimplements what's good about Stdlib together with
>    stuff currently on Extlib (requires more work, but may
>    result in a more modern, more consistent library)
> Do I read the situation correctly?
> Kind regards,
> Dario Teixeira
>       ___________________________________________________________
> Support the World Aids Awareness campaign this month with Yahoo! For Good
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports: