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 UAA07140; Wed, 29 Sep 2004 20:59:42 +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 UAA07170 for ; Wed, 29 Sep 2004 20:59:41 +0200 (MET DST) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i8TIxeV8023137 for ; Wed, 29 Sep 2004 20:59:41 +0200 Received: by mproxy.gmail.com with SMTP id 79so3462236rnk for ; Wed, 29 Sep 2004 11:59:40 -0700 (PDT) Received: by 10.38.73.46 with SMTP id v46mr300904rna; Wed, 29 Sep 2004 11:59:39 -0700 (PDT) Received: by 10.38.75.19 with HTTP; Wed, 29 Sep 2004 11:59:39 -0700 (PDT) Message-ID: <7f8e92aa040929115962177c6a@mail.gmail.com> Date: Wed, 29 Sep 2004 21:59:39 +0300 From: Radu Grigore Reply-To: Radu Grigore To: Jon Harrop Subject: Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features Cc: caml-list In-Reply-To: <200409271754.36040.jon@jdh30.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040925225246.48566.qmail@web53010.mail.yahoo.com> <200409271411.30384.jon@jdh30.plus.com> <7f8e92aa04092706317dae6556@mail.gmail.com> <200409271754.36040.jon@jdh30.plus.com> X-Miltered: at concorde with ID 415B061C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 2004:99 generic:01 ocaml:01 sep:01 tree:02 iterators:02 iterators:02 wrote:03 wrote:03 stl:03 stl:03 iter:03 data:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 27 Sep 2004 17:54:35 +0100, Jon Harrop wrote: > On Monday 27 September 2004 14:31, Radu Grigore wrote: > > The > > difference is that after you write the iterators code for a new > > sequence-like data structure all the "generic" functions, not only > > fold but also map and others, will automagically work on them. > > I think this is the core of what we disagree on. Indeed. I think this is the problem. Efficiency is indeed a constraint that limits the usefuleness of iterators and the "find" function is a good example of this. When using STL you have to remember that for certain data structures (e.g. set) you have to use member functions if you want better performance that is available only on that data structure. But I do not think that it is such a severe limitation. For iter, map, and fold efficiency is not a problem. At least no counter-example comes to mind. Even more, the same implementation of fold can be O(n) for a list and O(n log n) for a tree. This is because the fold itself is O(n), while particular iterators are either O(1) or O(log n). regards, radu ------------------- 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