Re: [Caml-list] Type visibility limitation in recursive modules

["\"Márk S. Zoltán\"" <zoltan.s.mark@dravanet.hu>]

Peng Zang wrote:
> I do not know if this is the intended behavior.  It may very well be.  
> However, it appears we can easily work around this by simply abstracting the 
> type later.  Eg.
>
> module rec Aleph :
>     sig
>         type t = Tag of Beth.t
>     end =
>     struct
>         type t = Tag of Beth.t
>     end
> and Beth :
>     sig
>         type t = Aleph.t list
>         val scandalous : Aleph.t
>     end =
>     struct
>         type t = Aleph.t list
>         let scandalous = Aleph.Tag((* HERE BE DRAGONS *) [])
>     end
>
> module Beth = (Beth:sig type t val scandalous : Aleph.t end)
>
>
> # Beth.scandalous;;
> - - : Aleph.t = Aleph.Tag []
> # Aleph.Tag [];;
> - - : Aleph.t = Aleph.Tag []
> # (Aleph.Tag []) = Beth.scandalous;;
> - - : bool = true
>
> Happy Holidays,
>
> Peng
>
>   
Agreed, this does work for the code on the outside, but I wanted to hide 
the actual gory details of Beth.t from the implementation of Aleph too. 
The real-life Aleph contains a huge mess of inherited code (inherited 
from myself, but I wrote it years ago), plus some serious potential for 
quasi-macaronic growth. I wanted to make sure that none of that code 
makes assumptions about Beth.t, because the choice of Beth.t could 
easily have serious performance implications, and I would like to 
isolate the rest of the code from the impact of Beth.t turning overnight 
into an Aleph.t array or worse. That can only be done if the 
implementation of Beth is the only place where the details of Beth.t are 
known.

This is not exactly a showstopper issue for me, though. The reason I 
posted it was that (1) I suspect this is a bug (more likely a design 
bug, not an implementation one), and I like finding bugs, or (2) this is 
a pointer into something I really should understand about modules, and 
with any help I will understand it soon, as more replies come in.

Happy Holidays,

      Z-