Yah, that's what I kind of put together from the rest of this thread. If Perl thinks both ends of the ... or .. range operators are constants, it tries to gen up the list at compile time. A bad idea when the list is potentially gigantic.

No, it's an even better idea to do it at compile time if the list is large. The larger the list, the larger the potential savings by precomputing it once at compile time.

No, it's an even better idea to do it at compile time if the list is large. The larger the list, the larger the potential savings by precomputing it once at compile time.

Yes, it is such a better idea that the following code consumes tons of resources and then dies, perhaps taking out a few other things because you've run out of some global resource:

sub rarelyUsed {
    my @huge;  # Actually, it is usually empty
    if( ... ) {
        @huge= ('a'..'zzzz');
    } elsif( ... ) {
        @huge= ('b'..'zzzzz');
    } elsif( ... ) {
        @huge= ('c'..'zzzzzz');
    }
    ...
}
[download]

Because computing 3 huge lists is so much better than likely computing none of them or just computing one of them. (:

Just like it is so good that using "perl -c" can die horribly and slowly because of a typo, especially since it is supposed to be useful for looking for typos.

Now, I might consider it a good idea if the list were pre-computed the first time it gets evaluated rather than when it gets compiled. But barring such an intelligent optimization, I'd settle for having a reasonable maximum size enforced for this "optimization".

- tye