in reply to RecDescent: binary shift in exe block?

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 # }

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?

Replies are listed 'Best First'.
Re: Re: RecDescent: binary shift in exe block?
by bear_hwn (Acolyte) on May 13, 2003 at 02:44 UTC
    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 #
    ....and even more worried about what other surprises await this poor hack in programmer's clothing.

      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.

        ick indeed! my beastie is 3k lines and about 40% comments. (because when i come back i'll not remember why i did what i did.) thanks for the effort. i'll just leave the mults & divs & comments and move on to the other issues awaiting as i try to get a substantially useful tool out of this - that being what i need (the enlightenment was more a 'want' so i don't fall in any tiger traps.) thanks again! hwn