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 EAA08941; Mon, 27 Sep 2004 04:04:29 +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 EAA09688 for ; Mon, 27 Sep 2004 04:04:27 +0200 (MET DST) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i8R24QO9019841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Sep 2004 04:04:27 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay03.plus.net with esmtp (Exim) id 1CBksM-000M9e-Bq for caml-list@inria.fr; Mon, 27 Sep 2004 02:04:26 +0000 From: Jon Harrop To: caml-list Subject: Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features Date: Mon, 27 Sep 2004 02:59:43 +0100 User-Agent: KMail/1.6.2 References: <20040925225246.48566.qmail@web53010.mail.yahoo.com> <200409261951.52609.jon@jdh30.plus.com> <7f8e92aa04092613141479823e@mail.gmail.com> In-Reply-To: <7f8e92aa04092613141479823e@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200409270259.43863.jon@jdh30.plus.com> X-Miltered: at concorde with ID 4157752A.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 isomorphic:01 2004:99 generic:01 generic:01 abstraction:01 templating:01 iterator:01 hofs:01 abstraction:01 preserving:01 avoiding:01 ocaml:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sunday 26 September 2004 21:43, skaller wrote: > The requirement is for a polyadic map. > Here is the type signature: > > map: ('a -> 'b) -> 'a 'F -> 'b 'F I'm confused. There is no code common to both List.map and Array.map, so what is being factored out into this "polyadic map" apart from this (invalid!) type? > Note: the output must have exactly the same shape > as the input: map preserves shape, it only changes > the values stored in the 'slots' of the data structure. > So a weird tree or graph has to come out isomorphic > to its input. This makes sense for array and list but what about sorted containers (e.g. set)? On Sunday 26 September 2004 21:14, Radu Grigore wrote: > I think the idea is that you can't write a _generic_ map. All you did > above is a dipatcher that gives the job to a specialized map function: > List.map2. What is the difference between a generic function and a function which dispatches to appropriate specialised functions? > The accumulate function in C++ is not a simple dispatcher. > It can implement the logic of "fold" because there is an extra level > of abstraction: iterators. I'd say that templating over the iterator type in C++ is equivalent to writing a HOF which accepts a fold in OCaml. In think, therefore, that HOFs are exactly the "extra level of abstraction" you speak of. Iterators often provide extra functionality, like the ability to go backwards. I think John calls the ability to control the iteration, rather than be controlled by it (e.g. by having fold call your given function on each element in order) "control inversion". However, I haven't found need of this because all the algorithms I use are written in terms of fold, map etc. > But what John says is possible in FISh (namely, writing a generic, > shape preserving map) sounds quite cool. Perhaps, but I'm not sure what this costs - I assume there is a sound theoretical reason for avoiding such types. In practice, I'm all for aggressive factoring but I can't see what we're factoring here... Cheers, Jon. ------------------- 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