[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2008-07-13 (21:12) |
From: | Jon Harrop <jon@f...> |
Subject: | Re: [Caml-list] Troublesome nodes |
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