--- Matthijs van Duin <[EMAIL PROTECTED]> wrote: > 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. > > ( 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? Unles the sig expressly states it as Inf or some other generative value, then that's a run-time issue. It it returns any integer-equivelent value (for that context) then what's the difference between that and 1..9999999? The compiler should probably just assume the number will be large, take whatever hit is associated with that possibly mistaken assumption, and go about it's business. If the function returns Inf with no warning, what would it do? the same thing. But you *can't* know what it will return in cases where there hasn't been enough info supplied. If 1..fn() is called in a list context, then it's 1..To_Be_Determined. Now, in a *scalar* context it's another story, and would call fn() as often as appropriate..... > > I believe we are indeed trying to define what we want it to do, no? > [snip] > > Do be careful that the result has consistent properties, though. > > Well, in perl's tradition, I think it's more important for Inf to do > what we mean than to be consistent. > IEEE Inf behavior is useful enough, with some constructions (such as > the range operator) behaving specially when it occurs as one of the > operands. Agreed, within the boundaries of the principle of least surprise. I *do* want whatever it does to make some sense, preferably to more people than not -- even if that violates IEEE, though I doubt it will. > > But most of the Laws of Arithmetic as you and I know them do not > > apply to these values. (One could say as much for floating-point > > numbers, I suspect.) > > Yes you can. But since the p in perl stands for practical, I don't > see that as a problem. > If we really want a mathematically pure system, it could probably be > implemented using a module. Again, agreed. Not all programmers are engineers. Some of us are even working with less than the ideal theoretical mathematical background, but are still trudging along trying to make a living shovelling bits. I for one *love* most any kind of theory discussion, but have never actually taken a trigonometry course, much less anything more advanced. 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. :) On the other hand, Perl could implement a module that does complex numbers, and I suspect there are more available that I could shake a search engine at. 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: it represents it in a metaphorical sense, the same way $revenue represents money. It's just an untyped scalar, and could easily hold a digital image of a tuna, but the coder uses it to do a particular thing, and names it accordinly. Inf is intended to stand in for an unreachable distant point in Perl, or an incalculable of some sort. It's the optimizer's job to make sure the program never actually tries to generate the entire set represented by 1..Inf -- which I personally think is *much* better written as (1...)! Ok, I think I'm ranting. Up too late, up too early getting ready for a model that can't make it, found out this morning the time had changed and I was an hour off schedule.... but hey, now I have time to rant here. :) Good morning, people. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
