Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen <jgoerzen@complete.org>]

On Thu, Apr 08, 2004 at 04:56:06PM +0200, Markus Mottl wrote:
> On Thu, 08 Apr 2004, John Goerzen wrote:
> > Also, there is no string_of_char function (I'd have to use fill).
> 
> That's not quite true: there is "String.make", which does what you want.

Yep, I missed that.

> > Similar complaints exist for working with subsets of lists; it's really
> > too hard to say "replace elements 4 through 9 with this", "delete
> > elements 4 through 9", "return elements 4 through 9", etc.
> 
> Yes, it's hard to do this with the current standard library.  The question
> is: who needs these functions anyway?  I can't remember ever having felt
> a need for them.

I need them all the time.  Just because you may not doesn't mean that
they are never needed.  For instance, I may get back a list of results
from a function that parses a network stream or a report, and I know
that I can always discard the first two and last three.  This is a
fairly common occurance here.

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

> > Yes, I could write functions to do all of this, but my point is that
> > I shouldn't have to.
> 
> The point of the standard library is not to have a function for every
> imaginable problem but to have ones that cover standard problems.

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.

> > This library problem hurts productivity, and in some cases makes OCaml
> > less productive than even C.
> 
> Things are not half as bad as you describe them here.  There may be
> cases where C is more productive - because you happen to have a library
> function for the problem.  But even in this case you can just interface
> to C, which is really not that difficult.

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

> There are surely cases where the OCaml standard library lacks generally
> useful functionality, but it's usually good enough for most problems.

Yes, "good enough", I'll buy that.  Barely.  But it's still *far* behind
other languages.  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:

realpath()
asctime()
strftime()
strptime()
basename()
dirname()
localtime()
gmtime()
ulimit()
getaddrinfo()
The following flags for recv/recvfrom: 
  MSG_WAITALL
  MSG_TRUNC
  MSG_ERRQUEUE
The following formats for socket():
  PF_INET6, PF_PACKET, PF_APPLETALK 
recvmsg()
mknod()
mountpoint()
ioctl()

These ommissions mean that I cannot write the following types of
programs in OCaml that I could in Python or Perl (and mostly, Java):

 * Any client or server that uses IPv6
 * Any file archiver or extractor
   + I cannot write a tar extractor in OCaml because no mknod() exists
   + I cannot write a general-purpose tar archiver in OCaml because
     mountpoint() does not exist (and I'd need that to implement -l)
 * Any kind of process (ie, server) that wishes to assert ulimit limits
   over its children (web servers restricting CGIs would be one example)
 * Any kind of program that reads or writes times obtained from
   the system in human-readable format
 * Things that need to obtain path information from relative paths
   in a secure manner that has no side-effects
 * A network tracer (tcpdump)
 * Audio programs (ioctl)
 * Tape backup utilities (ioctl)

These are all things that are in libc.  Most are specified in POSIX as
well and have been implemented widely for about 15 years.

If you limit the universe of "most problems" to be numerical analysis,
you may well be quite accurate.  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.

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.

I do *not* need to do these things in a "system-level" language such as
C.  Perl and Python are both quite well suited to the ask, and OCaml
would be too if its standard library were more complete.  There is
nothing in the fundamental design of OCaml that prevents this.  In some
cases, it's just a matter of missing some constants from the system's .h
files.

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