Perl 6's for() signature
John Siracusa
http://www.perl.com/pub/a/2003/04/p6pdigest/20030427.html?page=2
> Paul Hodges took a crack at implementing for as a subroutine and came
up with
> something that didn't look too insane. Luke Palmer added a refinement
allowing
> for n at a time looping. However, for reasons that I can't quite put
my finger
> on, I'm not quite sure that either method has got the sub signature
quite
> right, and I'm not entirely sure how you would express for's
signature as a
> Perl 6 signature anyway. Answers on a mailing list please.
Did this ever get resolved to anyone's satisfaction? While reading
EX6, I found myself wonder exactly what for() would look like in Perl 6
code...
-John
Luke Palmer
Well, I don't think it's possible, actually. There's a flattening
list context at the beginning (implying a sugary drink from 7 eleven),
followed by a code block. But, as we know, slurpy arrays can only
come at the end of positional parameters.
But, assuming that is possible, here's C<for> in its entirety:
sub for (*@list, &block) {
while @list {
block( *@list.splice(0, &block.arity) );
}
}
That's not handling NEXT blocks, et al. But I think that's just a
matter of putting &block.NEXT(), &c. in the appropriate places.
Luke
> -John
John Siracusa
> Well, I don't think it's possible, actually. There's a flattening
> list context at the beginning (implying a sugary drink from 7 eleven),
> followed by a code block. But, as we know, slurpy arrays can only
> come at the end of positional parameters.
Right, which is why I couldn't get my head around it. But EX6 says:
"an important goal of Perl 6 is to make the language powerful enough to
natively implement all its own built-ins"
Does "built-ins" just mean "subs" like split(), or does it also include
control structures like if() and for()?
> But, assuming that is possible, here's C<for> in its entirety:
>
> sub for (*@list, &block) {
> while @list {
> block( *@list.splice(0, &block.arity) );
> }
> }
Maybe for() does some magic with "is parsed" and the various Perl 6
grammar rule regexes?
-John
Rod Adams
>Well, I don't think it's possible, actually. There's a flattening
>list context at the beginning (implying a sugary drink from 7 eleven),
>followed by a code block. But, as we know, slurpy arrays can only
>come at the end of positional parameters.
Anyone but me feel the need for non-greedy slurpy arrays? similar to
non-greedy RE matches?
Then we could do:
sub for (*?@data, &block) {...}
Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
are processed Left to Right. Once seen, the mapping starts over right to
left. Everything remaining is slurpable.
Yes, it's more expensive to use, just like the RE version, but shouldn't
impact performance _too_ bad when it's not, since the behavior will be
detectable at compile time.
Thoughts?
Jonathan Worthington
Doing something like that was what came to my mind right away when I read
what Luke put too... It "feels right" to me, though I don't know that
counts for much. :-)
Jonathan
Rod Adams
> > Anyone but me feel the need for non-greedy
> > slurpy arrays? similar to non-greedy RE matches?
>
>wouldn't be used much, but it is nice to have the option.
>
>One thing though, can't you accomplish the same thing by slurping
>everything, then poping the block off of the array?
One could do most of the stuff in P6 parameters with P5's @_. But as Damian
showed at the end of E6, it can quickly grow to a nightmare, and making it
nicer is what P6 is all about.
-- Rod
>Rob
Rob Hanson
> slurpy arrays? similar to non-greedy RE matches?
I definately like the idea of having something like that. It probably
wouldn't be used much, but it is nice to have the option.
One thing though, can't you accomplish the same thing by slurping
everything, then poping the block off of the array?
Rob
Attriel
> non-greedy RE matches?
> Then we could do:
>
> sub for (*?@data, &block) {...}
>
> Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> are processed Left to Right. Once seen, the mapping starts over right to
> left. Everything remaining is slurpable.
With obvious restrictions on "no other slurpy/semi-slurpy arrays" in the
param list, b/c that would make things go insane, IMHO. Although, I guess
with typing, you could do splits on the typed params between, and assuming
there was no ambiguity ...
Ow, my head hurts now :o
--attriel
Joe Gottman
----- Original Message -----
From: "Hanson, Rob" <rha...@aptegrity.com>
To: "'Rod Adams'" <r...@rodadams.net>; "Perl 6 Language"
<perl6-l...@perl.org>
Sent: Thursday, July 31, 2003 1:29 PM
Subject: RE: Perl 6's for() signature
> > Anyone but me feel the need for non-greedy
> > slurpy arrays? similar to non-greedy RE matches?
>
> I definately like the idea of having something like that. It probably
> wouldn't be used much, but it is nice to have the option.
>
> One thing though, can't you accomplish the same thing by slurping
> everything, then poping the block off of the array?
>
> Rob
Yes, but you lose compile-time type checking on the last parameter. I
would prefer to have
for 1,2,3;
fail at compile-time, not run time;
Abhijit A. Mahabal
> Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> are processed Left to Right. Once seen, the mapping starts over right to
> left. Everything remaining is slurpable.
>
> Yes, it's more expensive to use, just like the RE version, but shouldn't
> impact performance _too_ bad when it's not, since the behavior will be
> detectable at compile time.
>
> Thoughts?
There is another problem beyond efficiency: the P6 list semantics is lazy.
The following is valid P6, AFAIK:
for 1 .. Inf {
print $_;
last when 10;
}
And then most of the proposed methods (including popping off *@_) would
not work.
There is another problem that I see with a user defined my_for. We want to
be able to write
my_for 1 .. 5 { something }
and not have to write:
my_for 1 .. 5 {something };
What is bothering me is the following: If we have a sub with the
signature:
sub very_complicated(Int $x, Code *@slurped)
how would the following get parsed:
very_complicated 7 { print "Hello," } { print " world!"}
# Those were the 3 args I wanted to pass
# and the next one is outside the call
sub next_routine {...}
It seems to me, then, that calls to user defined subs will need to end
with a semi-colon.
Abhi
Abhijit A. Mahabal Home: 520 N. Grant St, Apt #2
Graduate Student, Bloomington IN 47408
Dept of Cog Sci and Computer Science, 812 331 2286
Indiana University Off: LH301I; 812 855 8898
Luke Palmer
>
> > Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> > are processed Left to Right. Once seen, the mapping starts over right to
> > left. Everything remaining is slurpable.
> >
> > Yes, it's more expensive to use, just like the RE version, but shouldn't
> > impact performance _too_ bad when it's not, since the behavior will be
> > detectable at compile time.
> >
> > Thoughts?
>
> There is another problem beyond efficiency: the P6 list semantics is lazy.
>
> The following is valid P6, AFAIK:
>
> for 1 .. Inf {
> print $_;
> last when 10;
> }
>
> And then most of the proposed methods (including popping off *@_) would
> not work.
No, popping at least would work. I can assure you of that.
> There is another problem that I see with a user defined my_for. We want to
> be able to write
>
> my_for 1 .. 5 { something }
>
> and not have to write:
>
> my_for 1 .. 5 {something };
>
> What is bothering me is the following: If we have a sub with the
> signature:
> sub very_complicated(Int $x, Code *@slurped)
>
> how would the following get parsed:
>
> very_complicated 7 { print "Hello," } { print " world!"}
> # Those were the 3 args I wanted to pass
> # and the next one is outside the call
> sub next_routine {...}
>
> It seems to me, then, that calls to user defined subs will need to end
> with a semi-colon.
Semicolon syntax shortcuts are still up in the air. People constantly
get tripped up on whether or not to use a semicolon after whatever
kind of block. So, there's going to be some rule which will allow you
to omit them...
As of A4, "a } on a line by itself gets an implicit semicolon added,
if syntactically valid". But the rules might need to be a bit more
complex. We'll see.
Luke
Damian Conway
I posed this very question to Larry a few months back, when I was writing E6.
We're still mulling over the correct answer. The last thought on the problem
that Larry's shared with me was that there may need to be a special case for
allowing a single &block parameter after the slurpy (which would then be
popped off the parsed arg list before slurpification).
I don't think either Larry or I thinks that's ideal, so we'll probably keep
working towards a better (more general) solution to the problem.
Damian
Simon Cozens
> The last thought on the problem that Larry's shared with me was that there
> may need to be a special case for allowing a single &block parameter after
> the slurpy
And the Rubyometer creeps up another few notches...
(Gosh, you'd almost think that Matz had already thought through some of these
issues, wouldn't you? ;)
--
Will your long-winded speeches never end?
What ails you that you keep on arguing?
-- Job 16:3
Larry Wall
: dam...@conway.org (Damian Conway) writes:
: > The last thought on the problem that Larry's shared with me was that there
: > may need to be a special case for allowing a single &block parameter after
: > the slurpy
:
: And the Rubyometer creeps up another few notches...
It's long been planned to allow blocks anywhere in the signature,
particularly at the end, because of endweight considerations. It's
been on my Perl 5 wish list since long before I ever heard of Ruby.
In fact, the first thing I thought when I saw how Ruby did it was,
"Gee, why did he restrict it to only be the last thing?" In Ruby
it's a special case syntax. We're making a general capability to put
the block anywhere in the argument list. If that makes Perl more
like Ruby, so be it. But Perl is not terribly worried about where
it fits on the Rubyometer. Ruby will need to worry about where it
fits on the Perlometer.
: (Gosh, you'd almost think that Matz had already thought through some of these
: issues, wouldn't you? ;)
Certainly Matz thought about some of these issues. Whether he would
claim to have thought them "through" is another matter. There are
many throughways, and they don't all lead the same place. It's easy
to tunnel into a false minimum and think you're "through".
Larry
Jonadab The Unsightly One
> There is another problem beyond efficiency: the P6 list semantics is lazy.
>
> The following is valid P6, AFAIK:
>
> for 1 .. Inf {
> print $_;
> last when 10;
> }
Yeah, but that's a foreach loop, despite the fact that "foreach" is
spelled "for" in your example. foreach loops have a different
signature from for loops. (P6 does make it possible to have two
routines with the same name that differ by signature, right? ISTR
seeing something about that in one of the Apocalypses[1].)
> And then most of the proposed methods (including popping off *@_)
> would not work.
foreach loops take their only code block in the braces; you don't have
the code block inside the parens to worry about in that case, like you
would in a for loop. Thus, foreach loops are no harder to implement
than while or if, signature-wise.
> my_for 1 .. 5 { something }
>
> and not have to write:
>
> my_for 1 .. 5 {something };
Ah, that's another matter, but you need that to implement while and if
as well. Methinks that a signature should be able to call for a code
block in braces, and when it's called the signature after that code
block should be optional. (And it needs to be optional whether the
code block is the last thing in the signature or not; else, how would
one implement map and grep and sort?)
A question I haven't fully thought through: should a closing brace
_ever_ need to be followed by a semicolon? Because, if not, then we
could do this...
my $foo = sub { do_stuff() } # <-- Note no semicolon..
my $baz = {
my @bar;
more_stuff(@bar)
yetmorestuff(@bar)
\@bar } # <-- Here also.
Would that have any nasty consequences I haven't thought about?
---
[1] I _think_ that's the right plural.
*apocalupt + s + es => apocalupses, transliterated apocalypses.
But my third declension is a little rusty and I'm not certain
about that first s being added to the root to form the noun stem.
It's a sufficiently unusal word imported to English recently
enough that the plural would be formed like in the original
language, yes? But then why isn't the singular "apocalypsis"?
Fooey, English is weird, let's stick with Perl.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
Jonadab The Unsightly One
> Did this ever get resolved to anyone's satisfaction? While reading
> EX6, I found myself wonder exactly what for() would look like in
> Perl 6 code...
A for loop[1] is basically syntax sugar for a while loop. In general,
where foo, bar, baz, and quux are expressions, the following are equivalent:
for (foo; bar; baz) { quux }
foo; while (bar) { quux; baz }
If Perl6 has enough syntax-sugar ability to let you turn the former
into the latter, then you don't need to worry about for's signature.
[1] Of course I mean a C-style for loop.
Luke Palmer
>
> > There is another problem beyond efficiency: the P6 list semantics is lazy.
> >
> > The following is valid P6, AFAIK:
> >
> > for 1 .. Inf {
> > print $_;
> > last when 10;
> > }
>
> Yeah, but that's a foreach loop, despite the fact that "foreach" is
> spelled "for" in your example. foreach loops have a different
> signature from for loops. (P6 does make it possible to have two
> routines with the same name that differ by signature, right? ISTR
> seeing something about that in one of the Apocalypses[1].)
Yes, it's possible to have two routines with the same name which
differ by signature... however, in Perl 6, C<for> has only one
signature, and it's the one above. The C<for> loop you are thinking
of is spelled C<loop>, and that's an obvious candidate for C<is
parsed>, because it's so funky.
> > And then most of the proposed methods (including popping off *@_)
> > would not work.
>
> foreach loops take their only code block in the braces; you don't have
> the code block inside the parens to worry about in that case, like you
> would in a for loop. Thus, foreach loops are no harder to implement
> than while or if, signature-wise.
To the contrary, C<while> and C<if> take only a single expression in
scalar context, whereas C<for> takes a list in flattening list
context. This is the trouble, because you need flattening list
context followed by a different, C<Code> context. And that's not
allowed by A6 rules.
>
> > my_for 1 .. 5 { something }
> >
> > and not have to write:
> >
> > my_for 1 .. 5 {something };
>
> Ah, that's another matter, but you need that to implement while and if
> as well. Methinks that a signature should be able to call for a code
> block in braces, and when it's called the signature after that code
> block should be optional.
You mean s:2nd/signature/semicolon/ ?
> (And it needs to be optional whether the code block is the last
> thing in the signature or not; else, how would one implement map and
> grep and sort?)
Because commas are always optional around a code block, no matter
where it appears. This may well be generalized to semicolons, but
AFAIK, this is not the plan (yet).
> A question I haven't fully thought through: should a closing brace
> _ever_ need to be followed by a semicolon? Because, if not, then we
> could do this...
>
> my $foo = sub { do_stuff() } # <-- Note no semicolon..
> my $baz = {
> my @bar;
> more_stuff(@bar)
> yetmorestuff(@bar)
> \@bar } # <-- Here also.
>
> Would that have any nasty consequences I haven't thought about?
This has already been discussed at length. The answer is "um". :-)
So far documented, the semicolon is only optional when the closing
brace is the only thing on the line. Don't worry, Larry's got a
handle on this one, and I don't think it needs further discussion.
[snip]
> Fooey, English is weird, let's stick with Perl.
>
> --
> $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
> split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
Hmm, that last quote seems a little odd when placed next to your
signature... :-)
Luke
Benjamin Goldberg
Jonadab The Unsightly One wrote:
>
> John Siracusa <sira...@mindspring.com> writes:
>
> > Did this ever get resolved to anyone's satisfaction? While reading
> > EX6, I found myself wonder exactly what for() would look like in
> > Perl 6 code...
>
> A for loop[1] is basically syntax sugar for a while loop. In general,
> where foo, bar, baz, and quux are expressions, the following are equivalent:
>
> for (foo; bar; baz) { quux }
> foo; while (bar) { quux; baz }
Well, except that in the second, any variables declared in foo will leak
into the scope after the end of the for loop. Also, in the second,
"baz" is inside the same scope as quux, whereas in the normal C-style
for loop, it's not.
Thus, "for (foo; bar; baz) { quux }" is really more like:
{
foo;
start_for_loop:
if( !bar ) { goto end_for_loop }
{ quux }
baz;
goto start_for_loop;
end_for_loop:
};
> If Perl6 has enough syntax-sugar ability to let you turn the former
> into the latter, then you don't need to worry about for's signature.
Well, yes. But the point of this discussion is, precisely what *kind*
of syntactic sugar will be used.
> [1] Of course I mean a C-style for loop.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Luke Palmer
> >
> > John Siracusa <sira...@mindspring.com> writes:
> >
> > > Did this ever get resolved to anyone's satisfaction? While reading
> > > EX6, I found myself wonder exactly what for() would look like in
> > > Perl 6 code...
> >
> > A for loop[1] is basically syntax sugar for a while loop. In general,
> > where foo, bar, baz, and quux are expressions, the following are equivalent:
> >
> > for (foo; bar; baz) { quux }
> > foo; while (bar) { quux; baz }
>
> Well, except that in the second, any variables declared in foo will leak
> into the scope after the end of the for loop.
Actually, in Perl 6, they'll do that anyway. Scope in loops is
strictly defined by the location of the braces WRT the location of
"my". That is:
while (my $x = somefunc()) { ... }
# $x still in scope
And the same for all other loops. C<for> loops are an "exception",
sortof, because they're really declaring a parameterized block instead
of a lexical variable.
Luke
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:fibo...@babylonia.flatirons.org]
> Actually, in Perl 6, they'll do that anyway. Scope in loops is
> strictly defined by the location of the braces WRT the location of
> "my". That is:
>
> while (my $x = somefunc()) { ... }
> # $x still in scope
>
> And the same for all other loops. C<for> loops are an "exception",
> sortof, because they're really declaring a parameterized block instead
> of a lexical variable.
It seems like we could maybe generalize this "exception":
In cases where we say
my &block = -> $a, $b { do_stuff; }
for (my $a = 0, $b = 1; $a < $b; ++$a) block;
We're really just pulling the block vars out so we can tweak them.
Perhaps the right approach is that all lexically scoped vars declared
"within" loop keywords that take blocks are parameters, and persist until
the end of the loop-block.
while (my $line = <>) { # or loop, or for, or do/while, or whatever
...
}
print $line; # error -- line out of scope
The obvious accompaniment is C<is scoped(BLOCK)> or maybe C<is persistent>.
FOR_LOOP:
for (...) {
while (my $line is scoped(FOR_LOOP) = <>) {
...
}
print $line; # Okay -- $line ends with the for.
}
=Austin
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:fibo...@babylonia.flatirons.org]
> Austin Hastings writes:
> > > From: Luke Palmer [mailto:fibo...@babylonia.flatirons.org]
> >
> > > Actually, in Perl 6, they'll do that anyway. Scope in loops is
> > > strictly defined by the location of the braces WRT the location of
> > > "my". That is:
> > >
> > > while (my $x = somefunc()) { ... }
> > > # $x still in scope
> > >
> > > And the same for all other loops. C<for> loops are an "exception",
> > > sortof, because they're really declaring a parameterized block instead
> > > of a lexical variable.
> >
> > It seems like we could maybe generalize this "exception":
> >
> > In cases where we say
> >
> > my &block = -> $a, $b { do_stuff; }
> >
> > for (my $a = 0, $b = 1; $a < $b; ++$a) block;
>
> Uh, can't do that. Plus, you mean to say:
>
> loop (my ($a, $b) = (0, 1); $a < $b; ++$a), █
>
> C<for> is called C<loop>, and the & is required to avoid using the return
> value of calling C<block>. The , is required because it's not a curly
> block, and commas are only optional when it is.
>
> And you can't do that because the loop has no way of knowing that your
> lexicals are referring to &block's parameters.
Which begs the question:
my &blk = -> $a, $b {...};
for (@list) &blk;
What happens?
(IOW, how do we map locals/parameters into block vars?)
Or, given
my &blk = -> $a {...};
loop (my ($x, $max) = (0, -1);
$x < $num_elts;
$x++, $max = max($max, $x)),
&blk;
What happens?
(IOW, in a "target-rich" environment, how do we know what to bind?)
> Then again, C<for>
> could be made to do that using named parameters, but I don't think it
> will (there are some nasty traps with variables in outer scopes). It's
> easy enough to say:
>
> loop (my ($a, $b) = (0, 1); $a < $b; ++$a) { block($a, $b) }
>
Or maybe we have to say
loop (...) -> $a &blk;
But that's nasty.
> Now on to your argument :-)
>
> > We're really just pulling the block vars out so we can tweak them.
>
> Yeah, sortof.
...
> It's a beginner trap, so Larry changed it to follow intuition. It can
> be useful in a couple places, and it never really gets in your way. So,
> poof, no more magic scopes.
Hooray for newbies. And that's a good point.
I'm still curious about the binding rules, though.
=Austin
Jonadab The Unsightly One
> Yes, it's possible to have two routines with the same name which
> differ by signature... however, in Perl 6, C<for> has only one
> signature, and it's the one above. The C<for> loop you are thinking
> of is spelled C<loop>,
Oh, yes, forgot about that.
> To the contrary, C<while> and C<if> take only a single expression in
> scalar context, whereas C<for> takes a list in flattening list
> context.
*light dawns*
That's what I get for trying to start reading in the middle of a
thread, I guess.
> > Methinks that a signature should be able to call for a code block
> > in braces, and when it's called the signature after that code
> > block should be optional.
>
> You mean s:2nd/signature/semicolon/ ?
Yes, that was a thinko. I thought I typed semicolon there.
> This has already been discussed at length. The answer is "um". :-)
I see.
> So far documented, the semicolon is only optional when the closing
> brace is the only thing on the line. Don't worry, Larry's got a
> handle on this one, and I don't think it needs further discussion.
Cool.
> > Fooey, English is weird, let's stick with Perl.
>
> Hmm, that last quote seems a little odd when placed next to your
> signature... :-)
What, my little pathetic attempt at a JAPH? It's only even slightly
hard to follow if you don't understand closures. Nothing like some of
the clever monstrosities I've seen floating around on the net.