On 8/19/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
>David Green writes:
> > Hang on -- should we be saying "for each $foo" or "for $foo.each"
> > anyway? We don't say "for @foo.each"; the iteration is implicit. So
> > I'm thinking it should be "for $foo" or "while next $foo".
>
>Well, C<for $foo> gives you a one-iteration loop.
Oops, I meant $foo to be some iterable object... but yes, that conflicts
with referring to the object itself (such as a plain scalar... although
I guess anything without an explicit iterator method could simply
"iterate" by returning itself once).
But I was confusing myself there anyway. I was thinking that "for"
would somehow have to call the iterator implicitly because if the
iterating method just returned the next value in scalar context and all
values in list context, then "for $object" would pull everything (all
the $object-s flattened) instead of pulling each subsequent $object one
at a time (i.e. lazily).
Then I thought that maybe "for" doesn't need to work lazily (except that
the conveniently just-posted Synopsis 4 confirms that it is supposed to
be lazy). Or maybe "for" is only "as lazy as is reasonable", meaning if
it knows how (e.g. if you're using an array or filehandle, which have
known ways to meander through lazily), or if you write a really fancy
iterator for your object that can handle laziness.
If your iterator (in list context) just returns everything at once, then
"for" will effectively flatten the list because there's nothing else it
can do. (If you need one-at-a-time behaviour, use a while loop!)
Hm... but it still seems it would be good if "for" could know what the
iterator method is for any given object, so that it could call the
(single) iterator one at a time and get through any sequence as lazily
as possible.
>Which implies that iterators can behave as arrays. Then you get to
>weird questions like what:
> $foo[-1]
>Does. Iterate to the end and return that? The array abstraction
>doesn't work well for iterators, so perhaps that's not the best way to
>go.
Yeah... my instinct would be that if you want that much array-like
behaviour, then tie your object to or inherit it from an Array.
>I'm personally a fan of "every" as well as renaming Ruby's "each" to
>something else.
I was also warming up to "sequel", but it's kind of long to type.
OK, using "next" is a problem because of things like:
$foo='LINE'; next $foo;
but what if labels had to be stored in special "label objects" instead
of plain strings? Well, that could still cause problems if you ever
wanted to iterate over some label names, I guess. (Don't ask me why
you'd want to do that...)
Anyway, now that everything's a closure, isn't labelling a block a lot
like naming the block/closure/sub? (Probably not... =P) Hm -- you can
also label a statement on its own... I forgot about that because I don't
think I've ever actually seen Perl code that does that. (You can't
'next' to a statement anyway, only to a labelled block.)
- David "starting to confuse myself again" Green
