From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA17220; Thu, 8 Apr 2004 17:30:59 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA17289 for ; Thu, 8 Apr 2004 17:30:58 +0200 (MET DST) Received: from gatekeeper.elmer.external.excelhustler.com (gatekeeper.excelhustler.com [68.99.114.105]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i38FVojq013401 for ; Thu, 8 Apr 2004 17:31:51 +0200 Received: from chatterbox.elmer.internal.excelhustler.com (unknown [192.168.0.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "chatterbox.elmer.internal.excelhustler.com", Issuer "excelhustler.com" (not verified)) by gatekeeper.elmer.external.excelhustler.com (Postfix) with ESMTP id 1996BE01A1; Thu, 8 Apr 2004 10:30:56 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id C7D435C006; Thu, 8 Apr 2004 10:30:55 -0500 (CDT) Received: from wile.internal.excelhustler.com (wile.internal.excelhustler.com [192.168.1.34]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 702295C005; Thu, 8 Apr 2004 10:30:55 -0500 (CDT) Received: by wile.internal.excelhustler.com (Postfix, from userid 1000) id 182E34A01E; Thu, 8 Apr 2004 10:30:56 -0500 (CDT) Date: Thu, 8 Apr 2004 10:30:56 -0500 From: John Goerzen To: Ocaml Mailing List Subject: Re: [Caml-list] Dynamically evaluating OCaml code Message-ID: <20040408153056.GB30763@excelhustler.com> References: <20020104004356.GA1672@mev> <20040408133727.GC29195@excelhustler.com> <20040408145606.GA18473@fichte.ai.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040408145606.GA18473@fichte.ai.univie.ac.at> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Scanned-By: clamscan at chatterbox.elmer.internal.excelhustler.com X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 dynamically:01 2004:99 char:01 parses:01 hurts:01 reinvent:01 reinvent:01 lacks:01 python:01 basename:01 localtime:01 ulimit:01 flags:01 recvfrom:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 151 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