Re: [Caml-list] lablgtk polymorphic variants question

[Ruchira Datta <datta@math.berkeley.edu>]

I had written:
>> I guess I don't fully understand polymorphic variants.  It would have seemed
>> to me that if (new GBin.frame) expects an argument of type Gtk.frame, then
>> something of type [ 'frame] should satisfy it.  Why should it be necessary
>> that all four variants [`widget|`container|`bin|`frame] be able to occur?
>> I thought that the inferred type of a function would always allow less 
>> variants in its argument.

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.

I see that the polymorphic variants chosen in LablGTK reflect the GTK
class hierarchy.  For example, in gtk.ml is the declaration

type radio_menu_item =
	[`widget|`container|`bin|`item|`menuitem|`checkmenuitem|`radiomenuitem]

and the class hierarchy says:

 GtkObject
  +GtkWidget
  | +GtkContainer
  | | +GtkBin
  | | | +GtkItem
  | | | | +GtkMenuItem
  | | | | | +GtkCheckMenuItem
  | | | | | | `GtkRadioMenuItem

I understand that the function being contravariant means the opposite of
>> I thought that the inferred type of a function would always allow less 
>> variants in its argument.
my last quoted sentence holds.  I can see that, for example, any function
which expects a bin object ([`widget|`container|`bin]) should also accept
a frame object ([`widget|`container|`bin|`frame]).  So, the functions
have to be contravariant, i.e., have to allow more variants in the 
argument.  Looking at mlgtk, I see that there the GTK class hierarchy
doesn't show up at all.  Everything is directly a subclass of
Gtk.Unsafe.gtkobject.  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)?  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?

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?

Thanks,

Ruchira Datta
datta@math.berkeley.edu
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr