--- 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