2009/12/16 Shlomi Fish <shlo...@iglu.org.il>: > On Tuesday 15 Dec 2009 17:14:25 Philip Potter wrote: >> If evaluating a constant expression results in a runtime exception, >> that runtime exception must happen at runtime, and not at compile >> time. In general, it is the duty of an optimizer never to change >> program behaviour, only performance. >> > > But this is a case where the compiler evaluates a constant expression and it > results in an exception. So it cannot store it as a folded constant on the > side for the run-time place. As a result, it throws a compile-time error.
Yes, it can't fold the constant. That's no excuse for changing the behaviour of the program. What it should do is what I wrote in my previous email -- replace it with code that raises a runtime exception when executed -- ie a die "Illegal division by zero". >> Therefore an optimizer which tries to fold a constant expression at >> compile time only to find a divide by zero exception should write code >> which raises a divide by zero exception at runtime. Raising a divide >> by zero exception at compile time is not what the original program >> did, and so it's not what the optimizer should do either. > > Why? Uhm, because it changes the behaviour of the program? I don't see what else I can say. If the optimizer changes program behaviour then you have no guarantee that what you wrote is what will happen. >> If this error had happened at >> runtime, the program would have caught it and functioned entirely >> correctly; but by moving the exception to compile time -- and out of >> the eval block which was supposed to catch any exceptions -- the >> program won't even compile. > > Well, Perl's optimizer is not that smart. It does not inline such functions > because it doesn't know how many places they will get called. So you're spared > in this case. I don't think you understand my point. The point is: even if it could, it shouldn't. Once you allow optimizers to change program behaviour, you have no guarantee that what you write is what will happen. That is why optimizers must *never* change program behaviour. >> If I am supposed to defend against such an overzealous optimizer, how >> would I write code that uses any block eval to catch exceptions? A >> sufficiently advanced optimizer could always use some method like that >> described above to precalculate the results of the eval, triggering an >> exception at compile time instead of runtime. Therefore block eval >> could never be guaranteed to catch runtime exceptions! > > Well, a program can always have user-input (from files, STDIN, @ARGV, etc.) > which no compiler or optimiser can predict. Sometimes this input will trigger > certain exceptions which cannot be folded. Sometimes the optimizer will be unable to break my code? That is no reassurance. Phil -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
