Re: [Caml-list] lablgtk polymorphic variants question

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

From: Ruchira Datta <datta@math.berkeley.edu>
> Jacques Garrigue wrote:
> >LablGTK uses an encoding of widget types, in variant types, were
> >variant types are used as capacities. This can seem a bit unusual, but
> >you can see it in the fact the Gtk.obj abstract type is contravariant.
> 
> The contravariance annotation became possible in 3.01, so the code failed
> to compile for me while presumably the author succeeded in compiling it.

To be more precise, covariance annotations suppressed the need for
explicit coercion functions that were provided in lablgtk 1.00, but as
a result some types are a bit weaker than before: the coercion
function only asked its argument to be of type [> `frame] obj (we know
that only subtypes of Gtk.frame obj have this type anyway), but
coercion base on covariance annotation requires more (does not make
any assumption about other properties of the library).

> I guess you couldn't use the regular OCaml objects,
> with a normal class hierarchy reflecting the GTK class hierarchy,
> because the physical storage for the object actually resides elsewhere 
> (i.e., under the control of the GTK C library)?

Yes, you need a first "raw" layer to build upon.

> So, using polymorphic
> variants instead of Ocaml objects lets you still keep the class hierarchy,
> and your functions reflect subtypes properly given the proper variance
> annotation.  You don't need to worry about virtual methods or anything, 
> because the OCaml function just calls the C method anyway, which will take 
> care of that.  Is my understanding correct?

Basically yes, but variants are only used here in an abstract way (you
cannot actually match on them), and actually using objects for that is
also possible.
type frame = < widget : unit; container : unit; bin : unit; frame : unit >
with a covariant Gtk.obj type, would also work. This is just more
verbose, since you need to associate a type to each pseudo-method,
whereas this means nothing here.

> Perhaps someone who understands the issues could give a small example
> showing exactly what would be wrong with an OCaml class hierarchy
> which just mirrors the GTK class hierarchy?

I'm not sure of what you are asking for. If this is about directly
providing a hierarchy of concrete classes, you explained yourself that
this is not possible because the actual implementation is on the C
side. On the other hand, I just explained above how you could encode
the GTK hierarchy with pseudo object types, and recover the expect
covariance.

Hope this helps.

     Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr