Re: [Caml-list] A G'Caml question" + additional info

[Markus Mottl <markus@mail4.ai.univie.ac.at>]

On Wed, 11 Jul 2001, Krishnaswami, Neel wrote:
> For instance, I recently wrote yet another set implementation, because
> the functorial interface to the Set module in the standard library
> wouldn't let me use it in a fully polymorphic fashion.

This is a shortcoming of the standard library that there are no
polymorphic implementations of "Set" and similar. It's very easy to
extract a polymorphic (module-) version from the existing code. Note
that the non-polymorphic version also has advantages for users: e.g. they
don't have to pass around comparison functions all the time.

> If the Set library had been written using OCaml's object system,
> then I would not have had to redo my own.

I disagree: a lot of important functionality cannot be easily replicated
with objects alone - at least not in a reasonable way. Just imagine
using the "map" function on an object version of "Map":

The type system won't allow you to implement this function in its full
generality within the class. If you implement it outside with a normal
function, you either have to use very inefficient add-operations or
have to reveal the datastructure (breaks interfaces) or you have to do a
tricky module/class combination (function sees internals, module hides
representation using abstract types), which immediately eliminates the
benefits of objects (you'd have to use an abstract type anyway rather
than operate on object types).

> From this experience I conclude that the right thing is to use the
> features that offer the nicest degree of modularity and reusability.

Right. That's why I almost exclusively prefer modules over objects... ;)

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr