Re: [Caml-list] Dynamically evaluating OCaml code

[Bruno.Verlyck@inria.fr]

   Date: Thu, 8 Apr 2004 10:30:56 -0500
   From: John Goerzen <jgoerzen@complete.org>

I hate posting to such long threads, but if you care:

   glaring socket omissions, read/write files handles, string slicing,
- sockets (esp. IPV6): I've no full solution.
- read-write file handles: You can get them wit Unix.openfile and
  Unix.dup.  Then with Unix.{in,out}_channel_of_descr, you can use
  the Pervasives I/O functions.
- string handling: look at my (rather full-featured) Cstr library
  (http://pauillac.inria.fr/cash/cstr/); it doesn't answer syntax
  questions, but those are a different matter.  It doesn't implement
  negative indices, but if you dare looking at the sources, *maybe*
  only the check- macros have to be modified.

As for lists, I saw a message from someone trying to implement SRFI 1,
but no further announce.  I feel that it really calls for mutable
lists, with are less in OCaml's spirit, and you'll miss syntactic
sugar.

   Here are some other functions that I have in C, Python, Perl 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()
Some of them are in Unix, some in Filename, some others (under other
names) in Cash (http://pauillac.inria.fr/cash/), with another view to
file descriptors / Caml channels.

For mknod, as an emergency measure, I'd fork the mknod command.

As for flags that aren't in Unix (or ulimit), you touch a strong
problem for library implementors: they are defined only for some OSes,
and are a pain to implement and test when you have no personal use for
them.  Yes, laziness.  On the other hand, you ask for free lunch.

(Another pain is making any general library, moreover part-time; even
Cstr, which is not big, nor very complicated, that I didn't design,
took me five times what I thought; OK, I played some games with
camlp4, but documenting and testing it is a lot of boring work).

HTH,
Bruno.


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