inheritance for functor ?

inheritance for functor ?

[Christophe Raffalli]

The "open" feature for module and module type does not add any
construtor to a module. It would be nice to also have an "inherit" or
"import" constructor that would add all the constructor of a module to
the current module.

Here si an example:

I could write this:

module type Ring =
  sig
   type t                          (*les elemnets de l'anneau seront de
type t*)  
    val zero : t                   (*definition de l'element nul*)
    val one : t                    (*definition de l'unite*)
    val t_of_int : int -> t
    val (++) : t -> t -> t         (*definition de la somme pour
l'anneau*)
    val (--) : t -> t -> t         (*definition de la soustraction*)  
    val ( ** ) : t -> t -> t       (*definition de la multiplication*)
    val (==) : t -> t -> bool
    val opp: t -> t
    val print : t -> unit 

  end

module type Field =
  sig
   import Ring   
    val (//) : t -> t -> t
  end

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

This feature reflects more the intention of the programmer.

 
-- 
Christophe Raffalli
Laboratoire de Mathématique / LAMA
Université de Savoie
UFR SFA, Campus Scientifique
73376, Le Bourget du Lac CEDEX, FRANCE.

URL: http://www.logique.jussieu.fr/www.raffalli
email: Christophe.Raffalli@univ-savoie.fr

inheritance for functor ?

[David Monniaux]

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

Re: inheritance for functor ?

[Jerome Vouillon]

On Thu, Sep 03, 1998 at 10:53:05PM -0700, David Monniaux wrote:
> 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.

Actually, this is possible: if the class is declared virtual in the
signature of the module, 'new classtype' is not exported:
    # module M = struct class c = object end end;;
    module M : sig class c : object end end
    # module M1 : sig class virtual c : object end end = M;;
    module M1 : sig class virtual c : object end end
    # new M1.c;;
    One cannot create instances of the virtual class M1.c
It is also possible to only export the class type, therefore also
preventing inheritance:
    # module M2 : sig class type c = object end end = M;;
    module M2 : sig class type c = object end end

> 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?

It is possible to write a function that coerce an object and add it to
a list :
    # let (<<) x y = (y :> widget) :: x;;
    val << : widget list -> < .. > -> widget list = <fun>
This way, coercions are hidden:
    [] << (foobar constructing a label) << (foobar constructing a button)

-- Jerome Vouillon