Christophe Raffalli writes:

 > module type Euclidian_Ring =
 >   sig
 >    import Ring
 >    type nt
 >     val norm : t -> nt
 >     val leq : nt -> nt -> bool
 >     val (//) : t -> t -> t
 >     val (mod) : t -> t -> t
 >     val div_mod : t -> t -> t * t
 >   end

inherit would not add another keyword.

Such a feature looks highly desirable (especially for examples such as
yours, with mathematical structures). Also, it looks easy to implement.

High fives to the implementors for let module = ... in ...

Remark: it's not possible to hide a 'new classtype' function in a
signature. That looks useful in certain circumstances, like mlgtk with
its classes taking a pointer into a C structure as a
parameter. However, this is not a must at all; after all, the library
user is supposed to be big enough to understand that some functions
shouldn't be used, period.

Now about mlgtk. I've recently had demands for it. I plan to add all
the gtk library functions and the data structure accessors as soon as
possible. Partial versions will be posted on my WWW page
(http://www.eleves.ens.fr:8080/home/monniaux).

Talking of which, what are the perspectives on variances? In ML-gtk, I
have classes such as button, label, all descending from
widget. Certain functions take a widget list as an argument. The
problem is that the user has to do the casts manually:

[((foobar constructing a button) :> widget);
 ((foobar constructing a label) :> widget)]

which is quite heavy. Is there any way to make it look better?

-- 
David Monniaux, PhD student at ENS, Paris, France
Now at: Computer science laboratory  SRI International
        Formal methods group         Menlo Park, CA, US
http://www.csl.sri.com/~monniaux