See p5git://perly.y which contains the following lines (not consecutively):
scalar : '$' indirob ; indirob : WORD | scalar %prec PREC_LOW | block | PRIVATEREF ;
It may be that the only reason that $$; is not parsed as a '$' followed by an indirob (that is a scalar, namely $;) is because the "%prec PREC_LOW" causes another interpretation to be preferred (the shift/reduce conflict is resolved in the other direction).
On the other hand, the tokenizer has a lot of power for this type of stuff. I believe the part of p5git://toke.c that is relevant is scan_ident() (see "S_scan_ident") which will often be called in a case '$': section, for example, in Perl_yylex().
In particular, see after the line starting "/* Is the byte 'd' a legal single character identifier name?". Which eventually, for this case, leads to almost the last line of that function:
else if (PL_lex_state == LEX_INTERPNORMAL && !PL_lex_brackets && ! +intuit_more(s))
Which leads one to read intuit_more() (see "S_intuit_more") which is one of my favorite parts of the tokenizer. Be sure to read the comments above that routine.
But since $$[ doesn't get parsed as ${$[}, I don't believe that intuit_more() is to blame which makes me think that none of the toke.c code is to blame. Which makes me believe that scan_ident() would return ';' if the lexer called it after finding '$$'.
Which leads me back to "%prec PREC_LOW". But (as you saw if you followed along), this code is not simple so I'm not actually confident that this is the right answer. You could try changing perly.y and build a new perl and see.
- tye
In reply to Re: Dereferencing of built-ins with crappy names (precedence override)
by tye
in thread Dereferencing of built-ins with crappy names
by hurricup
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |