caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: David Teller <David.Teller@univ-orleans.fr>
Cc: OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Labelling trees
Date: Thu, 07 Jun 2007 11:00:46 +1000	[thread overview]
Message-ID: <1181178046.6546.54.camel@rosella.wigram> (raw)
In-Reply-To: <1181158983.9266.12.camel@Blefuscu>

On Wed, 2007-06-06 at 21:43 +0200, David Teller wrote:
> Hi everyone,

> That would let me annotate instances of my_expression or my_function
> with informations of type 'a. However, this won't scale in case I decide
> that my static checker will need annotations of different types for
> my_expression and my_function. Of course, my AST is actually a tad more
> complex and would require about 15 type arguments, which I don't
> consider very nice. 

This is indeed a nasty problem I have too. In theory, polymorphic
variants with open recursion support what you want by making a new
parametric term with a new case

	`TYPE_ast of typ * 'ast

and then closing the recursion. This is a covariant extension.

The problem is that whilst this is relatively easy to encode
for 1 parameter, it gets messy with 2 .. and if you have
15 or so as I do as well .. it's just easier to use a dummy
type or magic .. neither of which is satisfactory.

Nor is the above encoding very nice, since it doesn't ensure
each branch of the tree is labelled, instead it simply caches
values where you chose, to speed up the functional calculation.

I just do the boring thing. I make a new type with the term
plus annotations and translate from the untyped to typed terms.

You CAN solve this with a list or array mapping the physical 
term address to the type, with O(N) performance (YUK). 
You can't use a Map or Hashtbl because they require ordering, 
and Ocaml moves objects around so ordering on addresses isn't stable.

Double indirection works though: instead of terms, use an integer
which Maps to a term .. you can then also Map the integer to 
your type. Of course .. this isn't statically safe.

BTW: this is basically 'parallel hierarchies' problem of OO
on a value level.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  parent reply	other threads:[~2007-06-07  1:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 19:43 David Teller
2007-06-06 21:22 ` [Caml-list] " Christophe Raffalli
2007-06-07  1:00 ` skaller [this message]
2007-06-07 14:26   ` Till Varoquaux
2007-06-07 23:09     ` skaller
2007-06-08  9:52       ` Till Varoquaux
2007-06-08 10:32         ` skaller
2007-06-07 14:25 ` Christian Stork
2007-06-07 23:48 ` Jeremy Yallop

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=1181178046.6546.54.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=David.Teller@univ-orleans.fr \
    --cc=caml-list@inria.fr \
    /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).