Re: Perl 6's for() signature
John Siracusa [EMAIL PROTECTED] 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 }
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.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Perl 6's for() signature
Luke Palmer [EMAIL PROTECTED] writes:
Yes, it's possible to have two routines with the same name which
differ by signature... however, in Perl 6, Cfor has only one
signature, and it's the one above. The Cfor loop you are thinking
of is spelled Cloop,
Oh, yes, forgot about that.
To the contrary, Cwhile and Cif take only a single expression in
scalar context, whereas Cfor 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.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Fwd: Re: Perl 6's for() signature
Fwd from Luke -- he's adopted a retarded MUA.
--- Luke Palmer [EMAIL PROTECTED] wrote:
Date: Mon, 11 Aug 2003 21:22:05 -0600
From: Luke Palmer [EMAIL PROTECTED]
Subject: Re: Perl 6's for() signature
Austin Hastings writes:
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?
Exactly the same thing as:
for @list - $a, $b {...};
You get a yada-yada-yada exception :-P
Seriously, think of them like this:
my blk = sub ($a, $b) {...};
for @list, blk;
and
for @list, sub ($a, $b) {...};
(IOW, how do we map locals/parameters into block vars?)
That is, block vars Iare parameters.
Or, given
my blk = - $a {...};
loop (my ($x, $max) = (0, -1);
$x $num_elts;
$x++, $max = max($max, $x)),
blk;
What happens?
That's a different story. You get a not enough arguments to call
at runtime.
That's because Cloop doesn't map parameters; instead, it repeatedly
manipulates
lexicals. You'd have to write:
loop (...)
blk.assuming(a = $x);
Or as I said before,
loop (...) { blk($x) }
(IOW, in a target-rich environment, how do we know what to bind?)
Then again, Cfor
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.
Yeah, don't think so. Plus, the block to Cloop can't take any
parameters,
because Cloop doesn't know what to give it.
In summary:
Cfor takes a list and a parameterized block blk, calling blk
repeatedly
with the elements of the list as arguments. Cloop (and Cwhile
and friends)
take a closure with no parameters, and mess with variables in such a
way
that they look like loop variables. They have no idea what to pass
the
block as parameters.
Hope this cleared some things up.
Luke
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
Re: Perl 6's for() signature
Jonadab The Unsightly One wrote:
John Siracusa [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Perl 6's for() signature
Jonadab The Unsightly One wrote:
John Siracusa [EMAIL PROTECTED] 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. Cfor loops are an exception,
sortof, because they're really declaring a parameterized block instead
of a lexical variable.
Luke
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 [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
RE: Perl 6's for() signature
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Austin Hastings writes:
From: Luke Palmer [mailto:[EMAIL PROTECTED]
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. Cfor 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), block;
Cfor is called Cloop, and the is required to avoid using the return
value of calling Cblock. 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, Cfor
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
RE: Perl 6's for() signature
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
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. Cfor 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 Cis scoped(BLOCK) or maybe Cis persistent.
FOR_LOOP:
for (...) {
while (my $line is scoped(FOR_LOOP) = ) {
...
}
print $line; # Okay -- $line ends with the for.
}
=Austin
Re: Perl 6's for() signature
Abhijit A. Mahabal [EMAIL PROTECTED] writes:
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, Cfor has only one
signature, and it's the one above. The Cfor loop you are thinking
of is spelled Cloop, and that's an obvious candidate for Cis
parsed, because it's so funky.
And then most of the proposed methods (including popping off [EMAIL PROTECTED])
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, Cwhile and Cif take only a single expression in
scalar context, whereas Cfor takes a list in flattening list
context. This is the trouble, because you need flattening list
context followed by a different, CCode 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)
[EMAIL PROTECTED] } # -- 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//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Hmm, that last quote seems a little odd when placed next to your
signature... :-)
Luke
Re: Perl 6's for() signature
Abhijit A. Mahabal [EMAIL PROTECTED] writes:
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 [EMAIL PROTECTED])
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)
[EMAIL PROTECTED] } # -- 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//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Perl 6's for() signature
[EMAIL PROTECTED] (Rod Adams) wrote in message
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 [EMAIL PROTECTED]) 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 [EMAIL PROTECTED])
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
Re: Perl 6's for() signature
[EMAIL PROTECTED] (Rod Adams) wrote in message
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 [EMAIL PROTECTED]) 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 [EMAIL PROTECTED])
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
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
Re: Perl 6's for() signature
FWIW, we're aware of the problem. 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
Re: Perl 6's for() signature
[EMAIL PROTECTED] (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... (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
Re: Perl 6's for() signature
On Fri, Aug 01, 2003 at 11:01:15PM +0100, Simon Cozens wrote: : [EMAIL PROTECTED] (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
Re: Perl 6's for() signature
At 10:05 AM 7/31/2003 -0600, Luke Palmer wrote:
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 ([EMAIL PROTECTED], 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?
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
RE: Perl 6's for() signature
At 01:29 PM 7/31/2003 -0400, Hanson, Rob wrote:
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?
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
-Original Message-
From: Rod Adams [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 12:56 PM
To: Perl 6 Language
Subject: Re: Perl 6's for() signature
At 10:05 AM 7/31/2003 -0600, Luke Palmer wrote:
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 ([EMAIL PROTECTED], 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?
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
-Original Message-
From: Rod Adams [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 12:56 PM
To: Perl 6 Language
Subject: Re: Perl 6's for() signature
At 10:05 AM 7/31/2003 -0600, Luke Palmer wrote:
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 ([EMAIL PROTECTED], 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?
Re: Perl 6's for() signature
Anyone but me feel the need for non-greedy slurpy arrays? similar to
non-greedy RE matches?
Then we could do:
sub for ([EMAIL PROTECTED], 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
Re: Perl 6's for() signature
- Original Message - From: Hanson, Rob [EMAIL PROTECTED] To: 'Rod Adams' [EMAIL PROTECTED]; Perl 6 Language [EMAIL PROTECTED] 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;
