From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA27056; Tue, 20 Mar 2001 06:23:30 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA27026 for ; Tue, 20 Mar 2001 06:23:29 +0100 (MET) Received: from math.berkeley.edu (gold.Math.Berkeley.EDU [169.229.58.61]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f2K5NSL15880 for ; Tue, 20 Mar 2001 06:23:28 +0100 (MET) Received: from blue1.math.Berkeley.EDU (blue1.Math.Berkeley.EDU [169.229.58.58]) by math.berkeley.edu (8.9.3/8.9.3) with ESMTP id VAA08769; Mon, 19 Mar 2001 21:23:27 -0800 (PST) Received: (from datta@localhost) by blue1.math.Berkeley.EDU (8.9.3/8.9.3) id VAA11429; Mon, 19 Mar 2001 21:23:26 -0800 (PST) Date: Mon, 19 Mar 2001 21:23:26 -0800 From: Ruchira Datta To: caml-list@inria.fr Subject: Re: [Caml-list] lablgtk polymorphic variants question Message-ID: <20010319212326.A1126@blue1.berkeley.edu> Reply-To: datta@math.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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