> For any result of grepping (1..) (with a predicate which always
> terminates, say), you can do this. If C<grep { g($_) } (1..)> is
> nonempty, then it has a first element; we can find this first element
> by running essentially this:
>
> for(my $n=1; ; $n++) {
> last if g($n)
> }
>
> Note that this even works if g(n) is true for infinitely many
> (positive) values of n.
>
And so you can say for (..-1):
for(my $n=-1; ; $n--) {
last if g($n);
}
Of course, perl has to know this is a list with no left operand (rather than
no right operand), so any ordering has to be reversed at the end.
Now, note that _both_ these pieces of code fail to work if:
- grep is called not in a boolean context, but in a list context... how do
we know when we've found the last valid item?
- the test is never true, such as grep __<-1 (1..)
There is nothing fundamentally different about the two cases. If I haven't
convinced you yet, consider that you can _always_ map (where $y>$x):
push @i, $_ if f($_) for ($y..$x);
to:
reverse (push @i, $_ if f($_) for ($x..$y));
and then consider that:
(..-1) == map -__ (1..);
as you've noted yourself previously. Therefore there is a one to one mapping
between implementations of (1..) and (..-1).
So to summarise my last few posts, my argument goes:
- If you can implement (1..) then you can implement (..-1)
- If you can implement (..-1) then you can implement (..)
- Damian says that we can implement (1..) (although there's more RFCs coming
to confirm this). Let's assume he's right
- Therefore we can implement (..)
- Perl should work how you expect
- If (1..) works, you expect (..-1) to work
- If (1..) and (..-1) work, you expect (..) to work
- Therefore RFC 24 should be adjusted to propose semi-finite lists with
either operand to '..' missing, and infinite lists with both operands
missing.
Feel free to email me directly if you want clarification of any of this
argument.
