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 SAA09747; Mon, 5 May 2003 18:39:05 +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 SAA09116 for ; Mon, 5 May 2003 18:39:04 +0200 (MET DST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h45Gd3T13982 for ; Mon, 5 May 2003 18:39:03 +0200 (MET DST) Received: from ibm3.cicrp.jussieu.fr (ibm3.cicrp.jussieu.fr [134.157.15.3]) by shiva.jussieu.fr (8.12.9/jtpda-5.4) with ESMTP id h45Gd1ru093920 ; Mon, 5 May 2003 18:39:01 +0200 (CEST) Received: from ibm1.cicrp.jussieu.fr (ibm1.cicrp.jussieu.fr [134.157.15.1]) by ibm3.cicrp.jussieu.fr (8.8.8/jtpda/mob-V8) with ESMTP id SAA21838 ; Mon, 5 May 2003 18:38:08 +0200 Received: from localhost (fernande@localhost) by ibm1.cicrp.jussieu.fr (8.8.8/jtpda/mob-v8) with ESMTP id SAA4022380 ; Mon, 5 May 2003 18:38:08 +0200 Date: Mon, 5 May 2003 18:38:08 +0200 (DST) From: Diego Olivier Fernandez Pons To: "Yaron M. Minsky" cc: Caml List Subject: Re: [Caml-list] Two types of efficiency (Was Efficiency of 'a list) In-Reply-To: <1052135863.2398.6046.camel@dragonfly.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Antivirus: scanned by sophie at shiva.jussieu.fr X-Spam: no; 0.00; pons:01 cicrp:01 caml-list:01 library':01 api:01 okasaki:01 ralf:01 hinze:01 baire:01 improvment:01 chris:01 fernandez:01 ocaml:01 caml:01 olivier:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Bonjour, > You're kidding, right? You're making a classic "best is enemy of > the good" mistake here. Yes, there are lots of implementations, and > it's not clear which of them is absolutely optimal. That doesn't > mean ocaml shouldn't provide built-in support for one "good-enough" > solution. Such support doesn't preclude using whatever the optimal > algorithm is for the situation. But most of the time, it works > fine, and having built in support improves the usability of the > language greatly. Having various algorithms/data structures improves the usability of the language greatly, that is absolutely true. But what you are describing is more the need of a 'large, standard and uniform data structure library' than 'build-in' support. - large, to handle all kind of situations - standard, to insure compatibility - uniform, to be able to switch easily between different implementations > I for one have never quite understood why the Set and Map modules > only provide modular implementations, and why the API is relatively > weak. The Map and the Set modules of the standard library in Caml are a good starting point : they may not be as complete as you would have liked, of course but they will improve with time. Keep in mind that designing a data structure library is a hard work : Chris Okasaki, Ralf Hinze and a lot of others have failed ; Baire has not even been released after 1 year of work, the geometric algorithms in JDSL (Java data structures library) never arrived and after 2 years the new version 2.1 does not provide any real improvment over 2.0.6, etc. The Caml standard library is in the 'not so bad' category Diego Olivier ------------------- 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