> "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, 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 [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, 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)
> [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
