--- Damian Conway <[EMAIL PROTECTED]> wrote:
> The semantics of C<for> would simply be that if it is given an
> iterator object (rather than a list or array), then it calls
> that object's iterator once per loop.
By extension, if it is NOT given an iterator object, will it appear to
create one?
That is, can I say
for (@squares)
{
...
if $special.instructions eq 'Advance three spaces'
{
$_.next.next.next;
}
...
}
or some other suchlike thing that will enable me to consistently
perform iterator-like things within a loop, regardless of origin?
(Oh please! Let there be one, and for love of humanity, let it be
called "bork". Pleasepleaseplease!!! It's a shorthand form of "bind or
kontinue", really it is. :-) :-) :-))
> but I think that's...err...differently right.
The verb form is "euph" ? Or "euphemise"?
> Otherwise I can't see how one call call an iterator directly in a
> for loop:
>
> for <fibs()> {...}
Which suggests that fibs is a coroutine, since otherwise its return
value is weird. But
while <fibs()> { ... }
suggests instead behavior rather like while (!eof()), although the
diamond is strange.
So in general, diamonded-function-call implies coroutine/continuation?
> But I could certainly live with it not having that, in which case
> the preceding example would have to be:
>
> my $iter = fibs();
> for <$iter> {...}
That's not horrible, but it does even more damage to expression
folding.
> and, if your coroutine itself repeatedly yields a iterator
> then you need:
>
> my $iter = fibses();
> for < <$iter> > {...}
>
> (Careful with those single angles, Eugene!)
To disagree, vile Aussie! To be looking at perl5's adornmentless
diamond:
perlopentut sez:
POT> When you process the ARGV filehandle using <ARGV>,
POT> Perl actually does an implicit open on each file in @ARGV.
POT> Thus a program called like this:
POT> $ myprogram file1 file2 file3
POT> Can have all its files opened and processed one at a time
POT> using a construct no more complex than:
POT> while (<>) {
POT> # do something with $_
POT> }
This *ought* to work the same in p6.
Since you can modify @ARGV in a pure string context, what's the real
behavior?
If I say: while (<>) {print;} I'm asking for file-scan behavior.
If I say: for (@ARGV) { print; } I'm asking for array-scan behavior.
If I say: for (<@ARGV>) { print; } I'm asking for trouble?
Proposal:
@ARGV is a string array, but <> is topicized in :: (or whatever the
default execution context is called) to iterate over @_MAGIC_ARGV,
which is := @ARGV but of a different class whose iterate behavior
performs an open "<$_" in the background, and iterates serially over
each entry in @ARGV once EOF occurs.
my CoolFileType @MY_ARGV := @ARGV; # Same data, different interface.
for (<@MY_ARGV>) {
print;
}
This is kind of neat, but there needs to be a solid, readable
typecasting mechanism to facilitate the multiple flavors of iteration
-- to convert from one iterator format to another, for example.
> > They elegantify stuff.
>
> <tsk> <tsk> If you're going to talk Merkin, talk it propericiously:
>
> "They elegantificatorize stuff"
We Merkuns don't add, we shorten. That's "elify", to wit:
"Z'at elify the code?"
"Elify - no."
Reduction of length, combined with conservation of ambiguity. Win win
win.
=Austin
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
