In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matt Diephouse) wrote:
>What I mean is that Perl takes an array and makes an iterator out of it.
>Sure, you probably don't think about it like that, but the behavior is
>the same (who says arrays need to iterate starting at element zero?).
I probably didn't, but over the last couple of days I've been thinking
about it like that more and more.
>The odd thing is that here we are designing Perl 6, and we're trying
>to take an iterator and make it into an array so that we can turn it
>back into an iterator again. It seems like we should just use it as an
>iterator::
> for $iterator -> $elem { ... }
Yes!
>Supposing
> class Filehandle does Iterate; # Iterate or Iterator?
>we have an easy way to create new iterators. I'm not sure how useful
>they would be in Perl 6
Maybe the class doesn't do it, but one of its methods does? Then you
can call it whatever makes sense.
class Filehandle
{ method next is iterator {...} }
class Monarch
{ method succeed is iterator {....} }
class Blockbuster
{ method sequel is iterator { $.title++; return $self; } }
>(how do iterators compare to lazy lists?)
Aren't lazy lists a funny kind of iterator? Ones that memoise their
results. And supply an indexing method [].
>Which be even cuter like this (I think):
> for iter($sth.execute) -> $results { ... }
>where iter creates an Iterator object that just knows to call C<.next>
>on its argument.
That still seems too cumbersome to me. Isn't it "for" that knows to
call .next (or .sequel, whatever)? I'm thinking that that is the
point of "for $foo", which should be approximately the same as "while
$foo.next". We've got "while" for looping, ".next" for iterating,
and "for" for doing both in one convenient little shortcut.
So lists and arrays would be iterators, although they may not flaunt it
in public. But you could always explicitly call their .next method if
you wanted to. For example,
for @lines
{
if s/\\$// # ends with a backslash = continued on next line
{
$_ ~= @lines.next;
redo;
}
# now process our joined line ...
}
Of course, that's just the example for "redo" from the Camel, except
using an array instead of <>. A P5 array wouldn't have worked, because
there's no way to get the "next" iteration of an array in the way that
you can use a scalar <> to read the next line of the file. (Though
there ought to be a better way of referring to the object of the "for"
-- I had to refer to it by name here, but I couldn't do that if it were
a list; and $_ is already taken. @_ strikes me as reasonable (for a
not necessarily very large value of "reasonable").)
I'm not sure how much extra syntax is needed. Something that's
expected to iterate (like a filehandle) should just iterate naturally
when used in scalar context, or list context, or both. (But a
filehandle might stringify to the filename in string context, and
return the filehandle object itself when being passed to a function
looking for a filehandle.)
Something that isn't typically expected to iterate (like an array)
could use its .next method, which is a tad wordy, but that's good
because that makes it clear and obvious that we are explicitly
iterating.
Presumably you could slurp up all the iterations at once using * or
** to flatten them. That still doesn't get us the magical <> because
it's really a double iteration (over the filenames in @ARGS and then
over the contents of each file). In fact, that's just a specific case
of wanting to loop through several iterators -- C<for $iter1, $iter2,
$iter3 {...}> only loops through the *list* of iterators, not through
each object itself.
So maybe we do need Larry's new [EMAIL PROTECTED] to get that kind of
double-iteration (without having to nest "for" loops, ugh!). Hm.
Unless the flattening operator will take care of that. C<for
*$iter1, *$iter2, *$iter3 {...}> would do it, but I'm not sure about
C<for [EMAIL PROTECTED] {...}>. (It would definitely do *something*, of that
I'm fairly confident!)
But I'm starting to think I may have just been thinking the original
problem all along, only inside-out....
>Hoping I haven't removed all doubt of my foolishness,
I'm hoping this reply reassures you.
- David "at risk of removing all doubts of mine" Green
