Version française
Home     About     Download     Resources     Contact us    
Browse thread
Camlp4 help
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: blue storm <bluestorm.dylc@g...>
Subject: Re: [Caml-list] Camlp4 help
On 3/21/09, Andre Nathan <andre@sneakymustard.com> wrote:
> I think I understand, although I thought the "x = expr" rule in the sum
> form definition meant that before "plus" any expression would be
> allowed.

What you wanted is   let a = b in (a plus b). The expression is not
before plus, plus is inside the expression. Your rule means that
inside plus, the left member can be an expression (eg. (let a = b in
a) plus b).

> I want to allow any expression inside a "sum" block, which I think I
> could do by defining it as a new rule in "expr", but I'd like "plus"
> expressions to only be allowed inside a "sum" block, which I'm not sure
> how to do.

I see (but there may be a better choice) two solutions :
- create a new structure expression_inside_sum wich is a complete copy
of "expr" with sums added. This is ugly and redundant.
- use a "marker" trick in two pass :
   - in your grammar you "mark" plus nodes by translating them into a
specific AST node (wich cannot be produced by any usual camlp4
construct), for example "a plus b" -> <:expr< $id:"camlp4.plus"$ a b
>>
   - then you use an Ast.map or a Camlp4Filter to explore the
resulting AST, translating the marked nodes (the ones with
"camlp4.plus" as identifiers) into different things depending on
wether you're inside a sum-block or not (or possibly raising an error
outside a sum-block).

If you want an example, I used a similar trick in my "pa_holes"
extension : "\1"-like identifiers are allowed only inside a (\ ... )
block; at first they're allowed everywhere (the "ident" rule is
changed), then they're transformed into a valid camlp4 construction
inside the (\ ... ) blocks ("expr" rule), and finally the AST is
explored and any remaining \n raise an error (Remove_holes filter).

This solution is also ugly, but has little redudancy.