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 SAA24868; Thu, 8 Apr 2004 18:44:09 +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 SAA24093 for ; Thu, 8 Apr 2004 18:44:08 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i38Gj1jq022598 for ; Thu, 8 Apr 2004 18:45:02 +0200 Received: from fichte.ai.univie.ac.at (markus@localhost [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.6) with ESMTP id i38Gi4Hn020383; Thu, 8 Apr 2004 18:44:04 +0200 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.6) id i38Gi4t4020382; Thu, 8 Apr 2004 18:44:04 +0200 Date: Thu, 8 Apr 2004 18:44:04 +0200 From: Markus Mottl To: John Goerzen Cc: Ocaml Mailing List Subject: Re: [Caml-list] Dynamically evaluating OCaml code Message-ID: <20040408164404.GA19556@fichte.ai.univie.ac.at> Mail-Followup-To: John Goerzen , Ocaml Mailing List References: <20020104004356.GA1672@mev> <20040408133727.GC29195@excelhustler.com> <20040408145606.GA18473@fichte.ai.univie.ac.at> <20040408153056.GB30763@excelhustler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040408153056.GB30763@excelhustler.com> User-Agent: Mutt/1.4.1i 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 unboxing:01 reinvent:01 reinvent:01 tiresome:01 python:01 misleading:01 strawman:01 ideally:01 runtime:01 arrays:01 compiler:01 compiler:01 apps:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 164 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