On Thu, Apr 24, 2008 at 03:31:52PM -0500, John M. Dlugosz wrote: > BTW, it will require a new rule in the specification to allow «=« as a > form of pseudo-assignment to declarations. But it has problems with the > list on the RHS anyway.
I don't see why, since there's no list there...and anyway, he meant »=» anyway, if he wanted ($x, $y) = (127,127). > The initializer needs to go =inside= the > signature. I think you meant to write > > > (my int8 ($x, $y)) «=« 127; It should already parse that way. scope_declarator is a noun, and nouns may be used on the left side of an infix operator. When scope_declarator sees something it doesn't recognize, it just stops, so EXPR picks it up. Now, it could be argued that it *should* be considered part of the 'my', though in the case of 'my' it makes no difference. It could make a difference for, say, 'state', though. >> For decrement of unsigned types---which Str essentially is---we > That makes me think of another way to confuse people who don't really know > the difference between numbers and strings: > > $x = "-100"; > $x++; > say $x; # prints -101, not -99. Interesting point. At one time we had the increments autocoerce to Num if the Str looked like a number. I don't recall why we removed that... but this seems like a good argument for reinstating it. Would also solve the "10" -> 9 problem, for some definition of "solve". Ah yes, if I recall, the argument was what to do with strings that look like "123E42" when the E could be accidental. I can imagine a filename "123.4e2. Or "0xF00D". But this now seems like a weaker argument than decrementing "10" or incrementing "-100". So I think I'll probably reinstate the "looks like a number", at least for integers in decimal notation. We've got to scan the string anyway to look for the final alphanumeric string anyway, so seeing if it's pure digits with optional '-' on the front would not be any more inefficient. Larry
