On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: > : Can we ditch C<for> in the examples in favor of C<while>, for a while? :)
: >
: > Okay. Have an example:
: >
: > while =$IN -> $line {...}
: >
: > I think that works. I'm back to thinking unary = in scalar context iterates
: > like p5's <>
:
: What would these do?
:
: while =$IN -> $l1,$l2 {...}
: while =$IN -> @x {...}
:
: That first one seems particularly useful. I'm not exactly sure what
: the second one should do, but it seems like it should be similar to
: { my @x = $IN.slurp; ... }
The C<while> statement is not an arbiter of lists. It want a scalar
value that can play the bool role. Assuming that $IN is really $*IN,
they would both fail because you're trying to bind a scalar string
to a signature that doesn't accept a single scalar string. It would
be exactly like
sub foo($I1, $I2) {...}
foo("#!/usr/bin/perl\n"); # missing $I2
sub bar(@x) {...}
bar("#!/usr/bin/perl\n"); # Trying to bind non-string to @x
That being said, if =$iterator returns a list of array references, the
second one would work. I don't see any way to make the first one work.
: Can it be that unary = in n-ary context iterates like p5's <> except
: when n == Inf or n == 0 (which are list and void context I guess) ?
You mean slurps all the values and then throws away all but n of them?
That's how p5's <> currently behaves. Or did you mean scalar <>?
In any event, I don't think C<while> is ever going to provide an n-ary
context to whatever it wants a boolean value from. That's what C<for>
is for.
Larry
