Hi Laurent,

the code below seems to do what I want. Even without a dynamic variable. Maybe I should test more thoroughly.


my $nest = 0;
grammar Sum {
  token TOP { ^ <Sum> $ }
  rule Sum { <Expr>+ % <op> }
  rule Expr { <num> | { $nest++ } '[' ~ ']'  <Sum> { $nest-- } }
  token op { <[-+]> }
  token num { \d+ }
  token flag { <?> }
}
class Act {
  method num ($/) { say ">>> $/ at nesting level $nest" }
}

my $input = '2 + 5 + [7 - [3-2] +4] - 8';


Thanks,
Theo

Theo van den Heuvel schreef op 2018-08-01 21:46:
Hi Laurent,

I will do some experimenting, because I could be wrong about the
timing thing. A first experiment seems to work.
I will post my solution when I am satisfied that it works.

thanks,
Theo


Theo van den Heuvel schreef op 2018-08-01 21:21:
Hi Laurent,

dynamic variables were my first attempt (see original post). The
problem as I see it,
but I may well be mistaken, is that I cannot use the grammar rule to
change the variable, e.g,
switching it on before and off after handling the item in question,
Sum in my example, and use that in my action class,
because these actions take place later.

Best,
Theo


Laurent Rosenfeld schreef op 2018-08-01 20:57:
Theo,

if you define a dynamic variable (with the * twigil, for example
$*mode)) in the section of the code right before calling the parse (or
equivalent) method, then your actions class should be able to read it
and to modify it when needed. Then, it is a matter of defining your
action methods to do different things depending on the value of that
dynamic variable, and to change that variable value depending on the
result of the parsing.

Best,
Laurent.

2018-08-01 20:29 GMT+02:00 Theo van den Heuvel
<vdheu...@heuvelhlt.nl>:

Hi Laurent,

yes I have, but the mode switching is supposed to happen
mid-parsing. I hope to avoid having to interrupt the parse, because
picking up after a subparse is going to be hard.
I was looking for a way to communicate a change of mode with the
action class, but:
a) I don't think there is a way to make the grammar parameter
visible to the action class. At least, I can't think of one.
b) the relation between rule X in the grammar and method X in the
action class is hiding within the engine.
c) loosely formulated grammar and action handling don't seem to
share a timeline.

Thanks,

Laurent Rosenfeld schreef op 2018-08-01 19:57:
Hi Theo,

have you considered using only one grammar but simply calling it
with
two different actions classes as a parameter depending on the mode
you
want to use?

2018-08-01 16:41 GMT+02:00 Theo van den Heuvel
<vdheu...@heuvelhlt.nl>:

Hi Perl6-people,

I am looking for some inspiration. I am working with a grammar that
I would like to have operate in two different modes.
In both modes the rules are identical, but the methods should behave
differently. There are probably better ways to do this than I can
think of at this point.

As an illustration (not the actual problem), say we want to proces
arithmetical expressions in two modes: normally we just copy the
input, but within a pair of braces we directly calculate the result.
grammar actions are easy to write per mode, but the combination is
harder.

In our example we would like to convert "{3 + 5} + {2 -1}" into "8 +
1". In my original case the grammar is large.

So far, I have considered the following ideas:
- using a parameter on the grammar rules
- meddling with the AST
- using a dynamic variable (but actions are performed later)
- using the actions method (I don't see how I could use that here)

One way to get this done is by combining the first two ideas:

grammar Sum {
token TOP { ^ <Sum: 0> $ }
rule Sum($p) { <Expr>+ % <op> <flag>**{$p}}
rule Expr { <num> | '[' ~ ']' <Sum: 1> }
token op { <[-+]> }
token num { \d+ }
token flag { <?> }
}

The presence of the flag is the clue for the actions.

This is less than satisfactory because we would have to pass on the
parameter to all non-terminals.

Can anyone think of a better way to do this?

thanks,

--
Theo van den Heuvel

--
Theo van den Heuvel
Van den Heuvel HLT Consultancy

--
Theo van den Heuvel
Van den Heuvel HLT Consultancy

Reply via email to