> Ariel Scolnicov wrote:
> Consider C<grep {$_ <= 0} (1..) . (map {-$_} (0..))>. Clearly, this
> "should" generate the "list" C<(..0)>. But it doesn't! Here's what
> really happens: Perl says to itself "1 is not nonpositive, 2 is not
> nonpositive, 3 is not nonpositive, ..."; it B<never> reaches the point
> where it starts saying "0 is nonpositive, -1 is nonpositive, ...".
>
You could say the same of:
$someNums = grep __<-1 (1..);
print "You'll never see me!"; # Not true! You'll see why shortly!
You see, this is not a problem with (..1), or infinite lists like {(1..) .
map -__ (..0)}, it's a problem with all semi-finite lists. If the domain
within which the first argument to grep (in this case) can return true is
unknown, we never know when to stop evaluating the list!
But this is OK, because, as I mentioned in my last post, the argument is
evaluated lazily. We only have to worry about the domain when we:
1- Reduce the list
2- Output the list
Actually, outputting the list isn't so bad. We can assume that the
programmer knows what they're doing, and that they'll signal a break in some
way when they're ready.
Reduction is where the challenge is. Damian is already doing an RFC on
reduce(), which I don't want to preempt too much. However, I expect you'll
find that Damian will introduce some nomenclature to define a 'stopping
condition' and perhaps also a predicate domain appropriately... I'll be
interested to see this myself.
However, the point is that there are no challenges introduced by (..1) that
aren't in (1..), and that there are no challenges in (1..) . (..0) that
aren't in (..1). So if Damian's RFCs on lazy evaluation and reduction deal
with semi-finite lists OK, then (..) will be just as doable as (1..).
