Re: [Caml-list] Dynamically evaluating OCaml code

[Markus Mottl <markus@oefai.at>]

On Thu, 08 Apr 2004, John Goerzen wrote:
> > > (While we're at it, I think it's silly that there is a list and an
> > > array type).
> > 
> > I beg your pardon - what else do you have in mind???
> 
> One type that can do both.

That's a very bad idea, IMHO.  The efficiency tradeoffs are so large
for certain operations that I'd never put anything like this into a
standard library.

Arrays, for example, are something that should definitely be part of
a standard library, because the compiler can perform some extremely
valuable optimizations for them (e.g. unboxing).

> Of course.  Do you think that obtaining slices of a list or printing the
> current time in a human-readable format are not standard problems?  If
> so, I would have to point out to you that there is a quite lengthy
> history that supports my position on this.

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.

> And I should not *have* to interface to C just to print out a date &
> time or parse the time.  See, your attitude is part of the problem --
> your position is that "it's not hard to reinvent the wheel."

No, my point is that it's easy enough to write such a library.  You don't
have to make it standard.

> My position is that all the easy reinvention that has to happen adds
> up to something that is hard, and goes against principles of code
> sharing, since every OCaml programmer is going to reinvent things
> slightly differently.

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

> And you haven't even addressed my complaints about
> 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?

> If you limit the universe of "most problems" to be numerical analysis,
> you may well be quite accurate.

This has nothing to do with academic vs. commercial applications.
Numerical analysis isn't even my main topic of interest.  It's all a
question of how contributions should be made to OCaml.  Putting an ever
increasing number of functions into the standard library is probably
not the solution.

> However, such a limitation is going to be misleading if you are talking
> about more general problems.  I have zero need for numerical analysis
> tools here, and in the grand scheme of things, needs for them make up
> a small minority of needs.

I wouldn't want to see numerical analysis in the standard library
either so this is a strawman argument.  Ideally, the standard library
would contain only functionality that is critical for making the
compiler/runtime work.  Everything else could be fetched from some
central repository.

> These are also real needs.  I regularly need to deal with times and
> humans.  I also have done some work with archivers and the like, and the
> problems highlighted here are real.  I have several machines that are
> only reachable by IPv6, and this is a huge problem for me wrt OCaml.
> OCaml apps are the only ones I have trouble with in this regard.

Again: I believe you that you need this functionality.  I just don't
think that all of this should be part of a standard library.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

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