Q: about type inclusion

Q: about type inclusion

[Christian Boos]

[Summary: it seems that module type inclusion doesn't use the notion of
          class subtyping. Is there a theoretical reason for that or
	  could it be done in the future ?]

Hello,

  I was at first puzzled by an error message saying "type x is not included
in type y", because type x was a class inherited from class y, until I realized
that there is two distinct notions of type inclusion in the langage : 
module type inclusion and class subtyping. 
  However, I don't see why they couldn't mix, in particular on the example
given at the end of this message.

Any comments welcomed !

------------------------------------------------------------------

[Resume: il semblerait que l'inclusion entre types de modules n'exploite
         pas les relations de sous-typage entre classes. Y a-t-il une
         impossibilite quelque part ou bien est-ce realisable ?]

Bonjour,

  Bien que presentant de nombreuses similitudes, l'inclusion entre types
de modules et le sous-typage entre classes sont deux choses distinctes dans
le langage. Cependant je n'entrevois pas les raisons d'une incompatibilite de 
fond entre les deux, notamment celle conduisant a produire une erreur sur 
l'exemple ci-apres.

------------------------------------------------------------------

    module type A =
	  sig    class a (unit) =  method a : int  end     end
  
    module type B =
	  sig    class a (unit) =  method a : int  method b : int  end     end
  
  
    module Bimpl = 
	  struct    class a () =  method a = 1  method b = 2  end   end
  
   
    module B = (Bimpl : B)  (* of course *)
    
    (* but *)
   
    module A = (Bimpl : A)  

Characters 16-21:
Signature mismatch:
Modules do not match:
  sig class a (unit) = method a : int method b : int end end
is not included in
  A
Class types do not match:
  class a (unit) = method a : int method b : int end
is not included in
  class a (unit) = method a : int end
# 



-- Christian 

Re: Q: about type inclusion

[Jerome Vouillon]

Hello,

>   I was at first puzzled by an error message saying "type x is not included
> in type y", because type x was a class inherited from class y, until I realized
> that there is two distinct notions of type inclusion in the langage : 
> module type inclusion and class subtyping. 
>   However, I don't see why they couldn't mix, in particular on the example
> given at the end of this message.

There are two reasons for that.  First, the abbreviations must remain
the same. In your example, type Bimpl.a expands to < a: int; b: int >,
whereas A.a would expand to < a: int >.  Second, the method a (for
instance) is typed assuming that the type of self is an instance of
< a: int; b: int; .. >.  In particular, method a could invoke method
b, and expect it to return an int.  If your example did succeed, the
type of self in class A.a would only by constraint to be of the shape
< a: int; .. >, which is not correct: this is a more general type than
the previous one, and then nothing prevents you anymore to add a
method b of type bool in the subclass of A.a. 

So, it is not possible to hide public methods a posteriori.

-- Jerome

> ------------------------------------------------------------------
> 
>     module type A =
> 	  sig    class a (unit) =  method a : int  end     end
>   
>     module type B =
> 	  sig    class a (unit) =  method a : int  method b : int  end     end
>   
>   
>     module Bimpl = 
> 	  struct    class a () =  method a = 1  method b = 2  end   end
>   
>    
>     module B = (Bimpl : B)  (* of course *)
>     
>     (* but *)
>    
>     module A = (Bimpl : A)  
> 
> Characters 16-21:
> Signature mismatch:
> Modules do not match:
>   sig class a (unit) = method a : int method b : int end end
> is not included in
>   A
> Class types do not match:
>   class a (unit) = method a : int method b : int end
> is not included in
>   class a (unit) = method a : int end
> # 

Functors & Classes (was Re: Q: about type inclusion)

[Christian Boos]

Hello,

I just want to make a few additional comments on this old (18 April)
discussion:

Jerome Vouillon writes:
 > 
 > 
 > Hello,
 > 
 > C. Boos writes:
 > >  I was at first puzzled by an error message saying "type x is not 
 > > included in type y", because type x was a class inherited from class y, 
 > > until I realized that there is two distinct notions of type inclusion 
 > > in the langage : module type inclusion and class subtyping. 
 > >  However, I don't see why they couldn't mix, in particular on the 
 > > example given at the end of this message.
 > 
 > There are two reasons for that.  First, the abbreviations must remain
 > the same. In your example, type Bimpl.a expands to < a: int; b: int >,
 > whereas A.a would expand to < a: int >.  Second, the method a (for
 > instance) is typed assuming that the type of self is an instance of
 > < a: int; b: int; .. >.  In particular, method a could invoke method
 > b, and expect it to return an int.  If your example did succeed, the
 > type of self in class A.a would only by constraint to be of the shape
 > < a: int; .. >, which is not correct: this is a more general type than
 > the previous one, and then nothing prevents you anymore to add a
 > method b of type bool in the subclass of A.a. 
 > 

 > So, it is not possible to hide public methods a posteriori.

OK, I see. The problem is that this last hypothetical method b : bool 
could be called in place of the original method b : int, which will
be dynamically overriden. But C++ distinguishes virtual and non-virtual
methods : if O'Caml does the same thing, would this problem disappear ?

Then it would be possible to mix functors and classes. I think that now
this is a rather difficult task. Given a functor F of type A -> B, 
a class A.c  specifies a set of methods that needs to be matched EXACTLY
when you implement the c class. 
This is too constraining, because when you use different implementations, 
you often need different additional methods as well.

Maybe there are other ways than using explicit non-virtual public methods
(use private methods ?) for specifying a base class in a functor, 
but with the current language I don't see how.


------------------------------------------------------------------

Bonjour,

J'aimerais juste refaire un  commentaire sur cette vieille discussion.


> [voir plus haut]

> So, it is not possible to hide public methods a posteriori.

OK, mais le probleme vient du fait qu'une methode publique peut etre
surchargee dans une sous-classe ? Si comme en C++, les methodes 
virtuelles et non-virtuelles etaient distinguees, il serait possible
de "cacher" a posteriori les methodes publiques non-virtuelles ?

Du coup, on pourrait utiliser conjointement les classes et les foncteurs,
parceque j'avoue que jusqu'a maintenant, je me suis casse les dents sur ce
probleme.

En effet, si dans un foncteur de type F: A -> B, on specifie une classe A.c, 
dans tous les modules implementant cette classe, on doit utiliser
EXACTEMENT les memes methodes pour c, ni plus ni moins. 
C'est trop contraignant pour etre utilisable en pratique, puisque si l'on a 
des modules differents, c'est en general qu'on a des implementations 
differentes, et donc besoin de methodes additionelles differentes.

Peut-etre y a-t-il d'autres facons de faire, avec des methodes privees par 
ex., pour arriver a specifier une classe de base dans un foncteur, 
mais en tout etat de cause, avec le langage actuel je ne vois pas.


-- Christian