Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features

[Jon Harrop <jon@jdh30.plus.com>]

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