Browse thread
The OCaml Community (aka back from the Developer Days)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 <darioteixeira@yahoo.com> 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 > http://uk.promotions.yahoo.com/forgood/ > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >