bear_hwn has asked for the wisdom of the Perl Monks concerning the following question:

in an attempt to shift & merge returned results, i find i cannot use '>>' or '<<' in the executable block; i must instead divide and multiply, respectively. e.g. in this code, 'goodrule' works, 'badrule' does not: 
sub_rule :   /[0-7]/
badrule : /reg1/i '=' sub_rule ',' /reg2/i '=' sub_rule ';'
   {
      $main::machineword = $item[3] << 3 | $item[7];
      1
   }
goodrule : /reg1/i '=' sub_rule ',' /reg2/i '=' sub_rule ';'
   {
      $main::machineword = $item[3] * 8 | $item[7];
      1
   }

[download]
by 'not working' i mean i get undefined sub-rules and such as if i was getting file/stream type redirection instead of the shifts i want. any ideas about where i've gone wrong? thanks. hwn

Replies are listed 'Best First'.
Re: RecDescent: binary shift in exe block?
by diotalevi (Canon) on May 06, 2003 at 21:03 UTC

    I was thinking HERE docs are more likely. Put the bitshift inside a << section or stick it into a subroutine and have *that* do the bitshift.

    #badrule : /reg1/i '=' sub_rule ',' /reg2/i '=' sub_rule ';'
#   {
#      $main::machineword = eval <<R
\$item[3] << 3 | \$item[7];
R
#      1
#   }

    [download]

    Added: In conslutation on the chatterbox, some other ideas came up that won't step into string-eval which is really quite a hack. I'd use a unary '+' on the right-hand term. So instead of writing $item[3] << 3 it'd be $item << +3. The idea is to distinguish between a string and "other stuff." Another idea is to maybe put a newline between the end of the << and the next term and whatever other whitespace you prefer. Best of luck to you - report back, eh?

[reply]
[d/l]
[select]
      thanks for the suggestions. for the present, i have taken the approach of putting the divides and multiplies in the code -- but i'm not happy as it is no longer immediately clear what is going on, and i have had to fall back on the programmers' bane: comments. :-) i'm tired of seeing: 
      #
# /4194304  -- that's right shift by 22
#

      [download]
      ....and even more worried about what other surprises await this poor hack in programmer's clothing.
[reply]
[d/l]

        It gets worse - in pursuit of your problem I tried looking through P::RD source code and its almost comment-void. I was expecting to find the bits where it parses the grammar but it too much of a pain. 76K of source code and only a dozen lines of comment. Ick.

[reply]
Re: RecDescent: binary shift in exe block?
by bear_hwn (Acolyte) on Jun 17, 2003 at 00:29 UTC
    greetings seekers (& those only pretending to be seekers :-)

    i raised the issue, and now that i have been given an answer, it seemed only right to leave it here as part of this thread, in hopes of helping any who follow.

    first, i must confess that my poorly constructed sample actually works just fine, but the illustrated problem recurred with a better contrived example.

    i visited the p::rd mailing list (mailto:recdescent@perl.org), laid out the problem and, "hey presto!", i was enlightened, thusly:

    SHORT ANSWER:
    always place a blank line after every usage of the '<<' shift operator, but do it INSIDE the action. 
    {
   $main::Instruction_lower = 0x000000
         | (($item[16] & 0x000003) << 10)
         ;# the next blank line is required.

   1;
}

    [download]


    the LONG ANSWER (without permission, but with many thanks) is:
    "the problem is with Text::Balanced::_match_quotelike where it thinks the '<<' is a hereis operator instead of a shift and tries to process it like a quoting operator.
    . . .
    The reason for the bug is that it consumes the entire input and the parser fails in a bizarre way that makes it think everything after the '<<' is part of that hereis literal.
    So to fake it out, give it what it wants, which is a blank line after every usage of the '<<' shift operator, but you have to do it INSIDE the action. The original code had the blank line after the action and the parser parser looses its mind."

    many thanks to all that helped and/or tried.
[reply]
[d/l]

Back to Seekers of Perl Wisdom