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 PAA01943; Tue, 20 Mar 2001 15:02:01 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA01782 for ; Tue, 20 Mar 2001 15:02:00 +0100 (MET) Received: from tet.kurims.kyoto-u.ac.jp (isdnppp2.kurims.kyoto-u.ac.jp [130.54.16.103]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f2KE1v919042 for ; Tue, 20 Mar 2001 15:01:57 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by tet.kurims.kyoto-u.ac.jp (8.11.1/8.11.1) with ESMTP id f2KE3gv00648; Tue, 20 Mar 2001 23:03:42 +0900 (JST) (envelope-from garrigue@kurims.kyoto-u.ac.jp) To: datta@math.berkeley.edu Cc: caml-list@inria.fr Subject: Re: [Caml-list] lablgtk polymorphic variants question In-Reply-To: <20010319212326.A1126@blue1.berkeley.edu> References: <20010319212326.A1126@blue1.berkeley.edu> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010320230342S.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 20 Mar 2001 23:03:42 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Ruchira Datta > 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