On Wed, 16 Dec 2009 10:09:38 +0000, Philip Potter wrote: > 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".
This is Perl. The distinction between the compilation and run time phases is almost totally academic. (For instance, use strict throws some exceptions at compile time and others at run time.) Since there's no compiled executable produced, the only difference in behavior is that your program dies sooner than it would have. Of course, conceivably it would not have died at all if the constant folding occurred in conditionally unexecuted code. So think of this as compile-time validation made possible by the use of constants: if your program *were* to execute that code, it would die. Better to know about that in advance than 49 hours into a 50 hour duty cycle. Perl has never made a promise about compilation phase vs runtime phase separation of duties you appear to want. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/ http://www.informit.com/store/product.aspx?isbn=0137001274 -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
