Re: [Caml-list] does class polymorphism need to be so complicated?

[Benjamin Geer <ben@socialtools.net>]

Jacques Garrigue wrote:
 > [explanation of issues concerning method polymorphism]

Thank you for explaining this.

> To speak truly, the current syntax is based on the assumption that you
> won't define often polymorphic methods, and that defining them is a
> work for library designers, not for the average end user.

I think that one of the things that would improve life a great deal, for 
people wanting to write applications in Caml, would be the existence of 
many more libraries.  Unfortunately, I think languages become popular 
not mainly because of how expressive they are, but because of the 
libraries available in them.  Therefore, in order to help Caml become 
more widely used, it would be a good idea to make things as easy as 
possible for library authors.  (That's actually why I came to this list; 
I want to write libraries in Caml, to make it more generally useful for 
writing applications.)

Moreover, a library user needs to handle the library's own polymorphism. 
  For example, suppose there were a Caml API for accessing databases, 
and that this API consisted entirely of class types, intended to be 
implemented by Caml 'drivers' for different databases.  The library user 
would get a #connection; the class implementing #connection would be 
determined by the driver (and would never be known by the library user). 
  In this way, the user could switch to a different database by 
switching to a different driver, without having to change any 
application code.  In order to pass around this #connection object 
within the application, the library user would have to write polymorphic 
methods.

> This also means that you have a number of workarounds hiding this
> heavy syntax to the end user, even when he has to define such a
> method.
> 
> For instance you could be provided a virtual class printer:
> 
> class virtual printer : object
>   method virtual print : #printable -> unit
>   method ...
> end
> 
> Then you would use it as
> 
> class my_printer () = object
>   inherit printer
>   method print obj = ...
> end

That's somewhat better, but it means that every class must be derived 
from a virtual base, even when there's no other reason for it.

> P.S. Having a lighter syntax for polymorphic methods might be a good
> idea. But since we must keep it explicit enough, the improvement would
> be quite limited. The best I can think of is something like:
>    method 'a. print (obj : #printable as 'a) = ...
> Maybe a bit better, but also more complicated to handle.

I think that would definitely be an improvement.

> An advantage of such a syntax is that it could also be used in normal
> "let rec" to provide polymorphic recursion.

That would be a big advantage in my view.

Ben

-------------------
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