Re: [Caml-list] OCaml standard library improvement

[Amit Dubey <adubey@CoLi.Uni-SB.DE>]

Fran Valverde writes:
> But if *we* (I am including all OCaml programmers here) think it worth 
> building such a library, why bother the OCaml team by piling *more* work 
> on them? As somebody in this lists has pointed out, they are already 
> doing *harder* work on the (may I have my interest included here) module 
> recursion problem & downcasts and whatnot and I trust their capability 
> (and willingness) to work in whatever problems they think it worth.
> 
> Why not (self?)appoint, say, three persons (I don't care about many more 
> with decision power to come to an agreement about anything) to receive 
> would-be code and maintain a "big-s(c)ale library"... This may find its 
> way into the Standard library or it may not, but would definitely make 
> happy all these people wanting to contribute differentially to the whole 
> OCaml effort...
> 
> Just an idea... Something to discuss...
> 
> Regards,
> 
>         Fran Valverde


    I've been following the discussion, and I think it's a good idea.
I have to code submit, but one thing that (unfortunately!) needs
to be discussed is the license.  I usually don't follow the license threads
on this list, so I apologize if this post smacks of ignorance, but
I would suggest the LGPL is probably a good bet for such a library.
Any other suggestions?  (I am ambivalent myself, and would be happy
with the GPL or BSD licenses).

    Another note, do people think that hosting such a project on
Sourceforge might be a good idea?  If there are positive replies,
(in particular, I would be interested to hear what the core Ocaml
developers think of this idea), I will volunteer to register the
project.


Nicolas George writes:
> There is a problem to solve before it: the confusion between modules
> (used as namespace units) and compilation units. Supose you have a large
> set of string functions, tu split, search for words, replace, and so on.
> You want them all in one module, since you do not want to remember that
> split_on_char is in String42, but split_on_chars is in String17. But you
> do not want that as soon as you use the trivial split_on_char function,
> your resulting binary includes all the bloat for KMP word search.

    This is a good point, Nicolas.  However, my feeling is that this
may not be a big problem in the begining, and it might be difficult
devising a logical way to split things before we know enough about the scope
of the problem.  I'd suggest the best solution here would be to start off
keeping everything together.  If there is too much bloat, things could be
split up into smaller modules, with some larger modules that "include"
other ones to provide backwards compatibility.


    -Amit Dubey

-------------------
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