English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Shared types: dependency in modules with polymorphic type
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-05-14 (07:58)
From: Hugo Ferreira <hmf@i...>
Subject: Re: [Caml-list] Shared types: dependency in modules with polymorphic type
Hi Jacques,

Jacques Carette wrote:
> One modification which will get you a long way towards your goal is to 
> remove the : VB from
> Hugo Ferreira wrote:
>> module VB1 : VB
>> = struct  ...
> While this may look like it is just "type checking", it in fact does 
> more and makes sure that VB1.t, to the outside world, is abstract.  This 
> stops any possibility of unification with 'like' types.  Same with Make_U.
> Note that VB1 will still be of type VB, and you can be sure of that 
> because the constraint in Make_U's signature will enforce it -- only a 
> bit later than at declaration time, at use-time.

Understood. I was only thinking of the interface.

>> My question is: is their any way I may organize the modules or
>> indicate shared types in order to use a (very extensive) VB
>> interface (Or VB1 module)? Specifically how do I enforce the
>> shared type:
>>  U1.instance VB1.t = U1.t = Make_U(VB1).t
> First, try the above.  It may help.  If it does not, then you will need 
> to add explicit sharing constraints.  But which sharing constraints are 
> *really* needed will be the ones revealed by first removing the type 
> annotations you currently have.

Worked correctly. However I need only remove the U in Make_U : U and
change it to a simple Make_U. "U1.t" now becomes visible and binds

> Note that you should not have to re-organize your modules at all to 
> achieve this [at least, not in this example].

Worked like a charm. No additional changes.

Thank you,
Hugo F.

> Jacques