Re: [Caml-list] Troublesome nodes

[Jon Harrop <jon@ffconsultancy.com>]

On Sunday 13 July 2008 18:39:07 Dario Teixeira wrote:
> Hi again,
>
> Sorry, but in the meantime I came across two problems with the supposedly
> ultimate solution I just posted.  I have a correction for one, but not
> for the other.
>
> The following statements trigger the first problem:
>
> let foo1 = text "foo"
> let foo2 = see "ref"
> let foo3 = bold [foo1; foo2]
>
> Error: This expression has type Node.link_node_t but is here used with type
>          Node.nonlink_node_t
>        These two variant types have no intersection
>
> The solution that immediately comes to mind is to make the return types
> for the constructor functions open:  (I can see no disadvantage with
> this solution; please tell me if you find any)

I believe that is the correct solution. Sorry I didn't reach it sooner myself!

> module rec Node:
> sig
>     type nonlink_node_t = [ `Text of string | `Bold of Node.super_node_t
> list ] type link_node_t = [ `See of string | `Mref of string *
> nonlink_node_t list ] type super_node_t = [ nonlink_node_t | link_node_t ]
>
>     val text: string -> [> nonlink_node_t]
>     val bold: [< super_node_t] list -> [> nonlink_node_t]
>     val see: string -> [> link_node_t]
>     val mref: string -> nonlink_node_t list -> [> link_node_t]
> end =
> struct
>     type nonlink_node_t = [ `Text of string | `Bold of Node.super_node_t
> list ] type link_node_t = [ `See of string | `Mref of string *
> nonlink_node_t list ] type super_node_t = [ nonlink_node_t | link_node_t ]
>
>     let text txt = `Text txt
>     let bold seq = `Bold (seq :> super_node_t list)
>     let see ref = `See ref
>     let mref ref seq = `Mref (ref, seq)
> end
>
>
> The second problem, while not a show-stopper, may open a hole for misuse of
> the module, so I would rather get it fixed.  Basically, while the module
> provides constructor functions to build nodes, nothing prevents the user
> from bypassing them and constructing nodes manually.  The obvious solution
> of declaring the types "private" results in an "This fixed type has no row
> variable" error.  Any way around it?

I was going to suggest boxing every node in an ordinary variant type with a 
single private constructor:

  type 'a t = private Node of 'a constraint 'a = [< Node.super_node_t ]

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e