Front page | perl.perl5.porters |
Postings from July 2010
On 12 July 2010 13:07, David Golden <xdaveg@gmail.com> wrote: > On Mon, Jul 12, 2010 at 12:51 AM, Eric Brine <ikegami@adaelis.com> wrote: >> On Sun, Jul 11, 2010 at 10:22 PM, David Golden <xdaveg@gmail.com> wrote: >>> >>> I'm suggesting that we disclaim any implicit guarantee that the >>> compiler won't optimize away expressions that have side effects when >>> evaluated. >> >> Without that guarantee, >> >> my $x = f() >> or DEBUG && warn(...); >> return $x; >> >> would be buggy. Dunno if that matters > > I said "... have side effects when evaluated ..." but your example has > a side effect (functional call) in an assignment before the logic > expression. Maybe "evaluated" isn't the right term, but I was > intending it to mean the action of reading a value from a variable. I think this is close to something i mentioned. My thought was: given that $b=$a++ + $a++; is not defined, that we could also assume that changing fetch magic inside of fetch magic would only take effect after that statement concluded, and thus $b=$a + $a; where $a is tied/overloaded and the magic changes on invocation of the fetch is also undefined. Thus we could check for magic at the beginning of the expression, and then cache it for the duration, although we would guarantee that the magic WAS called twice if there was magic. But the problem with any of these changes is that it could/would break stuff somewhere. Which is why i figured some kind of compiler hint was in order, as it would mean that new code could be optimised relatively sanely and old code would continue on unbroken. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next