Re: More questions on downwards binding.
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
> do?
Given that comma is a list operator, C 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 is given , 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 as a C 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 or C. 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.
>
> 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.)
>
> : 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
> 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 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
proposal: when-blocks, and binding $_
The when keyword can use a localizer that makes its target obvious but
slightly counter-intuitive.
given $x {
when /a/ { ... }
}
The problem is operations within the when-block that might expect to
use $_, the defaultdefault variable.
given $x {
when /a/ { s/a/A/; }
}
After all, I used a default-match in the when-expr, so why not keep
using it?
Three possible truths:
Possibility Z- when-blocks do nothing (currently).
for @A
{
for @B -> $x
{
when /b/ # m// checks localized $x from @B
{
s/b/bee/;# changes $_ from @A.
print; # prints $_ from @A.
}
}
}
Possibility A- when-blocks "localize" $_ inside.
for @A
{
for @B -> $x
{
when /b/ # m// checks localized $x from @B
{ # Implicit: local $_ = $x;
s/b/bee/;# s/// works on $_ which is now = $x.
print; # prints $_ from @B
}
}
}
Possibility B- when-blocks accept a -> operator, which if used "naked"
binds the current localizer to $_.
for @A
{
for @B -> $x
{
when /b/ -># m// checks localized $x from @B
{ # unadorned -> means "$x -> $_"
s/b/bee/;# s/// affects $x, from @B
print; # prints $x via $_
}
when /ever/# m// checks localized $x from @B
{ # no -> means no binding, $_ is from @A
s/b/bee/;# s/// works on $_, from @A.
print; # prints $_, from @A.
}
}
}
I prefer B, because it allows control over whether or not I want to
'hide' $_ inside the when-block.
=Austin
__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
Re: proposal: when-blocks, and binding $_
On Tue, Feb 26, 2002 at 01:26:41PM -0800, Austin Hastings wrote:
>
> Possibility B- when-blocks accept a -> operator, which if used "naked"
> binds the current localizer to $_.
I think if I had a choice between
given $y -> $x {
when /a/ -> {...}
when /b/ -> {...}
...
}
and
given $y {
when /a/ {...}
when /b/ {...}
...
}
I'd always prefer the second. Re-aliasing the aliased variable for every
when block doesn't quite seem worth the effort.
Allison
Re: proposal: when-blocks, and binding $_
Which, then, would you like:
To implicitly localize $_, losing access to an outer version,
or to have to change between implicit and explicit operations?
for @A {
for @B -> $x {
when /a/ { s/x/y/; }
}
}
What should that do?
=Austin
--- Allison Randal <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2002 at 01:26:41PM -0800, Austin Hastings wrote:
> >
> > Possibility B- when-blocks accept a -> operator, which if used
> "naked"
> > binds the current localizer to $_.
>
> I think if I had a choice between
>
> given $y -> $x {
> when /a/ -> {...}
> when /b/ -> {...}
> ...
> }
>
> and
>
> given $y {
> when /a/ {...}
> when /b/ {...}
> ...
> }
>
> I'd always prefer the second. Re-aliasing the aliased variable for
> every
> when block doesn't quite seem worth the effort.
>
> Allison
__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
RE: proposal: when-blocks, and binding $_
Austin Hastings:
# --- Allison Randal <[EMAIL PROTECTED]> wrote:
# > On Tue, Feb 26, 2002 at 01:26:41PM -0800, Austin Hastings wrote:
# > >
# > > Possibility B- when-blocks accept a -> operator, which if used
# > "naked"
# > > binds the current localizer to $_.
# >
# > I think if I had a choice between
# >
# > given $y -> $x {
# > when /a/ -> {...}
# > when /b/ -> {...}
# > ...
# > }
# >
# > and
# >
# > given $y {
# > when /a/ {...}
# > when /b/ {...}
# > ...
# > }
# >
# > I'd always prefer the second. Re-aliasing the aliased variable for
# > every
# > when block doesn't quite seem worth the effort.
#
# Which, then, would you like:
#
# To implicitly localize $_, losing access to an outer version,
# or to have to change between implicit and explicit operations?
That's easy to fix in one of two ways:
for @A -> $y {
for @B -> $x {
...
}
}
or:
for @A {
my $y := $_;
for @B -> $x {
...
}
}
# for @A {
# for @B -> $x {
# when /a/ { s/x/y/; }
# }
# }
#
# What should that do?
If you're too lazy to type the four characters in "->$y", too bad.
PS. Small nit in the way you reply: please put the text you're replying
to *above* your reply and intersperse your text with the text of the
message as appropriate. I and most other people on the Perl 6 lists use
this style--it helps to provide context and remind people what the
discussion is about. Even if your mailer arranges the text so that your
style is easier (as mine does), it takes only a few keystrokes per
message to reformat it.
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking, regex hacker, embedding coder, and boy genius
#define private public
--Spotted in a C++ program just before a #include
Re: proposal: when-blocks, and binding $_
On Tue, Feb 26, 2002 at 02:20:48PM -0800, Brent Dax wrote:
> Austin Hastings:
> #
> # Which, then, would you like:
> #
> # To implicitly localize $_, losing access to an outer version,
> # or to have to change between implicit and explicit operations?
Well, I like the idea of having C and the C operate on the
same thing. But I don't really want C to either localize or
clobber $_, I want it to leave the information structure alone. That's
why I'd alias $_ at the C or the C, just like I would now.
> # > given $y {
> # > when /a/ {...}
> # > when /b/ {...}
> # > ...
> # > }
>
> That's easy to fix in one of two ways:
>
> for @A -> $y {
> for @B -> $x {
$y =~ s/x/y/;
$x =~ s/x/y/;
> ...
> }
> }
Which gives you no defaults, but the ultimate in clarity and control.
> # for @A {
> # for @B -> $x {
> # when /a/ { s/x/y/; }
s/x/y/;
> # }
> # }
> #
> # What should that do?
Even if we give C aliasing powers, it is still confusing, because
you jump back and forth between the $_ within the C block and the
$_ between C blocks.
Allison
Re: More questions on downwards binding.
[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 in this case) is free
to pass arguments to those parameters however it sees fit.
: ==
:
: 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.
: ==
:
: > : What would the default-variable scheme do in this context?
: >
: > That's a problem. But a more basic problem is, what would a C
: > do?
:
: Given that comma is a list operator, C 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).
: ==
: > 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.
: Finally, what does <- do?
Numeric comparison of a negated value. Unless we turn := into <-, which
would probably drive the mathematicians nuts.
Larry
