Re: [Caml-list] OCaml standard library improvement

[Brian Hurt <brian.hurt@qlogic.com>]

On Fri, 21 Feb 2003, Amit Dubey wrote:

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

I vote for LGPL myself.  I have a Priority Search Queue implementation 
I'll submit:
http://www.informatik.uni-bonn.de/~ralf/talks/ICFP01.pdf

With respect to strings, I think what we need is a good regular expression 
parsing library.  Something less powerful than Ocamllex, but more powerful 
than strchr.

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

Long term, I'd perfer to see it become part of the standard distribution.  
If you can gaurentee that it's always there, it'll be a lot more widely 
used.



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

- We shouldn't be afraid to add functions/functionality to libraries.  
There should never be a string2 library, let alone a string17 library.

- We shouldn't be afraid to add new libraries either- for different 
functionality.  Regular expression parsing, for example, shouldn't be in 
the string library.

This sounds contradictory, but it's not (quite).  Every library should
have a clear domain.  I look at it in terms of code: libraries should come
in one of two forms- either collections of simple related routines with no
common infrastructure, or collections of routines which share a common 
infrastructure.

So the string library would be a collection of simple routines.  None of
the routines in string call each other, or any common 'infrastructure'
routines.  Regular expressions have infrastructure- routines to create and 
manipulate DFAs and NFAs if nothing else.  That common infrastructure then 
defines it as a seperate library- the library of everything using that 
infrastructure.

Just my $0.02.

Brian


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