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


Reply via email to