Aaron Sherman wrote:
> As a special case, perhaps you can treat ranges as special and not as simple
> iterators. To be honest, I wasn't thinking about the possibility of such
> special cases, but about iterators in general. You can't generically reverse
> lazy constructs without running afoul of the halting problem, which I invite
> you to solve at your leisure ;-)
A really obvious example occurs when the RHS is a Whatever:
(1..*).reverse;
.reverse magic isn't going to be generically applicable to all lazy
lists; but it can be applicable to all lazy lists that have predefined
start points, end points, and bidirectional iterators, and on all lazy
lists that have random-access iterators and some way of locating the
tail. Sometimes you can guess what the endpoint and backward-iterator
should be from the start point and the forward-iterator, just as the
infix:<...> operator is able to guess what the forward-iterator should
be from the first one, two, or three items in the list.
This is especially a problem with regard to lists generated using the
series operator, as it's possible to define a custom forward-iterator
for it (but not, AFAICT, a custom reverse-iterator). In comparison,
the simplicity of the range operator's list generation algorithm
almost guarantees that as long as you know for certain what or where
the last item is, you can lazily generate the list from its tail. But
only almost:
(1..3.5); # list context: 1, 2, 3
(1..3.5).reverse; # list context: 3.5, 2.5, 1.5 - assuming list is
generated from tail.
(1..3.5).reverse; # list context: 3, 2, 1 - but only if you
generate it from the head first, and then reverse it.
Again, the proper tool for list generation is the series operator,
because it can do everything that the range operator can do in terms
of list generation, and more.
1 ... 3.5 # same as 1, 2, 3
3.5 ... 1 # same as 3.5, 2.5, 1.5 - and obviously so.
With this in mind, I see no reason to allow any magic on .reverse when
dealing with the range operator (or the series operator, for that
matter): as far as it's concerned, it's dealing with a list that lacks
a reverse-iterator, and so it will _always_ generate the list from its
head to its tail before attempting to reverse it. Maybe at some later
point, after we get Perl 6.0 out the door, we can look into revising
the series operator to permit more powerful iterators so as to allow
.reverse and the like to bring more dwimmy magic to bear.
--
Jonathan "Dataweaver" Lang
