caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dario Teixeira <darioteixeira@yahoo.com>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Troublesome nodes
Date: Sat, 19 Jul 2008 01:43:04 -0700 (PDT)	[thread overview]
Message-ID: <271056.64261.qm@web54605.mail.re2.yahoo.com> (raw)
In-Reply-To: <20080719.112314.52190643.garrigue@math.nagoya-u.ac.jp>

Hi,

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

Perhaps... ;-)  Here is the full code, producing an error in version
"3.11+dev12 Private_abbrevs+natdynlink (2008-02-29)", compiled via GODI:

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 ]
    type (+'a, 'b) t = private 'a constraint 'a = [< super_node_t ]

    val text: string -> ([> nonlink_node_t], [> `Basic]) t
    val bold: ([< super_node_t], 'a) t list -> ([> nonlink_node_t], 'a) t
    val see: string -> ([> link_node_t], [> `Basic]) t
    val mref: string -> (nonlink_node_t, 'a) t list -> ([> link_node_t], [> `Complex]) t

    val make_basic: ('a, [< `Basic]) t list -> ('a, [`Basic]) t list
    val make_complex: ('a, [< `Basic | `Complex]) t list -> ('a, [`Complex]) t list
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 ]
    type (+'a, 'b) t = 'a constraint 'a = [< super_node_t ]

    let text txt = `Text txt
    let bold seq = `Bold (seq :> (super_node_t, 'a) t list)
    let see ref = `See ref
    let mref ref seq = `Mref (ref, seq)

    let make_basic n = n
    let make_complex n = n
end


> 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.

Thanks Jacques, I would really appreciate it.  I'm stuck at this point, so
any help is welcome.  Moreover, this is in fact a neat problem, so any Ocaml
hacker should be able to enjoy it.  Here follows a complete description of
the problem, unprejudiced by the current solution.

I have two types of documents, "basic" and "complex".  Both are composed
of a list of nodes.  The difference between them is that complex documents
may use a superset of the kinds of nodes available for basic documents.
Namely, while basic documents may only use "Text", "Bold", and "See" nodes,
complex documents may also use "Mref" nodes in addition to those three.

In total, there are therefore only four different kinds of nodes.  Two of
those, "Text" and "See" are terminal nodes; the other two, "Bold" and "Mref"
are defined via recursion.  There is one additional restriction: "See" and
"Mref" produce links, and links may not be the immediate ancestors of other
links (note that since "See" is a terminal node and cannot therefore be a
parent, in practice this rule is identical to saying that "Mref" may not
the parent of "See").

Disregarding the basic/complex distinction, nodes could be defined as follows:

type super_node_t =
    | Nonlink_node of nonlink_node_t
    | Link_node of link_node_t
and nonlink_node_t =
    | Text of string
    | Bold of super_node_t list
and link_node_t =
    | Mref of string * nonlink_node_t list
    | See of string


The table below summarises the properties of each node:

Node:	Allowed for:	Definition:	Produces link?
------------------------------------------------------
Text	basic/complex	terminal	no
Bold	basic/complex	rec		no
See	basic/complex	terminal	yes
Mref	complex		rec		yes


There is one final, important, requirement.  I want to be able to
pattern-match on nodes from the outside of the module.  To build a
Node-to-Node function, for example.

To conclude, I'll leave you with some sample documents.  Some are valid,
but others are not.  The compiler should catch the latter.

(* valid *)
let doc1 = make_basic
		[
		text "foo";
		bold [text "bar"];
		see "ref"
		]


(* valid *)
let doc2 = make_complex
		[
		text "foo";
		bold [text "bar"];
		see "ref"
		]


(* valid *)
let doc3 = make_complex
		[
		text "foo";
		mref "ref" [text "bar"]
		]


(* Invalid because a link node is the parent of another *)
let doc4 = make_complex
		[
		mref "ref" [see "foo"]
		]


(* Invalid because basic documents do not allow Mref nodes *)
let doc5 = make_basic
		[
		text "foo";
		mref "ref" [text "bar"]
		]


Best regards,
Dario Teixeira



      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html


      reply	other threads:[~2008-07-19  8:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 20:39 Dario Teixeira
2008-07-11 21:20 ` [Caml-list] " Jeremy Yallop
2008-07-12 12:37   ` Dario Teixeira
2008-07-12 13:25     ` Jacques Carette
2008-07-12 16:44     ` Wolfgang Lux
2008-07-12 18:21       ` Dario Teixeira
2008-07-12 18:27         ` Jeremy Yallop
2008-07-12 18:58       ` Jacques Carette
2008-07-11 23:11 ` Zheng Li
2008-07-13 14:32 ` [Caml-list] " Dario Teixeira
2008-07-13 17:39   ` Dario Teixeira
2008-07-13 21:10     ` Jon Harrop
2008-07-14 15:11       ` Dario Teixeira
2008-07-14 18:52         ` Dario Teixeira
2008-07-14 19:37           ` Jeremy Yallop
2008-07-16 21:22             ` Dario Teixeira
2008-07-17  0:43             ` Jacques Garrigue
2008-07-17 10:59               ` Jeremy Yallop
2008-07-18  2:34                 ` Jacques Garrigue
2008-07-18  9:47                   ` Jeremy Yallop
2008-07-18 13:02                     ` Jacques Garrigue
2008-07-18 13:55                       ` Jacques Garrigue
2008-07-19  2:15                         ` Jacques Garrigue
2008-07-17 16:12               ` Dario Teixeira
2008-07-18  2:27                 ` Jacques Garrigue
2008-07-18 13:09                   ` Dario Teixeira
2008-07-18 17:36                     ` Dario Teixeira
2008-07-19  2:23                       ` Jacques Garrigue
2008-07-19  8:43                         ` Dario Teixeira [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=271056.64261.qm@web54605.mail.re2.yahoo.com \
    --to=darioteixeira@yahoo.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).