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 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 2E930BC0A for ; Thu, 24 May 2007 16:09:57 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4OE9siU007917 for ; Thu, 24 May 2007 16:09:55 +0200 X-IronPort-AV: E=Sophos;i="4.14,573,1170595800"; d="scan'208";a="133629356" Received: from ppp59-172.lns2.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.59.172]) by ipmail01.adl2.internode.on.net with ESMTP; 24 May 2007 23:39:50 +0930 Subject: Re: [Caml-list] Extracting common information From: skaller To: Niko Matsakis Cc: caml-list@yquem.inria.fr In-Reply-To: References: Content-Type: text/plain Date: Fri, 25 May 2007 00:09:47 +1000 Message-Id: <1180015787.6122.18.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46559CB2.003 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 pointer:01 expr:01 expr:01 annotation:01 annotations:01 compiler:01 pointer:01 rewriting:01 'my:98 sourceforge:01 wrote:01 caml-list:01 binary:01 binary:01 On Thu, 2007-05-24 at 13:04 +0200, Niko Matsakis wrote: > Hello, > > type type_tree = Primitive of string | Pointer of type_tree > > and expr_tree = Unary of string * expr_tree | > > Binary of string * expr_tree * expr_tree > This seemed like it should work reasonably well, but then I realized > I would want to thread along some annotation to store the types, line > numbers, and things like that. Since these annotations will change > between compiler passes, I thought I would use a variant type like so: > > > type 'ud type_tree = Primitive of 'ud * string | > > Pointer of 'ud * 'ud type_tree > > and 'ud expr_tree = Unary of 'ud * string * 'ud expr_tree | > > Binary of 'ud * string * 'ud expr_tree * 'ud > > expr_tree > > etc > > but then I ran into the problem that I sometimes want to be able to > extract the user data without reference to the type of tree involved, > and I can see no easy way to do that beyond: > > > let ud_type type = > > match type with > > Primitive(ud,_) ud | > > Pointer(ud,_) ud > > etc > > Obviously, that is unappealing. That doesn't matter: what you have done is the best way, except the type for source references should be concrete, not a parameter. Although you could factor this by separating the source location from the term .. that's a bad idea because you will be tempted to throw out the source location when analysing the terms .. which prevents you emitting good errors. Putting the source location directly in the terms FORCES you to calculate a reasonable location for every term you synthesise by a rewriting rule (via the type system), which is a good thing. There is another way though .. just add a term like: `Source of src_loc * tree which says 'my child was produced from this source location'. I don't recommend this though, precisely because it can be used wherever you like .. or not used at all. -- John Skaller Felix, successor to C++: http://felix.sf.net