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