Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen <jgoerzen@complete.org>]

On Thu, Apr 08, 2004 at 06:44:04PM +0200, Markus Mottl wrote:

[ snip ]

> I feel that this question really also touches the recent discussion
> concerning library management.  If it were very easy to make use of
> contributed code, we wouldn't talk so often about extensions to the
> standard library.

[ snip ]

> I agree here: that's why I'd like to see more social tools rather than
> extensions to the standard library.  It's tiresome to search the web
> for already invented wheels, downloading code, compiling it (hopefully
> without problems), installing it and keeping it up-to-date (including
> libraries that it depends on).

Yes.  That would make sense for a lot of things.  The Humps are already
fairly usable for finding things, but installing them can be a different
matter.

I have to think twice before using things not in the standard library
for code that others will run because I must consider the complexity of
setting them up.  Some libraries don't compile out of the box on systems
that lack ocamlopt; others require various amounts of Makefile hacking
to see correct paths, etc.

Perl has a fairly small standard library but a very easy method to add
on to it (CPAN).  That works well.

Python has a fairly large standard library and an almost-as-easy method
to add on (setup.py; you have to download but install is easy).  That
works well, too.


> > IPv6 and other glaring socket omissions, read/write files handles,
> > string slicing, and IMAP libraries.  Should I add a few more?  Here are
> > some other functions that I have in C, Python, Perl (and, for the most
> > part, even Java) that are missing from OCaml:
> 
> I am not questioning the fact that OCaml could need more libraries for
> more functionality.  I am questioning that all of this should become
> part of a standard library.  I wouldn't mind seeing the code there, of
> course, but why burden the developers with tasks that could be done by
> the community?  What is "standard" anyway?  Only what INRIA calls one?
> Or what is used predominantly by the community?

I'd have no problem with having a more broad standard definition than
INRIA.  The reason I've been talking about the standard library thus far
is that basic support for some of the things I'm looking for already
exists there, so it would seem silly to reinvent it all somewhere else
-- not to mention the complexity that would cause with two competing
interfaces for the same task.  As an example, there's IPv6 support.  The
standard library already has IPv4 support, and given that, the amount of
effort required to add IPv6 is relatively small, and most of the
existing interfaces could be reused.  So to me, the standard library is
the only place it makes sense to put IPv6 (unless, for instance, INRIA
and the community decided to totally split off networking to a separate
module).

What it comes down to is that we need to have clearly-defined guidelines
for what goes into INRIA's standard library and what doesn't, and they
have to be sensible.  Something like "IPv4 yes, IPv6 no" or some date
functions but not others is not a good long-term solution.

Otherwise, we'll have some people using the INRIA functions (they may
not need the functionality that's lacking) and others using whatever
add-on library exists.  And it can be tough to integrate the two types
of code into a single system.

[ snip ]

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