> It may be more useful to discuss this issue using less contrived
> examples. :)
I would agree. I haven't had any use for a double "if" or a double "for".
The double "if" case is handled by "&&". The double "for" case is handled
by "for" and "map".
The interesting cases are combinations of "
On 10/4/06, Juerd <[EMAIL PROTECTED]> wrote:
Damian Conway skribis 2006-10-03 16:40 (-0700):
> >Which can also be written as:
> >do { do { say 1 if 1 } if 1 } if 1;
> Sorry, no it can't. From S4
> (http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
>"Unlike in Perl 5
Damian Conway skribis 2006-10-03 16:40 (-0700):
> >Which can also be written as:
> >do { do { say 1 if 1 } if 1 } if 1;
> Sorry, no it can't. From S4
> (http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
>"Unlike in Perl 5, applying a statement modifier to a do block i
On 10/3/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
Paul Seamons wrote:
>> It relates to some old problems in the early part of the RFC/Apocalypse
>> process, and the fact that:
>>
>> say $_ for 1..10 for 1..10
>>
>> Was ambiguous. The bottom line was that you needed to define your
>> param
The use case here is
do { .foo for @bar } if $baz;
But I guess you can always "protect" it with a parens:
(do { .foo for @bar }) if $baz;
Or just:
if $baz { .foo for @bar }
or even:
@bar».foo if $baz;
;-)
Damian
在 Oct 4, 2006 10:17 AM 時，Damian Conway 寫到：
Audrey asked:
However, I wonder if this is too strict. Disallowing "while" and
"until" after a do block is fine (and can be coded directly in those
two statement modifier macros), but is there a reason to disallow
other modifiers?
Well, for a start
Audrey asked:
> However, I wonder if this is too strict. Disallowing "while" and
> "until" after a do block is fine (and can be coded directly in those
> two statement modifier macros), but is there a reason to disallow
> other modifiers?
Well, for a start, there's this syntactic problem:
do
在 Oct 4, 2006 7:46 AM 時，Damian Conway 寫到：
[Apologies for the last post. Gmail got a little eager.
Here's what I meant to send...]
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/
S04
[Apologies for the last post. Gmail got a little eager.
Here's what I meant to send...]
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
"Unlike in Pe
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
"Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Which if
Aaron Sherman skribis 2006-10-03 13:46 (-0400):
> In Perl 6, that's simplified to:
> {{say 1 if 1}.() if 1}.() if 1;
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Which if crammed together the way you wrote it, turns into:
do {do {say 1 if 1} if 1} if 1;
Or perhap
Paul Seamons wrote:
It relates to some old problems in the early part of the RFC/Apocalypse
process, and the fact that:
say $_ for 1..10 for 1..10
Was ambiguous. The bottom line was that you needed to define your
parameter name for that to work, and defining a parameter name on a
modifi
> It relates to some old problems in the early part of the RFC/Apocalypse
> process, and the fact that:
>
> say $_ for 1..10 for 1..10
>
> Was ambiguous. The bottom line was that you needed to define your
> parameter name for that to work, and defining a parameter name on a
> modifier means t
Paul Seamons wrote:
Of course, that wasn't exactly what you were asking, but it does present
a practical solution when you want to:
{say $_ for =<>}.() if $do_read_input;
Which I just verified works fine under current pugs.
Thank you.
Hadn't thought of that. I think that is workable
> Of course, that wasn't exactly what you were asking, but it does present
> a practical solution when you want to:
>
> {say $_ for =<>}.() if $do_read_input;
>
> Which I just verified works fine under current pugs.
Thank you.
Hadn't thought of that. I think that is workable.
But it also
Trey Harris wrote:
In a message dated Fri, 1 Sep 2006, jerry gay writes:
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
p
> > Yeah, every once in a while, I've wanted the second layer, but I'm
> > willing to rewrite the statement as a true normal if/while instead of a
> > backwards if/while, and it *does* help the overall readability.
>
> I'd concede that the actual useful uses are rare enough to not warrant
> giving
> From my early conversations with Larry, I recall that the reason is that
> RSTS/E BASIC-PLUS had nested trailing modifiers, and both Larry and I saw
> many abuses of these over the years. Therefore, he decided not to repeat
> that abomination, limiting it to precisely one level deep. I'm happy
Paul Seamons schreef:
> In the samples you gave I had to read the entire line to see
> what the outcome of the code is.
I was not addressing reading skills, but just your "you'd either have
... or ...". One always needs to read the full line, but one doesn't
have to do that linearly or just from
> "Paul" == Paul Seamons <[EMAIL PROTECTED]> writes:
Paul> I don't know what the reasoning was back then and it may be the same
today.
>From my early conversations with Larry, I recall that the reason is that
RSTS/E BASIC-PLUS had nested trailing modifiers, and both Larry and I saw many
ab
> $no or $false or $yes and $true and say "OK then" ;
>
> $no or $false or say "OK then" if $yes and $true ;
Thank you for your reply.
I know there are other ways to do it. I've had no choice but to do it other
ways in Perl5.
I don't think I have ever used that notation (outside of file open a
Paul Seamons schreef:
> The following is one more interesting case.
>
> say "Ok then" if $yes and $true unless $no or $false;
>
> Without nested modifiers you'd have either:
>
> say "Ok then" if $yes and $true and ! $no and ! $false;
>
> or
>
> say "OK then" unless ! $yes or ! $true or $no $or $fa
> This was definitively rejected by Larry in 2002:
Yes. That is good to see and I do think I remember seeing that or some similar
postings come to think of it. Thank you for shaking my memory.
Now it is 2006. Object syntax has changed. Little bits and pieces (and
sometimes larger chunks) of
In a message dated Fri, 1 Sep 2006, jerry gay writes:
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
http://www.nntp.perl.or
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
http://www.nntp.perl.org/group/perl.perl6.language/9343
He has not revisited t
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
http://www.nntp.perl.org/group/perl.perl6.language/9343
He has not revisited the issue in the several times it has come up since.
26 matches
Mail list logo
