[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

Reply via email to