On 10/20/06, Rob Dixon <[EMAIL PROTECTED]> wrote:
Paul Johnson wrote:
>
> On Fri, Oct 20, 2006 at 10:56:09AM +0200, Dr.Ruud wrote:
>
>> Norbert Preining schreef:
>>>
>>> Dr.Ruud:
>>>>
>>>> $ perl -wle '
>>>> $a = 3;
>>>> $b = 0 + (++$a) + ($a++);
>>>> print "b=$b\n";
>>>> '
>>>> b=8
>>>> :)
>>> Nup, this is not the solution:
>> Solution?
>>
>> It showed that there is a bug. I already reported it.
>
> And I already replied ENOTABUG as promised ;-)
It's clear what the language should be doing in this situation and it isn't
doing it, so it's broken. It's only not a bug in the sense that it's documented
to be broken.
Rob
How is it clear what the language should be doing? Repeat after me:
addition is a commutative. The order of addition by definition does
not matter, and any attempt to make it matter should absolutely return
an undefined behavior. Why should Perl guarantee that it will read the
operands of '+' from left to right? As far as I'm concerned, the
Perl/C people have this one right. Given
$x = 3;
$y = ++$x + $x++;
It seems to me that the flow (remembering that addition is
commutative) could be optimized to
$y = $x++; # $y = 3, postincrement, $x=4
$y += ++$x; # preincrement, $x = 5, $y = 9
That makes perfect sense to me. The optimizer sees that it needs an
unincremented $x, inlines the '3', and then gets on witth the
increments. Because, let me say it again, addition is commutative.
If you want to perform addition where the order of execution does
matter, it's up to you to ensure the order.
$y = (0 + ++$x) + $x++; # gets 8
$y = (++$x + 0) + $x++; # gets 8
$y = ++$x + (0 + $x++); # gets 9
$y = ++$x + ($x++ + 0); # gets 9
for instance, seem to yield the expected results. I'd still try to
split the increments into separate statements if possible, though,
because I don't think that behavior is guaranteed. The current
optimizer seems to perform the variable substitution when the parens
are evaluated, but I don't see why that couldn't break at some point;
it's still non-commutative and therefore undefined. Perl is good about
DWIM, but don't expect it to read your mind and figure out which
mathematical properties you'd like to suspend today. If you want to
re-write the rules of logic to suit your fancy, it's up to you to
rewirte the optimizer to suit your fancy, too.
At least that's my $.02.
I'd also recommend against using the reserved variables $a and $b in
examples. That in itself should be a warning that the problem is with
the implementor, not the implementation.
-- jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org
values of β will give rise to dom!
