I know it is an annoying and bad habit but I'm still young enough so
at first glance I think I know it all.
> [billions and billions of]
> SYN_A # Return one element regardless of context.
> SYN_B # Return number of element wanted by context.
> SYN_C # Return all element regardless of context.
Left out are the Defined? (SYN_D) and Copy (SYN_E)
operations.
For files in p5 we have A and C in scalar or array context of bracketed
file handles. Introduction of "counted busy" context gives us B in
bracketed file handles:
($first, second_holder(), third_holder()) = <$generator>
($first, second_holder(), third_holder(), @AllTheRest) = <$generator>
Which lets us keep unbracketed for D and E.
> The basic underlying question is, what is the context that should fire
> off an iterator? Everyone thinks @foo[1..10] should just do the right
> thing, whatever that is.
okay I'll bite. It's the second through eleventh values of @foo, a
10-element sized busy.
> Assuming the following makes an iterator,
> and doesn't set $iter to 1 the first time through:
>
> $iter = 1..10;
something we might be able to currently do with a source rewrite
to a tied scalar
>
> How many of these work?
>
> while ($x = @foo[$iter]) { ... }
$x becomes a true and defined reference to a continuable expression ,
and a compile-time warning is issued about suspicious use of an
iterator, suggesting angle brackets.
while ($x = @foo[<$iter>]) { ... }
still doesn't DWITYM, or does it? It does, due to the relaxation of
the @arrayname[index] syntax being an accessor rather than a slice,
so it is equivalent of
while (($x) = @foo[<$iter>]) { ... }
would be a lazy while-equivalent of
foreach $x (@foo[1..10]){ ... }
> while ($x = <$iter>) { ... }
unless the code has C<reset $iter> in it somewhere this will advance
the iterator, breezing right past false and only stopping on undef
(semantic shift triggered by appearance of angles)
(although there are no falses in 1..10)
> while ($x = $iter) { ... }
endless loop unless $iter gets set to false or undef
> for ($iter) { ... }
C<for> having some magic in it to iterate iterators seems reasonable
>
> I think that iterators must be dereferenced by something explicit, and
> we will have to be very clear as to what is explicit enough. Subscripts
> may be explicit enough:
>
> @foo[$iter] # okay?
> @foo[<$iter>] # kludgey
>
> Obviously, $iter.method doesn't want to iterate:
>
> $iter.more # can't iterate, or you call $iter.more.more.more...
> <$iter>.more # okay, iterates over some iterators.
>
> Well, that's enough brainwracking for the moment. Gloria is making me
> go eat something...
>
> Larry
fascinating
