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

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Benjamin Geer <ben@socialtools.net>

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

Sure.
There's no intent to make it difficult.
The idea is only that being a bit more verbose on a declaration that
is hopefully made only once in a hierarchy is not that bad.

The real problem actually is not verbosity, but the fact you have to
understand that there can be two levels for polymorphism: the class or
the method. I think that's not that immediate, and I don't want to
bother beginners with that. We'll see the impact on Java programmers
when they will get generics.

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

Here there may be a deeper misunderstanding about the ocaml type
system: if a subclass does not add methods to its superclass, its type
does not change.
That is, I would expect all connections to have the same type, and as
a result there is no need for considering the more general
#connection.

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

OK, there's also another way to do it, without inheritance. I just
tried not to be confusing.

class type printer = object
  method virtual print : #printable -> unit
end

class my_printer () = object (self : #printer)
   method print obj = ...
end

Looks a bit strange at first, but it does the work.

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

Might consider it. But its a rather big change in the language, so
this requires some more study.

Jacques

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