S04 mentions that statement modifiers behave as for perl5 (excpet that
you can have both an conditional modifier and a looping modifier on a
single statement.
Both then it gives this example, with be modifiers being operators
within an expression, not as modifiers of a statement.
line 260
Larry Wall wrote:
Jonathan Lang wrote:
: Larry Wall wrote:
: >: Finally: when used as a statement modifier, is "given" considered to
: >: be conditional or looping? (Gut instinct: conditional.)
: >
: >Why does it have to be one or the other? It's just a topicalizer.
:
: One implication of repla
On Sun, Mar 04, 2007 at 09:44:59PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: >: Finally: when used as a statement modifier, is "given" considered to
: >: be conditional or looping? (Gut instinct: conditional.)
: >
: >Why does it have to be one or the other? It's just a topicalizer.
:
: O
Larry Wall wrote:
: Finally: when used as a statement modifier, is "given" considered to
: be conditional or looping? (Gut instinct: conditional.)
Why does it have to be one or the other? It's just a topicalizer.
One implication of replacing "statement_modifier" with
"statement_mod_cond" and
g/pugs/src/perl6/Perl-6.0.0-STD.pm
settles down.
: Also, what's the reasoning behind specifically disallowing _all_
: statement modifiers to "do" blocks (as opposed to forbidding just
: looping statement modifiers)? Is this legacy from when the
: distinction wasn't being made, or
The text of S02, S03, and S04 still contain references to the
now-defunct "statement_modifier" grammatical category.
Also, what's the reasoning behind specifically disallowing _all_
statement modifiers to "do" blocks (as opposed to forbidding just
looping statement mo
> 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
oo for @bar }) if $baz;
Which also makes the syntactic problem go away. So indeed,
disallowing statement modifiers after do{} altogether seems sane.
Thanks!
Audrey
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
on a
> modifier means that you have to parse the expression without knowing
> what the parameters are, which is ugly in a very non-stylistic sense.
Again, thank you for your reply.
I don't think that is ambiguous though. If you view statement modifiers in
their unwrapped state, that
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
Larry in 2002:
perhaps a sentence to that effect belongs in S04, which has no mention
of nested statement modifiers, for or against.
Well, that's because Synopses at least in theory only refer to changes
from Perl 5. Perl 5 doesn't allow more than one statement modifier, and
Perl 6 doe
n a commit bit and add a test to pugs.
Anyway. Once again if the alleged crime or the predicted crime is too great
then I concede. I can see that it could be abused by some. But that doesn't
mean I will abuse it.
Paul
PS. And not that it matters, but TT3 is planned to support nested statement
modifiers and my engine which does much of TT3 already supports them - and I
do use them on occasion - but that's a different mailing list.
> 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
of the Perl 6 grammar have changed and reverted and
changed again.
I don't know what the reasoning was back then and it may be the same today.
I'm just wondering what that reason is. Maybe nested statement modifiers
promote bad language skills. Maybe its because statement modifiers
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.
perhaps a sentence to that effect belongs in S04, which has no mention
of nested statement modifiers, for or against.
Well, that's because Synopses at least in t
not revisited the issue in the several times it has come up since.
perhaps a sentence to that effect belongs in S04, which has no mention
of nested statement modifiers, for or against.
~jerry
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.
I'm not sure if I have seen this requested or discussed.
Is there a parsing reason why Perl 6 would allow nested statement modifiers or
is it mainly a sanity-please-don't-hurt-my-eyes reason.
It is silly to do things such as:
say "Interesting" if $just_because if $because
On Wed, Aug 30, 2006 at 01:37:33PM +0800, Agent Zhang wrote:
: Hi, there~
:
: I think S04 says too little about statement modifiers. Please comment
: on the following code samples. Are they valid Perl 6?
:
:do { say } for 1..3;
The do-BLOCK construct does not allow statement modifiers
Hi, there~
I think S04 says too little about statement modifiers. Please comment
on the following code samples. Are they valid Perl 6?
do { say } for 1..3;
{ say } for 1..3;
-> $i { say $i } for 1..3;
And how about similar variations for other statement modifiers, such
as wh
too late.
:
: Any reason to [not] add a C statement modifier which restricts
: the scope of the declarations?
Already used "where" for subtype constraints.
: Sure its redundant, but so are all
: statement modifiers. Sometimes its good to factor things out and express
: them later, ra
stricts
the scope of the declarations? Sure its redundant, but so are all
statement modifiers. Sometimes its good to factor things out and express
them later, rather than earlier. It lets us focus on the important
things first:
print "$a $b $c" where ($a,$b,$c)=(1,2,3);
(in this case, we c
ry all sorts of things that can't actually be done, but I
suppose in this case it's a plausible extrapolation.
I guess to be honestly "consistent" all modifiers would have to become
operators, which would bring us back to the multiple statement modifiers
to which Larry said no..
I'll rest my case
--
Matthijs van Duin -- May the Forth be with you!
> To save people from having to re-read the thread, here is the actual
> proposal in detail again:
>
> PROPOSAL
> Replace the 'if', 'unless', 'when' statement modifiers by identically
> named lowest-precedence left-associative oper
I just read Piers' summary:
Matthijs van Duin wondered if the issue of multiple statement modifiers
has been settled. The thread is long, and the answer is essentially (and
authoritatively) "Yes, it's settled. No, you can't do it." So, unless
Larry changes his mind the poi
Simon Cozens:
# [EMAIL PROTECTED] (Luke Palmer) writes:
# > we have a definitive
# ^^
# Remember that this is Perl 6. You keep using that word, etc.
It *is* definitive, Simon...at least this week. ;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regex
[EMAIL PROTECTED] (Luke Palmer) writes:
> we have a definitive
^^
Remember that this is Perl 6. You keep using that word, etc.
--
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }
On Mon, Mar 10, 2003 at 01:14:05PM -0700, Luke Palmer wrote:
It is nice to see someone who puts as much thought into posting as you
do. Unfortunately, your proposal is moot, as we have a definitive
"No, still can't chain them" from Larry.
http://archive.develooper.com/perl6-language%40perl.org/
> PROPOSAL
> Replace the 'if', 'unless', 'when' statement modifiers by identically
> named lowest-precedence left-associative operators that short-circuit
> from right to left.
>
> This means 'FOO if BAR' is identical to
nt if $y and $x' is the clearest indeed, but maybe
otherwise have a different taste.
To be honest, I doubt it'd be useful to stack multiple R2L short-circuiting
operators, but the ability to do so is obviously there. The main reason I
suggested it was because it means that support f
> I made a mistake in my original post, they definitely need to be
> left-associative. Your example should obviously be interpreted as:
>
> (.method given $x) given $y; # calls $x.method
ok.
> I think this is similar to how I mentioned that a duplicate 'for' is
> pointless. Just because poi
On Mon, Mar 10, 2003 at 08:20:39AM -0800, Paul wrote:
The real nightmare tends to show up when you duplicate a modifier.
What does
.method given $x given $y; # which object's .method is called?
mean? It gets worse below
I made a mistake in my original post, they definitely need to be left-
as
--- Matthijs van Duin <[EMAIL PROTECTED]> wrote:
> Now the real subject.. has the issue of multiple statement modifiers
> already been settled? I saw some mention it wasn't going to be
> supported, but also mentions of how it would be useful; I can think
> of
eal subject.. has the issue of multiple statement modifiers
already been settled? I saw some mention it wasn't going to be supported,
but also mentions of how it would be useful; I can think of such a
situation myself:
.method when MyClass given $obj;
as alternative to:
$obj.method if
On Wed, 2002-04-03 at 20:49, Larry Wall wrote:
> : Additionally, can you chain statement modifiers?
> :
> : do_this() if $a unless $b;
[...]
> No, still can't chain them.
That's a darned shame. In p5, I keep going back to code and finding
something like:
print fo
Luke Palmer writes:
: So, does the new =~ commute now, except for regexps; i.e.
:
: $a =~ $b
: is the same as
: $b =~ $a
:
: unless one or both are regexps?
I believe I marked which ones commute in A4.
: Additionally, can you chain statement modifiers?
:
: do_this() if $a unless $b;
: print
So, does the new =~ commute now, except for regexps; i.e.
$a =~ $b
is the same as
$b =~ $a
unless one or both are regexps?
Additionally, can you chain statement modifiers?
do_this() if $a unless $b;
print for @mylist if $debug;
or less efficiently,
print if $debug for @mylist;
print
52 matches
Mail list logo
