[Caml-list] lablgtk polymorphic variants question

[Caml-list] lablgtk polymorphic variants question

[Ruchira Datta]

I tried to compile lablgtkmathview but ran into an error.  I would guess
that it probably compiled under OCaml 3.00 but doesn't for me since I have
3.01.  I have lablgtk 1.2.0.  (Everything is from Sven Luther's Debian
packages, except lablgtkmathview and mlminidom which don't seem to be
packaged yet.)  The error:

File "gMathView.ml", line 61, characters 36-58:
This expression has type [ `frame] Gtk.obj but is here used with type
  Gtk.frame Gtk.obj
Type [ `frame] is not compatible with type
  Gtk.frame = [ `widget | `container | `bin | `frame] 

The offending line is:

 method get_frame = new GBin.frame (MathView.get_frame obj)

The declaration of MathView.get_frame is on lines 85-86 of gtkMathView.ml, 
in module MathView:

  external get_frame : [>`math_view] obj -> [`frame] obj =
   "ml_gtk_math_view_get_frame"
 
The declaration of Gtk.frame is on line 95 of gtk.ml:

type frame = [`widget|`container|`bin|`frame]

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.

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

Re: [Caml-list] lablgtk polymorphic variants question

[Sven LUTHER]

On Sun, Mar 18, 2001 at 10:13:50PM -0800, Ruchira Datta wrote:
> I tried to compile lablgtkmathview but ran into an error.  I would guess
> that it probably compiled under OCaml 3.00 but doesn't for me since I have
> 3.01.  I have lablgtk 1.2.0.  (Everything is from Sven Luther's Debian
> packages, except lablgtkmathview and mlminidom which don't seem to be
> packaged yet.)  The error:

Yes, there are packages of it, Stefano Zacchiroli did them, and i uploaded
them for him, since i am sponsoring him, and he is not yet a debian
maintainer. Please contact him at : zack@cs.unibo.it.

Friendly,

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

Re: [Caml-list] lablgtk polymorphic variants question

[Jacques Garrigue]

From: Ruchira Datta <datta@math.berkeley.edu>

> I tried to compile lablgtkmathview but ran into an error.  I would guess
> that it probably compiled under OCaml 3.00 but doesn't for me since I have
> 3.01.  I have lablgtk 1.2.0.  (Everything is from Sven Luther's Debian
> packages, except lablgtkmathview and mlminidom which don't seem to be
> packaged yet.)  The error:
[...]
> The declaration of MathView.get_frame is on lines 85-86 of gtkMathView.ml, 
> in module MathView:
> 
>   external get_frame : [>`math_view] obj -> [`frame] obj =
>    "ml_gtk_math_view_get_frame"

This is wrong. This should be:
  external get_frame : [>`math_view] obj -> Gtk.frame obj =
    "ml_gtk_math_view_get_frame"

> The declaration of Gtk.frame is on line 95 of gtk.ml:
> 
> type frame = [`widget|`container|`bin|`frame]
> 
> 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.

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.

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

Re: [Caml-list] lablgtk polymorphic variants question

[Stefano Zacchiroli]

On Mon, Mar 19, 2001 at 10:43:05AM +0100, Sven LUTHER wrote:
> On Sun, Mar 18, 2001 at 10:13:50PM -0800, Ruchira Datta wrote:
> > I tried to compile lablgtkmathview but ran into an error.  I would guess
> > that it probably compiled under OCaml 3.00 but doesn't for me since I have
> > 3.01.  I have lablgtk 1.2.0.  (Everything is from Sven Luther's Debian
> > packages, except lablgtkmathview and mlminidom which don't seem to be
> > packaged yet.)  The error:
> 
> Yes, there are packages of it, Stefano Zacchiroli did them, and i uploaded
> them for him, since i am sponsoring him, and he is not yet a debian
> maintainer. Please contact him at : zack@cs.unibo.it.

no Sven, I did the package of gtkmathview and minidom that are written
in C++ not in OCaml.

-- 
	- Zack -

Stefano Zacchiroli <zack@cs.unibo.it> ICQ# 33538863
Home Page: http://www.students.cs.unibo.it/~zacchiro
Undergraduate Student of Computer Science at University of Bologna, Italy
SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134)
	"Information wants to be Open"
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] lablgtk polymorphic variants question

[Jacques Garrigue]

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

Re: [Caml-list] lablgtk polymorphic variants question

[Ruchira Datta]

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

Re: [Caml-list] lablgtk polymorphic variants question

[Ruchira Datta]

Sven LUTHER wrote:
>On Sun, Mar 18, 2001 at 10:13:50PM -0800, Ruchira Datta wrote:
>> I tried to compile lablgtkmathview but ran into an error.  I would guess
>> that it probably compiled under OCaml 3.00 but doesn't for me since I have
>> 3.01.  I have lablgtk 1.2.0.  (Everything is from Sven Luther's Debian
>> packages, except lablgtkmathview and mlminidom which don't seem to be
>> packaged yet.)  The error:

>Yes, there are packages of it, Stefano Zacchiroli did them, and i uploaded
>them for him, since i am sponsoring him, and he is not yet a debian
>maintainer. Please contact him at : zack@cs.unibo.it.

You uploaded them where?  I searched unstable and didn't find them.  I
even looked in Incoming.  I had already installed libgtkmathview0,
libgtkmathview-bin, libgtkmathview-dev, libminidom0, and libminidom-dev,
if you were referring to any of those.  The two I am referring to are
the OCaml bindings.  If the versions I downloaded from Luca Padovani's
site (namely mlminidom-0.0.1 and lablgtkmathview-0.2.2) had been packaged,
they would have had dependencies on ocaml(>=3.00), and what I am finding
is that lablgtkmathview would also have had another dependency on 
ocaml(<=3.00).  But I will contact Stefano Zacchiroli as you suggest.

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