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 PAA01233; Sun, 25 Apr 2004 15:55:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA00921 for ; Sun, 25 Apr 2004 15:55:55 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3PDtqYM029136 for ; Sun, 25 Apr 2004 15:55:53 +0200 Received: from [192.168.1.200] (ppp119-113.lns1.syd2.internode.on.net [150.101.119.113]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i3PDtkZq076533; Sun, 25 Apr 2004 23:25:49 +0930 (CST) Subject: Re: [Caml-list] [ANN] The Missing Library From: skaller Reply-To: skaller@users.sourceforge.net To: Benjamin Geer Cc: james woodyatt , The Caml Trade In-Reply-To: <408BA602.5090506@socialtools.net> References: <20040423185148.GA4434@excelhustler.com> <20040423195206.GA27257@tallman.kefka.frap.net> <20040423202342.GA5962@excelhustler.com> <20040423223611.33ef1c08@haddock.max.fr> <20040423211003.GD6783@excelhustler.com> <20040423213325.GF6783@excelhustler.com> <93448C92-9685-11D8-891D-000A958FF2FE@wetware.com> <408BA602.5090506@socialtools.net> Content-Type: text/plain Message-Id: <1082901345.9537.326.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 25 Apr 2004 23:55:46 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 joking:01 incompatible:01 stepanov:01 discarding:01 allocators:01 refining:99 functorial:01 generalise:01 'map':01 supplies:99 callback:01 inverted:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-04-25 at 21:50, Benjamin Geer wrote: > Are you joking? Have you ever tried to write a program using several > mutually incompatible libraries? > > Before C++ had STL, everyone wrote their own string class. Surely you > can imagine the resulting contortions when libraries with different > string classes had to be used together. I was an active member of the C++ committee at that time. There was a set of classes in the Working Draft. A string class, IOstreams, some other things. All independently designed and voted on. It was a mess. A Standard string class. Better than no Standard. Then Alex Stepanov gave a brief talk on a library being developing at HP, based on an older Ada library. The ideas were new (to the C++ committee). But there was a coherent design, and stated design *principles* based on mathematics, built by researchers. Almost the *whole* Standard C++ library was overturned at the next meeting in a single vote in favour of STL, and what wasn't thrown out completely was modified to conform to the container-iterator-algorithm framework. Changes in the C++ language itself were then almost exclusively driven by the requirements of STL, partial specialisations in particular. The committee actually did a very good job firming up the details, discarding non-essential components, and writing detailed specifications -- although they made a few very serious mistakes, developing allocators being the worst disaster (they should have been thrown out completely). The result is, in my opinion, the best CS library EVER built. Its just a pity the C++ language doesn't have what it takes to drive it (lexical scoping like ML has). My conclusion from this process is: a loose community is no more capable of designing a coherent library than a high level programming language. A small high power research team is needed for that. But a small research team is just as incapable of industrialising a library: filling out the details, following the principles layed down, enriching and refining, testing and debating. That requires a larger community. A brief note on the theory behind STL: we don't understand it. I have an inkling. STL does two things that you can't do in Ocaml. (1) It provides functorial polymorphism. Iterators generalise over data structures themselves, not merely their value type. (2) Iterators provide control inversion. Compare the functional 'iter' and 'map' like HOF's of Ocaml, where the user supplies a callback, with the control inverted algorithms of STL, which use iterators to demand the data. I'm not criticizing Ocaml or it's library here, rather I'm making a point about process. The Ocaml library is a loose collection of things, like the C++ library before STL came along. Turning the Ocaml library over to the community before the reseachers have a coherent design will be a disaster. Holding onto it afterwards will be too. IMHO: the Ocaml team is doing the right thing. The Standard library is being kept small, being upgraded slowly, whilst the main emphasis is where it needs to be to support a new, coherent, library design. The type system. I think it's time to say thanks for the good work! Keep it up! .. and to ask: how can we help better? -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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