Re: [Caml-list] Troublesome nodes

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Dario Teixeira <darioteixeira@yahoo.com>

> I would like to add one extra, odd, tidbit.  On a simple example, 'private'
> will only work if a dummy constructor is added to the type.  Thus, this will
> not work:
> 
> module rec Node:
> sig
>         (* ... *)
>         type (+'a, 'b) t = private 'a constraint 'a = [< super_node_t]
>         (* ... *)
> end =
> struct
>         (* ... *)
>         type (+'a, 'b) t = 'a constraint 'a = [< super_node_t]
>         (* ... *)
> end

I don't understand your counter-example. In typechecks without any
problem, even in older versions. May you did cut it down too much?

> But this will:
> 
> module rec Node:
> sig
>         (* ... *)
>         type (+'a, 'b) t = private Dummy of 'a constraint 'a = [< super_node_t]
>         (* ... *)
> end =
> struct
>         (* ... *)
>         type (+'a, 'b) t = Dummy of 'a constraint 'a = [< super_node_t]
>         (* ... *)
> end =

You Dummy creates a datatype, so this is a completely different story.
Recursion is freely allowed in datatype definitions, while there are
restrictions for abbreviations.

> Is this behaviour correct?  (I'm running 3.11+dev12)

I cannot tell you, since I couldn't reproduce your problem.

By the way, I somehow get the feeling that your solution is
over-engineered. You shouldn't need all that many constraints.
I you could find a way to use private rows rather than private
abbreviations, your code might be much simpler.
But I'm sorry I couldn't follow the whole discussion on your problem.
I you could summarize it shortly, with the basic code (without phantom
types) and the invariants you are trying to enforce, I might try to
look into it.

Jacques Garrigue