Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Allison (3003)

Allison
  (email not shown publicly)

Human (I think).

Journal of Allison (3003)

Saturday January 07, 2006
11:19 PM

strings, commas, and operator precedence

[ #28279 ]

On my Parrot days this week I started to add operator support (just + and - to start), but ran into a snag with PGE's operator precedence parser. I expect it's just an undocumented necessary step, so I dropped a note to Patrick and set that aside.

Instead, I made the changes to take advantage of fact that PGE::Text::bracketed now extracts the bracketed value for you. (Thanks Patrick!) And then I started on comma lists. I've got it parsing and transforming to PAST. I'm currently trying to decide what the best way is to handle the transformation to POST. Specifically, I want to transform a Punie statement such as:

print 1, 2;

into the PIR:

print 1
print 2

So internally, I'm splitting a PAST::Op (print) node with a PAST::Op (comma) child into two equal level POST::Op (print) nodes. There are several ways to do it. It's mainly a question of where I want the complexity to bubble up (waterbed theory).

~~~~~~~~~~~~~~~~~~~~

One interesting little tidbit: because PGE is a recursive descent parser, I can't just directly translate certain rules from the original perl.y. The biggest problem is left recursion:

  rule expr   {
      <PunieGrammar::expr> = <PunieGrammar::expr>
      | <PunieGrammar::expr> \+ <PunieGrammar::expr>
      | ...
      | <PunieGrammar::term>
  }

In a recursive descent parser the left recursion is infinite. One solution is to eliminate the left recursion and translate that to something like:

rule expr {
    <PunieGrammar::term> <PunieGrammar::rexpr>
}

rule rexpr {
    = <PunieGrammar::rexpr>
    | \+ <PunieGrammar::rexpr>
    | ...
    | <null>
}

Unfortunately, this produces a match tree that's less-than-ideal for working out operator precedence. That's why PGE has a built-in operator precedence (shift/reduce) parser.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Hi,

    it looks like the PAST evaluation now adds double quotes to the argument of 'print' in generated PIR. I have updated 'Parrot bc', dropping the '"' in the generated PAST. However this is problematic in cases like
    print "0001"
    versus
    print 0001

    Im looking forward to support for '+', '-', '*' and '/' in PAST evaluation. As far as I see, this would allow me to convert all of my existing bc tests to PAST evaluation.

    --
    /* Bernhard.Schmalhofer@gmx.de */