Re: [Caml-list] Q: functors and "has a" inheritance

["Jocelyn Sérot" <Jocelyn.Serot@univ-bpclermont.fr>]

Thanks for the explanations, Gerd and Petter.

At least i now have a name for the wall i’m bumping into ;)

Gerd, i can’t figure out how your proposed workaround can solve the problem : if P is an argument of the Product functor, it has to be built before applying it, hasn't it ? So either we are back to the initial problem or we have to require that the end user manually builds it ? Am i missing sth ?

Incidentelly, i tried another workaround : instead of augmenting the [Myset] module for getting the [MysetA] module, i tried the other way : first define a SetA module with attributes attached to elements and then define a « normal » Set module by « hiding » some operations and redefining some others. Seems i’m stumbling on the same problem.. :( Could it be the case that functors just cannot support the reuse mechanism i’m seeking for ??

Jocelyn


Le 6 juil. 2016 à 12:15, Petter Urkedal <paurkedal@gmail.com> a écrit :

> On 2016-07-06, Jocelyn Sérot wrote:
>> Hi Nicolas,
>> 
>> Thanks fro your answer.
>> If i understand correctly, you mean that if i write, say :
>> 
>> module type S = sig type t val zero: t end
>> module type T = sig type t val zero: t end
>> module Make (X : S) = (struct type t = X.t * X.t let zero = X.zero, X.zero end : T)
>> module M1 = Make (struct type t = int let zero = 0 end)
>> module M2 = Make (struct type t = int let zero = 0 end)
>> 
>> then the compiler will never be able to deduce that M1.t and M2.t are indeed compatible. Am i right ?
> 
> Gerd nicely explained how, so I'm just add a note about why:
> 
> 1. If the module contained a function rather than a plain constant, it
>   would be undecidable in general whether the two structures were
>   equal.
> 
> 2. Even if we could (or adopted syntactic equality as an approximation),
>   it would break abstraction:  Structures imported from or depending on
>   external libraries could be coincidentally equal at some point and
>   different after an upgrade.
> 
> So, we would be left with a rather ad-hoc rule about how to compare
> structures.  The nominal approach taken by OCaml is consistent even if a
> bit conservative.  Note that module paths may include functor
> applications.