From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 7AC07BB84 for ; Sun, 13 Jul 2008 23:12:05 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskHAAcMekjUnw6EWmdsb2JhbACCOI9sARsCBQcSA5VD X-IronPort-AV: E=Sophos;i="4.30,355,1212357600"; d="scan'208";a="15067037" Received: from pih-relay05.plus.net ([212.159.14.132]) by mail1-smtp-roc.national.inria.fr with ESMTP; 13 Jul 2008 23:12:05 +0200 Received: from [90.192.139.241] (helo=beast.local) by pih-relay05.plus.net with esmtpa (Exim) id 1KI8rT-0002nu-LH for caml-list@yquem.inria.fr; Sun, 13 Jul 2008 22:12:03 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Troublesome nodes Date: Sun, 13 Jul 2008 22:10:55 +0100 User-Agent: KMail/1.9.9 References: <762868.68576.qm@web54603.mail.re2.yahoo.com> In-Reply-To: <762868.68576.qm@web54603.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807132210.55790.jon@ffconsultancy.com> X-Plusnet-Relay: b0b1b3ac29f3736ae3ef299bfa7cb7af X-Spam: no; 0.00; nodes:01 foo:01 foo:01 node:01 node:01 intersection:01 sig:01 val:01 val:01 struct:01 seq:01 seq:01 show-stopper:01 nodes:01 bypassing:01 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