3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead?

3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead?

[Aleksey Nogin]

Currently Camlp4 AST defines the record patterns as

   PaRec of loc and list (patt * patt)

and record expressions as

   ExRec of Loc.t and binding and expr

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.

Would it be better to have
   PaRec of loc and list (ident * patt)
and
   ExRec of loc and list (ident * expr) and expr
instead?

If so, it would seem that now is the time to make the change, as 3.10 is 
about to make major backwards-incompatible camlp4 changes anyway.

Aleksey

P.S. I've also filed this as http://caml.inria.fr/mantis/view.php?id=4263

Re: [Caml-list] 3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead?

[Nicolas Pouillard]

On 4/17/07, Aleksey Nogin <nogin@metaprl.org> wrote:
> Currently Camlp4 AST defines the record patterns as
>
>    PaRec of loc and list (patt * patt)
>
> and record expressions as
>
>    ExRec of Loc.t and binding and expr

Why do you mix the old definition of PaRec with the new definition of ExRec.

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


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

For expressions it's more complex, I won't do it.

Regards,

-- 
Nicolas Pouillard

Re: [Caml-list] 3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead?

[Aleksey Nogin]

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

Re: [Caml-list] 3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead?

[Nicolas Pouillard]

On 4/18/07, Aleksey Nogin <nogin@metaprl.org> wrote:
> On 18.04.2007 01:11, Nicolas Pouillard wrote:
>
> > Why do you mix the old definition of PaRec with the new definition of
> > ExRec.

[...]

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

That's now in CVS.

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

Yes it is just used for records and objects {< f1 = e1 ; ... ; fN = eN >}.

But having one more category seems heavy, I have to think more about it.

-- 
Nicolas Pouillard

Re: [Caml-list] 3.10+beta: Camlp4: AST mapping treats record labels as patterns; should they have type ident instead?

[Nicolas Pouillard]

On 4/20/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> On 4/18/07, Aleksey Nogin <nogin@metaprl.org> wrote:
> > On 18.04.2007 01:11, Nicolas Pouillard wrote:
> >

[...]

>
> > > 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.
>
> Yes it is just used for records and objects {< f1 = e1 ; ... ; fN = eN >}.
>
> But having one more category seems heavy, I have to think more about it.
>

Ok, I've done it. I've added the rec_binding type, quotation and use
it for record expressions and objects {< ... >}.

-- 
Nicolas Pouillard