--- Larry Wall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> : 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?
>
> Neither of these is an accurate view of the current design. The
>
> -> LIST { ... }
>
> construct is declaring a closure with a certain parameter signature.
> The construct interpreting that closure (C<for> in this case) is free
> to pass arguments to those parameters however it sees fit.
What's the query or specification mechanism for users? Or are the
constructs going to have built-in semantics which we can't emulate?
(IOW, is there any way for me to know what the expected shape of
$closure(@_) will be?)
> : ==========
> :
> : 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)
> : {
> : ...
> : }
>
> Yes, we could do it that way.
I'm for it.
> : ==========
> :
> : > : 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.
>
> No, that's Perl 5 thinking. In Perl 6 the comma always produces a
> list
> even in scalar context.
>
> : for @a1 -> $a1,
> : @a2 -> $a2
> : {
> : when /Larry Wall/i { ++larrymeter; }; # Uses $a2 implicitly.
> : when $a1 =~ /Perl/ { ... }; # doesn't.
> : }
>
> It would be more likely to assume a given of any($a1,$a2).
Perl5 is the perl I think now. Sorry.
If the C<when> uses any() as its given context, multiple-binding loops
are going to have to (almost) always specify their comparisons. Not
necessarily a bad thing, even for $_. Although hash iteration won't be
as cool.
for %hash -> ($key, $value) {
when !defined($value) { delete %hash{$key}; }
}
Instead of
for %hash -> ($key, $value) {
when undef { delete %hash{$key}; }
}
(The real "dwim" would have based C<when> on the hash key, instead, so
I'm not too upset here... :-)
Will there be an "unless" version of when, for implied negation?
Perhaps special recognition of 'not' in that context, as:
when not Exception { ... }
when not /a/ { ... }
when not @ary { ... }
> : ==========
> : > 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?
>
> Like any other anonymous subroutine or closure.
>
> : $closure($a, $b)
>
> That would work.
>
> : for @list $closure
> : map $closure @list
> : grep $closure @list
>
> Probably not.
Why not? While my syntax seems doomed to be wrong, your prior
statements gave me the impression that certain constructs (e.g.,
C<for>) may have closure-interpretation behavior that users would be
hard-pressed to emulate.
For example, from above:
> : > for @foo -> $a, $b { # two at a time
> : > ...
> : > }
It would be much easier for me to say
for @foo &$my_closure; # or however this should be written
than
my @bar ^:= @foo; # malleable ary with same refs
while @bar {
my @args;
... figure out behavior of $my_closure, set up @args ...
$my_closure(@args);
}
>
> : Finally, what does <- do?
>
> Numeric comparison of a negated value. Unless we turn := into <-,
> which
> would probably drive the mathematicians nuts.
As I recall, :- and := have both been introduced as inadequate textual
representations of "<-", so there's some justification there.
And frankly, it's too late for the mathematicians - they're already
nuts. ;->
=Austin
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
