I just said you can *compare* them, I didn't say test whether they're identical. Obviously comparing internal representations is a tricky business, and may have three results: "yes, the lists they generate are equal", "no, the lists they generate are not equal", "I have no clue".
In the last case, per-element comparison will need to be done.
Unless the compiler already knows it's from a generator. Then it only has to compare the existing elements, and if they compare, then the generator itself.
That falls in the first case: the internal representation would consist of the already-generated elements and a genereator for the rest. Comparison of the internal states will yield "yep, they're equal" so no (potentially infinite) per-element comparison is necessary.
> ( 1 .. fn() ) > However, do you evaluate fn() only once or repeatedly?
If a compiler does such an optimization, it needs to make sure fn() is evaluated repeatedly unless it knows for sure fn() will return the same value for each iteration and has no side-effects. I think this means that if fn() does *not* meet those conditions, the compiler can not use a list, because it would risk changing the semantics.
I must've missed something. Why would the compiler consier the value of fn() any if it's business?
What you've missed is that the context was the optimization of:
for ($i = 1; $i < fn(); $i++)
Semantically this code is required to evaluate fn() for each iteration, so the optimizer can't just replace it with for ( 1 .. fn() ) in the general case, however it can do so if and only if it can ascertain that fn() will return the same value for each iteration, and has no side-effects.
Perl needs to be able to handle complicated situations, but how often will you need imaginary numbers? Python handles complex numbers out-of-the-box; I've *never* seen a use for it, other than saying "oh, that's cool." But then, I don't do deep math at my job. I just shovel bits. :)
Complex numbers can be useful, although not for typical applications in perl's target audience.
It seems to me they can however be easily added as a class.
Inf is going to be supported in the core, but we need to keep in mind that it doesn't represent INFINITY in any literal sense [...] and could easily hold a digital image of a tuna
I vote yes on that, if it doesn't add too much to the size of the runtime library :-)
-- Matthijs van Duin -- May the Forth be with you!
