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 KAA16215; Fri, 5 Jul 2002 10:42:51 +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 KAA16702 for ; Fri, 5 Jul 2002 10:42:51 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g658gof11756 for ; Fri, 5 Jul 2002 10:42:50 +0200 (MET DST) Received: (from fpottier@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16276 for caml-list@inria.fr; Fri, 5 Jul 2002 10:42:50 +0200 (MET DST) Date: Fri, 5 Jul 2002 10:42:49 +0200 From: Francois Pottier To: caml-list@inria.fr Subject: Re: [Caml-list] Re: generic programming Message-ID: <20020705104249.B14853@pauillac.inria.fr> Reply-To: Francois.Pottier@inria.fr References: <200207030246.WAA28665@dewberry.cc.columbia.edu> <4.3.2.7.2.20020703102610.0248b280@mail.d6.com> <3D246739.4030204@ozemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <3D246739.4030204@ozemail.com.au>; from skaller@ozemail.com.au on Fri, Jul 05, 2002 at 01:18:17AM +1000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Jul 05, 2002 at 01:18:17AM +1000, John Max Skaller wrote: > > Only two data structures in Ocaml readily admit iterators: lists and arrays. > Other data structures like hastables, sets, maps, etc, have control > inverted iterators, which are much weaker (that is, you have to provide > a callback which is given each value in turn This is true, and I might add that they are *intended* to be weaker. Programming with an explicit `iter' or `fold' is much more structured than using an iterator; it is more compact and makes your intent more apparent. (This idiom is perhaps difficult to read for non-functional programmers, but the same is true of many features in many languages.) I find that the use of iterators is very seldom necessary. One typical instance is when you need to simultaneously iterate over two trees which have the same fringe, but not necessarily the same shape. Then, you may use `iter' to iterate over one tree, but need an iterator to traverse the other. I think this kind of situation arises rather seldom. Lastly, I should insist (as shown in my previous posting) that this is not a language issue; it's a library issue. O'Caml's standard library offers stack-based iterators, but no stateful iterators. This design choice is meant to encourage a functional programming style and I support it. > The real problem for STL style iterators is this: in C++, > the very point of iterators is that container independent > algorithms can be written. There is no easy way to do this in Ocaml, > at least not without using classes. This is wrong... why classes? (read on) > are known as data functors). Hence, we have > > List..map > Array.map > Hashtble.map > > etc, instead of just 'map' . Certainly, but you can parameterize your code over `map' (that is, write as a higher-order function or as a functor) and then apply it to a version of `map' for the particular data structure at hand. > Functorial polymorphism can be implemented for a wide class > of functors in an extension of ML: there is work being done > by Barry Jay at UTS on this. As far as I understand, this work is about automatically *generating* code for `map' from the definition of a data type, which is another issue. O'Caml as it stands already allows you to write `container independent' code. > Perhaps some of the type theorists reading the above text can give > a better and more proper explanation. But basically: C++ allows > polymorphism over data functors, but that polymorphism is NOT > parametric like it should be. Entirely true. I call that textual polymorphism :) -- François Pottier Francois.Pottier@inria.fr http://pauillac.inria.fr/~fpottier/ ------------------- 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