Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen <jgoerzen@complete.org>]

On Thu, Apr 08, 2004 at 05:26:54PM +0200, Markus Mottl wrote:
> On Thu, 08 Apr 2004, Richard Jones wrote:
> > which returns the first n members of a list.  As for slicing the
> > middle from a list, I tend to think that the original poster should
> > probably be using a different, more suitable structure.  Perhaps an
> > Array if he wants random access.
> 
> That's also my opinion: it's usually an indication of a bad choice
> concerning datastructure if you need such list functions.

One does not always have the choice of data structure.  Sometimes, and
this happens to be the case in several programs I've worked on recently,
the inadequecies arise when I'm trying to get data frmo an older system
into an OCaml-based one that does use more suitable structures.

For instance, consider this problem, which is a simplified version of a
real problem...  I am reading a line-oriented file delimited by "|".
It's easy enough to split this apart into a list (even though I must go
to Str and regexps to do it, grr).  

Now, I know that I must ignore the first two and last three elements in
that list.  I do not know in advance what size the list will be, and it
varies from line to line, but it always has at least five elements.  I
also do not necessarily know the values for "2" and "3" at compile time,
though they are constant throughout execution of the program.  The order
of the elements is significant and must not be altered.  Each element is
the same type (ie, a String).  There is nothing in the data itself that
differentiates it.

Now, which OCaml data structure gives me the ability to easily pull out
such a slice?  As far as I can tell, there are no standard functions for
any of Array or List to do that.  I could write a function for either of
them to loop over it and get me what I want, but the point is that this
functionality is useful.

Now, there are arguably other ways to do this; I could use a complex
regular expression to pull out the data in the center... ie:

  ([^|]*\|){2}(.*)(\|[^|]*){3}

may do the trick in this particular example, but not always.  (What if,
instead of lines, I am dealing with packets coming in off the network?)

One does not always get data handed to onesself on a platter, already
nicely ordered and suitable for storing in a nice structure (in any
language).  Hell, half the time my first step is to -- yes -- convert to
ASCII.  (I sometimes have to work with data coming from an AS/400, an
EBCDIC system that is thankfully being phased out)

> I absolutely agree with you!  But the point is: is this really so
> important to have it in the _standard_ library?  You didn't mention the
> word "standard" so I suppose you'd be perfectly happy if somebody wrote a
> fully-featured library for this kind of functionality?  And you'd rather
> like to see better "social tools" for making use of such contributions?

I don't really care if it comes in ocaml.tar.gz or not, for some of
these things.  Some of them absolutely should, especially more powerful
string/array/list slicing, IPv6, and POSIX interfaces.  But many of the
rest don't exist at all or require contortions to use.  (For instance,
there are two libraries out there named Extlib, both of which implement
some of what I want with little overlap between them.  How annoying.)

I see these as critical ommissions from the actual standard library:

 * IPv6 and other socket-related and DNS-related problems
 * Lack of support for read/write handles in Pervasives (relegated to
   Unix and with complex interactions between the two)
 * String/array/list indexing/slicing improvements
 * Standard C/POSIX date/time functions
 * Path manipulation functions (about 75% of these are already there;
   I have no idea why the other 25% aren't)
 * mknod() and similar functions  (we have mkfifo(), after all...)

These are all enhancements of functionality already present in the
standard library.  Why would I be able to use the standard library for
IPv4 but have to go elsewhere for IPv6?  That doesn't really make sense.

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