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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id ACEC7BC0A for ; Wed, 18 Apr 2007 18:13:51 +0200 (CEST) Received: from hub.hrl.com (hub.hrl.com [208.179.241.200]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3IGDoOk029005 for ; Wed, 18 Apr 2007 18:13:51 +0200 Received: from [192.27.172.110] (dangle.hrl.com [192.27.172.110]) by hpux03.hrl.com (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0JGP00BJ4BR1G5@hpux03.hrl.com> for caml-list@inria.fr; Wed, 18 Apr 2007 09:13:50 -0700 (PDT) Date: Wed, 18 Apr 2007 09:13:49 -0700 From: Aleksey Nogin Subject: Re: [Caml-list] 3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead? In-reply-to: To: Nicolas Pouillard , Caml List Reply-To: Caml List , Aleksey Nogin Message-id: <462643BD.8050309@metaprl.org> Organization: MetaPRL/Mojave Research Group MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.10 (X11/20070301) References: <462508EC.2090302@metaprl.org> X-Miltered: at discorde with ID 462643BE.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; camlp:01 expr:01 expr:01 grammars:01 bindings:01 camlp:01 bindings:01 doable:01 node:01 arbitrary:01 wrote:01 rec:01 workaround:01 workaround:01 caml-list:01 On 18.04.2007 01:11, Nicolas Pouillard wrote: > Why do you mix the old definition of PaRec with the new definition of > ExRec. Because I got confused and looked it up in the wrong place, sorry. > I recall them: > > Before: > > | PaRec of loc and list (patt * patt) > > | ExRec of loc and list (patt * expr) and option expr > > Now: > > (* { p } *) > | PaRec of Loc.t and patt > > (* { b } or { (e) with b } *) > | ExRec of Loc.t and binding and expr > > To fully understand here is a fragment of pattern and binding grammars: > > patterns, p ::= ... | { p } | p1 = p2 | p1 ; p2 > > bindings, b ::= ... | p = e | b ; b > >> where the binding can bind arbitrary patterns to expressions. This was >> not a big issue prior to 3.10, but now that 3.10 provides very powerful >> mapping and folding features, this seems a bit problematic. Namely, if I >> define a Camlp4 filter or an AST mapping function that affects patterns, >> the array labels will get affected as well, often in an undesired way. > > It's undesired, but there is an easy workaround: > > .... > method patt p = > match p with > | ... > | <:patt@loc< $p1$ = $p2$ >> -> <:patt@loc< $p1$ = $super#patt p2$ >> > | ... > .... That might helps, thanks! But this will only solve the PaRec problem, not the ExRec one, right? There is no easy way to distinguish the real bindings from the record ones (other than changing the expr method to do something completely separate in the ExRec case). >> Would it be better to have >> PaRec of loc and list (ident * patt) >> and >> ExRec of loc and list (ident * expr) and expr >> instead? > > There is no more lists in the camlp4 AST, that's a price to pay to > have consistency w.r.t quotations. > > For patterns there is something doable: > > | PaEq of Loc.t and patt and patt (* p = p *) > Can become > | PaEq of Loc.t and ident and patt (* i = p *) > > Since that node is only used with an ident on his left. Yes, this sounds like a good thing to do. > For expressions it's more complex > Is it the same issue as the workaround discussion above - the "proper" way to make this distinction would be to introduce a separare rec_binding type similar, but separate from the binding one? But is it true that the "b; b" case in the binding type is only used for records? If so, it would seem that splitting the binding type would not result in that much duplication. Of course, I am only starting to understand the new setup, no I may be completely wrong here. Aleksey