Ariel Scolnicov wrote:
> <...infinite lists...>
> This (and your preceeding messages on the subject) is unfortunately
> not possible to do in a clean manner; for that matter, neither is the
> (..0) proposal. The I<order> in which results are produced depends on
> the order in which you generate the elements of (..). Since there's
> no universally "good" order of the integers (do you take
> 0,-1,+1,-2,+2,...; or maybe 0, -1,-2, 1,2,3, -3,-4,-5,-6, 4,5,6,7,8;
> or any other order), there's no way `grep' can generate the results in
> the correct order. But this iterator B<is> an iterator; in
> particular, you I<expect> a well-defined order.
Intuitively, I _do_ expect a well-defined order. Something that just returns
a set is still somewhat useful, but I would like to argue that in fact we
_can_ specify the types of list I'm proposing _and_ have our ordering. Let
me see if I can convince you...
>
> But as soon as you're specifying some well-ordering of the integers,
> you might as well use C<@ints = map {well_order $_} (1..)>, where
> well_order is a bijection of the natural numbers onto the integeers.
> Note that the ordering is different than ...,-2,-1,0,1,2,...
>
Yes, this would be a real pain. But what if we had
@ints = (1..) . map -__ (0..);
Then, we have all the integers... And then perl just needs to know that (..)
and friends need a tuple, and that the second part of the tuple need to be
reversed as soon as we need order. Eventually, infinite lists need criteria
to become finite lists (otherwise we can't do anything useful with them!),
so at this point perl can generate the correct order.
> Similarly, the only useful meaning of C<@negs = (..-1)> would simply
> be C<@negs = map {-$_} (1..)>, and the ordering of the result is again
> "wrong".
>
Yes, but perl knows that we said (..-1), not map -__ (1..), so it does what
we mean as soon as we're ready to use our list in a finite context.
Note that doing this effectively requires that functions on infinite lists
be evaluated lazily. But this is true of (1..) too.
(Thanks to Bruce Davey for helping to develop this proposed solution.)
