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 PAA02886; Mon, 5 May 2003 15:33:10 +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 PAA03498 for ; Mon, 5 May 2003 15:33:09 +0200 (MET DST) Received: from mail3.tpgi.com.au (mail.tpgi.com.au [203.12.160.59]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h45DX7T06610 for ; Mon, 5 May 2003 15:33:08 +0200 (MET DST) Received: from ozemail.com.au (syd-ts22-2600-037.tpgi.com.au [203.26.30.37]) (authenticated (0 bits)) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h45DX0n05708; Mon, 5 May 2003 23:33:00 +1000 Message-ID: <3EB6680B.5000702@ozemail.com.au> Date: Mon, 05 May 2003 23:32:59 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "Yaron M. Minsky" CC: Caml List Subject: Re: [Caml-list] Two types of efficiency (Was Efficiency of 'a list) References: <1052135863.2398.6046.camel@dragonfly.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ozemail:01 caml-list:01 yaron:01 minsky:01 hypothesis:01 functorial:01 abstractions:01 functors:01 camlp:01 delegating:01 toxteth:01 glebe:01 2037,:01 9660:01 0850:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Yaron M. Minsky wrote: > You're kidding, right? You're making a classic "best is enemy of the > good" mistake here. With due respect, there is always the other side of the coin. What is thought to be "good enough" often enough turns out later to be ill-considered and a major disaster. Indeed one could make a hypothesis that this is *necessarily* the case, since "good enough" really means "we don't really understand the requirements". I'm not trying to flame, so much as suggesting that "when in doubt leave it out" isn't such a bad principle. As an example: functorial set interface vs. one using type variables. Well, most of us seem to think that the type variable interface is more convenient most of the time. But before the Ocaml team rushes ahead and provides it *in addition* to the existing functorial interface, it might be a good idea to enquire about how the two are related on a theoretical level. It might be an idea to devise some principle for deciding which kinds of interfaces to provide in a library, since the issue is likely to arise again. It may even be an idea to figure out if the theoretical relationship between the two representations can somehow be connected with language syntax so the transformation from one kind to the other can be done easily by a dumb user (like me), obviating the need for providing an exponential set of interfaces. The same applies to classes, since some data structures are mutable enough one wonder why classes weren't used, since dynamic binding to abstractions seems to provide some advantages over both type variables and functors in some circumstances. As an example: streams. Well, there WAS built in support for streams, but it was removed -- you can get the code to work now using camlp4, which is now part of the standard distribution. So just maybe strengthening camlp4 is better way forward then providing built-in syntactic support for more data structures: rather, it may be better to *eliminate* existing support, for example, for arrays (by delegating the job to camlp4). -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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