More questions on downwards binding,
> for @foo -> $a, $b { # two at a time
> ...
> }
Interpretation #1:
for @foo[0..$foo:2] -> $a,
@foo[1..$foo:2] -> $b
{ ... }
Interpretation #2:
for @foo -> $a { $b := $a; ... }
I like this second one, as a short-cut, but it's not worth it. Am I
correct in assuming (as I henceforth shall) that ->(list) is a
distributive binding operation, which spreads all the lhs list elements
into rhs list elements?
==========
Is it legitimate to make the precedence of -> high, and then
just require that distributive binding use parens? (Which resonates
well with existing usages: my ($arg1, $arg2) = @_;)
for @ary1 -> ($nam1, $pw1, $uid1, $gid1, $gcs1, $dir1, $shl1 ),
@ary2 -> ($nam2, $pw2, $uid2, $gid2, $gcs2, $dir2, $shl2)
{
...
}
==========
> : What would the default-variable scheme do in this context?
>
> That's a problem. But a more basic problem is, what would a C<when>
> do?
Given that comma is a list operator, C<when> takes the last one.
for @a1 -> $a1,
@a2 -> $a2
{
when /Larry Wall/i { ++larrymeter; }; # Uses $a2 implicitly.
when $a1 =~ /Perl/ { ... }; # doesn't.
}
==========
> you might not be able to say
> mumble $a -> $b,
> $b -> $a
> { ... }
> to mean
> mumble $a, $b -> $b, $a
> { ... }
mumble ($a, $b) -> ($b, $a) # Makes a list and distributively binds it.
{ ... }
===========
> And I think we have to allow for the case that there are no actuals
> to bind to the formals yet, which means we need an ordinarly looking
> parameter list after the ->. That is, as it currently stands, you
> can say
> my $closure = -> $a, $b { ... }
> as an equivalent to
> my $closure = sub ($a, $b) { ... }
>
> (The only difference being that the latter pays attention to "return"
> exceptions because it has an explicit "sub".)
How would you invoke such a defun?
$closure($a, $b)
for @list $closure
map $closure @list
grep $closure @list
==========
Finally, what does <- do?
=Austin
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> : The obvious extension to given <value> is given <list>, as:
>
> It's not obvious to me that you'd want more than one topic at a time.
> And there's much to be said for defining C<given> as a C<for> that
> provides a scalar context rather than a list context.
>
> : given $foo -> $bar is rw, # I think this is more readable
> : $moo -> $baz is rw
> : {
> : ...
> : }
>
> I suspect that one is not going to happen, because the -> binds a
> list
> tightly to the {...}, being a way of declaring formal parameters.
> Just
> possibly we might figure out a way of distributing -> through a list,
> but that might make for some fairly contorted logic in anything that
> implements anything like C<given> or C<for>. It would have "collect"
> the parameters to a following block from the preceding list. It
> would
> also be more difficult to explain than as mere syntactic sugar for
> a C<sub>.
>
> But yes, it's pretty, and if we can figure out an easy way to do it,
> you might be able to say that. (Or at least, its equivalent as a
> C<for>.)
>
> : or
> :
> : given ($foo, $moo) -> ($bar is rw, $baz)
> : {
> : ...
> : }
>
> Note that in terms of readability, you can always do:
>
> mumble $foo, $moo ->
> $bar is rw, $baz
>
> Admittedly, it's still not as pretty as the first one. But we can't
> have the precedence both ways. Either the arrow governs the comma,
> or
> the comma governs the arrow.
>
> : What would the default-variable scheme do in this context?
>
> That's a problem. But a more basic problem is, what would a C<when>
> do?
>
> : (Please, no-one suggest nesting 5 or 6 of these.)
>
> If you're gonna alias a lot of variables, it's probably better to use
> a normal binding assignment.
>
> But that brings up another problem with your proposed syntax. As
> with
> normal binding assignment,
>
> $a := $b;
> $b := $a;
>
> doesn't serve to swap the values, so too you might not be able to say
>
> mumble $a -> $b,
> $b -> $a
> {
> ...
> }
>
> to mean
>
> mumble $a, $b -> $b, $a {
> ...
> }
>
> Well, we could probably make it work anyway, since the formal
> parameters
> aren't really introduced till the left curly. In this they do not
> function as C<my> does, which introduces names immediately. But
> there's
> sill a precedence snafu.
>
> And I think we have to allow for the case that there are no actuals
> to
> bind to the formals yet, which means we need an ordinarly looking
> parameter list after the ->. That is, as it currently stands, you
> can say
>
> my $closure = -> $a, $b { ... }
>
> as an equivalent to
>
> my $closure = sub ($a, $b) { ... }
>
> (The only difference being that the latter pays attention to "return"
> exceptions because it has an explicit "sub".)
>
> But if we changed the precedence of -> to fit inside list elements,
> it
> wouldn't work.
>
> Larry
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
