On Thu, Aug 28, 2008 at 10:07 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote: > >> Opcode names are not reserved words in PIR, and may be used as variable >> names. >> For example, you can define a local variable named C<print>. [See RT >> #24251] >> +Note that by using an opcode name as a local variable name, the variable >> will >> +I<hide> the opcode name, effectively making the opcode unusable. Opcode >> names >> +used as subroutine identifiers, on the other hand, will I<hide> that >> opcode. >> -PIR keywords, on the other hand, I<are> reserved, and cannot be used as >> +In contrast to opcode names, PIR keywords I<are> reserved, and cannot be >> used as >> identifiers. Some opcode names (C<if>, C<unless>) are, in fact, PIR >> keywords, >> which therefore cannot be used as identifiers. >> > > This is another one of those muddy cases in PIR where words conflict when > they shouldn't. I can't think of any way that it's actually useful to have a > variable named 'add' prevent you from using the opcode 'add'. Call it a bug, > or at least a misfeature caused by limited parsing. > > Allison I see what you mean, but being able to do what you would like, would be very complex to implement and IMHO not worth the effort (probably something like setting flags like and lexer code such as: 'if (strcmp(yytext, "add") && expect_math_op) return TK_ADD;'. No fun. Having a rule that says that any local variable declared, hides any other object by the same name in the current scope, is not too hard to understand. In any case, having a local id called 'add' would be a bad practice any way, IMHO. kjs
