2009/12/18 Peter Scott <pe...@psdt.com>:
> On Wed, 16 Dec 2009 10:09:38 +0000, Philip Potter wrote:
>> 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.
I don't disagree with most of what you said. Yes, runtime and compile
time are not as clear as in a language like C. Yes, it's best to know
as soon as possible that a program has a potential problem. But my
issue is that here, no such problem exists, and yet perl is still
complaining about it.
Recall that the example here was a runtime error causing an exception
to be thrown _from within an eval {} block_. If the program were to
execute that code, it would not die, as you claim. It would instead
throw an exception which would be caught by the eval {} block,
recover, and continue. But by moving the runtime error to compile
time, and outside of the systems that you've set up to deal with the
error, perl is saying "I think this code is broken" when in fact it
isn't. perl has changed the behaviour of the problem.
I wouldn't mind if perl just issued a warning. Having a constant
expression 1/0 in code is probably a Bad Thing which the programmer
should be warned of. But since it's still valid code with a
predictable outcome, it should do what it's told, not try to second
guess what you wanted in some sort of DWIMery.
Thankfully, the people who wrote perl 5.10 seem to agree with me.
Phil
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
