Re: statement modifiers
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 replacing "statement_modifier" with : "statement_mod_cond" and "statement_mod_loop" is that every statement : modifier has to be defined as one or the other. Ah, in that sense 'given' is currently considered a loop, and 'when' is considered a conditional, so it's legal to say say "halt" when 42 given $answer; That follows from the recent decision to allow a condition inside a loop to make it easy to write list comprehensions. (The same decision that turned 'for' into a map clone, by the way, and made 'if' return () when false, at least in the absence of an 'else'.) Nice. Thank you. -- Jonathan "Dataweaver" Lang
Re: statement modifiers
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. : : One implication of replacing "statement_modifier" with : "statement_mod_cond" and "statement_mod_loop" is that every statement : modifier has to be defined as one or the other. Ah, in that sense 'given' is currently considered a loop, and 'when' is considered a conditional, so it's legal to say say "halt" when 42 given $answer; That follows from the recent decision to allow a condition inside a loop to make it easy to write list comprehensions. (The same decision that turned 'for' into a map clone, by the way, and made 'if' return () when false, at least in the absence of an 'else'.) Larry
Re: statement modifiers
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 "statement_mod_loop" is that every statement modifier has to be defined as one or the other. -- Jonathan "Dataweaver" Lang
Re: statement modifiers
On Sun, Mar 04, 2007 at 08:55:28PM -0800, Jonathan Lang wrote: : The text of S02, S03, and S04 still contain references to the : now-defunct "statement_modifier" grammatical category. Yes, there are several similar issues that need to be cleared up as soon as http://svn.pugscode.org/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 is there still a valid reason for : forbidding conditional modifiers? In addition to not confusing people with differing Perl 5 semantics, it also discourages people from violating the endweight principle. If the front is heavy enough to need a block, why not go ahead and use a regular if? : 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. Larry
Re: statement modifiers for setting variables
On Mon, Apr 18, 2005 at 06:01:48PM -0700, Dave Whipp wrote:
: The following is legal perl:
:
: print "$a $b $c" if ($a,$b,$c)=(1,2,3);
:
: This prints "1 2 3", but the definitions obviously aren't scoped to the
: modified statement. And a C in the modifier is a bit 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, 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 could use printf to to the factoring, but that's not a
: general solution).
Okay, here's a slightly more general solution:
{ print "$^a $^b $^c" }.(1,2,3);
Larry
Re: Statement modifiers (yes, again)
On Tue, Mar 18, 2003 at 08:53:23PM -0700, Luke Palmer wrote: How is a left-associative operator "less special" than a non-associative one? Ehm, most operators in perl are left-associative, so you probably mean R2L short-circuiting but even then I'm not sure what you're trying to say here And you speak of consistency, but wouldn't it be better to have C be consistent with C and C rather than C and C? (Seeing as C is explicitly a control-flow construct) 'and' is a flow-control construct too.. "foo if bar" and "bar and foo" work identically. Behaviorally 'if' is grouped with 'and'. But I suppose based on the name people will group the 'if' modifier with 'for' rather than with 'and'.. Then they'll assume they can do: FOO for @BAR while $BAZ; dunno.. people try 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!
Re: Statement modifiers (yes, again)
> 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 operators that short-circuit > from right to left. > > This means 'FOO if BAR' is identical to 'BAR and FOO', except it has a > lower precedence, and 'FOO unless BAR' is identical to 'BAR or FOO', > except it has a lower precedence. FOO and BAR are arbitrary expressions. > Because of left-associativity, 'FOO if BAR if BAZ' is identical to > 'BAZ and BAR and FOO'. > > 'FOO when BAR' is similar to 'FOO if BAR' except BAR is matched magically > like the rhs of the ~~ operator and an implicit 'break' occurs if true. > > RATIONALE > 1. it doesn't hurt anything: existing use of the modifiers (now operators) > remains functionally the same. > 2. it allows new useful expressions > 3. it is more consistent: 'if' has no reason being more special than 'and', > 4. it shouldn't make parsing more difficult This seems like it's just begging the question. How is a left-associative operator "less special" than a non-associative one? And you speak of consistency, but wouldn't it be better to have C be consistent with C and C rather than C and C? (Seeing as C is explicitly a control-flow construct) So it's really a consistency thing. If people notice they can do: FOO if $BAR if $BAZ; Then they'll assume they can do: FOO for @BAR while $BAZ; Which they can't. our answer is no if says Larry: so unless .doesnt; Luke
RE: Statement modifiers
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 regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Statement modifiers
[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"); }
Re: Statement modifiers
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/msg09331.html Thanks for the reference However, I'm pretty sure he's talking about disallowing multiple modifiers there. My "if/unless/when as operator" proposal is exactly to avoid having to support multiple modifiers. So I think discussion on this might still be fruitful. I'm actually a bit surprised noone had the idea earlier; to me the if- modifier is so similar to the 'and'-operator to have no reason being a modifier (it's actually implemented using 'and' internally in p5). Contrast that to the 'for'-modifier, which really has an impact on the statement unlike any operator could achieve, and hence really needs to be a statement modifier. -- Matthijs van Duin -- May the Forth be with you!
Re: Statement modifiers
> 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 'BAR and FOO', except it has a
> lower precedence, and 'FOO unless BAR' is identical to 'BAR or FOO',
> except it has a lower precedence. FOO and BAR are arbitrary expressions.
> Because of left-associativity, 'FOO if BAR if BAZ' is identical to
> 'BAZ and BAR and FOO'.
>
> 'FOO when BAR' is similar to 'FOO if BAR' except BAR is matched magically
> like the rhs of the ~~ operator and an implicit 'break' occurs if true.
>
> RATIONALE
> 1. it doesn't hurt anything: existing use of the modifiers (now operators)
> remains functionally the same.
> 2. it allows new useful expressions
> 3. it's more consistent ('if' has no reason being more special than 'and')
> 4. it shouldn't make parsing more difficult
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/msg09331.html
Luke
Re: Statement modifiers
On Mon, Mar 10, 2003 at 11:28:41AM -0800, Paul wrote:
Agreed. But is it worth putting them in if they would make a problem so
easily, and it can be so easily handled with blocks?
I don't think they can make a problem so easily, and I think it's worth
putting them in because afaics it's not very complicated. Just make 'em
short-circuiting infix operators, like 'and' and 'or', except it's the
left side that's conditionally evaluated rather than the right side.
> print if $x if $y; # ??
>
>Are you saying "test $y, and if it's true, test $x, and if it's true
>then print"?
Yes
ok, but wouldn't it be clearer to say
print if $y and $x; # ?
I think so. Alternatively you can write
$y and $x and print;
or if 'if' is an infix operator even:
($x if $y) and print;
Personally I think 'print 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 for multiple statement
modifiers isn't needed to allow:
.method when MyClass given $obj;
because 'when' would just be an operator here, and 'given' the only
modifier. Another reason to make this change is because 'if' and 'unless'
are in fact just 'and' and 'or' with different precedence in behavior.
Short-circuiting operators already exist, so the only new thing would be
R2L short-circuiting instead of L2R, but I doubt that's a problem.
Thus it reserves the title 'statement modifier' for the heavier stuff:
loops (for, while, until) and topicalizers (given).
But that's easier on the brain, becausewe read left-to-right, and it
short-circuits left-to-right. "z() if $x if $y" doesn't.
So don't stack multiple R2L short-circuiting operators if you think
it's confusing; I'm definitely not going to force you to :-)
Seriously, the nice thing is that the behavior of existing use of the
three modifiers remains exactly the same. Sure, you can write a few
new things that are unintelligable, but I think that perl offers rich
opportunities anyway for people who want to write obfuscated code. If
you don't want to obfuscate, then simply don't.
The when/given construction however is a clear example of a useful new
construction that making if/unless/when operators would allow.
But if() currently takes a block unless it's postfix.
I was just extrapolating, though as I said, I'd hate to try and write
the parser.
I don't see the problem.
The 'if' function takes a block. The 'if' infix operator works like
the 'and' operator except it short-circuits the other way around.
There is no conflict here, think about unary '-' versus infix '-'.
To summarize:
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 'BAR and FOO', except it has a
lower precedence, and 'FOO unless BAR' is identical to 'BAR or FOO',
except it has a lower precedence. FOO and BAR are arbitrary expressions.
Because of left-associativity, 'FOO if BAR if BAZ' is identical to
'BAZ and BAR and FOO'.
'FOO when BAR' is similar to 'FOO if BAR' except BAR is matched magically
like the rhs of the ~~ operator and an implicit 'break' occurs if true.
RATIONALE
1. it doesn't hurt anything: existing use of the modifiers (now operators)
remains functionally the same.
2. it allows new useful expressions
3. it's more consistent ('if' has no reason being more special than 'and')
4. it shouldn't make parsing more difficult
--
Matthijs van Duin -- May the Forth be with you!
Re: Statement modifiers
> 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 pointless modifier combinations exist > doesn't mean multiple modifiers in general are a problem. Agreed. But is it worth putting them in if they would make a problem so easily, and it can be so easily handled with blocks? > since 'if' has a lower precedence than '=', this is: > ($x = $y) if $z; > or equivalently > $z and ($x = $y) duh. ok. > > print if $x if $y; # ?? > > > >Are you saying "test $y, and if it's true, test $x, and if it's true > >then print"? > > Yes ok, but wouldn't it be clearer to say print if $y and $x; # ? > It means the left side is not always evaluated; that's > short-circuiting and has nothing to do with precedence. > Notice how in perl 5 the 'or' operator is in the lowest > precedence class, but certainly short-circuits (think "foo or die") But that's easier on the brain, becausewe read left-to-right, and it short-circuits left-to-right. "z() if $x if $y" doesn't. > > print "$x,$y\n" for $x -> @x for $y -> @y; # is that approximate? > > Syntax error. The -> operator doesn't make sense without a block. > See http://www.perl.com/pub/a/2002/10/30/topic.html But if() currently takes a block unless it's postfix. I was just extrapolating, though as I said, I'd hate to try and write the parser. > > print for @x for @y; # @y's topic masked > >would probably make no sense unless ... > > Note that I actually *said* it makes no sense. I have to admit that > if the conditionals (if, unless, when) would be operators, I'd have > trouble to think of a situation where multiple modifiers are useful > at all; which I why I said making the conditionals infix-operators > would probably suffice. I was just agreeing there. :) > Then again, I just thought up (perl 5 style): > >print for split while <>; > > but I have to admit I can probably live without the ability to write > something like that ;-) Dittobut I have *wanted* to do something vaguely like that on *several* occasions! More often it is conditionals, though. I'll leave it to better minds, and use whatever they give me. ;o] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Statement modifiers
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- associative. Your example should obviously be interpreted as: (.method given $x) given $y; # calls $x.method I think this is similar to how I mentioned that a duplicate 'for' is pointless. Just because pointless modifier combinations exist doesn't mean multiple modifiers in general are a problem. lowest? why lowest? Ehm, because that is consistent with current behavior? Careful with that If you make it a lowest precedence operator, $x = $y if $z; # = is higher precedence Does it get assigned if $z is undefined? since 'if' has a lower precedence than '=', this is: ($x = $y) if $z; or equivalently $z and ($x = $y) In either case, the assignment is done if $z is true I may be missing something, but print if $x if $y; # ?? Are you saying "test $y, and if it's true, test $x, and if it's true then print"? Yes I suppose that might workbut that still makes it high priority, doesn't it? It means the left side is not always evaluated; that's short-circuiting and has nothing to do with precedence. Notice how in perl 5 the 'or' operator is in the lowest precedence class, but certainly short- circuits (think "foo or die") print "$x,$y\n" for $x -> @x for $y -> @y; # is that approximate? Syntax error. The -> operator doesn't make sense without a block. See http://www.perl.com/pub/a/2002/10/30/topic.html Still, print for @x for @y; # @y's topic masked would probably make no sense unless ... Note that I actually *said* it makes no sense. I have to admit that if the conditionals (if, unless, when) would be operators, I'd have trouble to think of a situation where multiple modifiers are useful at all; which I why I said making the conditionals infix-operators would probably suffice. Then again, I just thought up (perl 5 style): print for split while <>; but I have to admit I can probably live without the ability to write something like that ;-) -- Matthijs van Duin -- May the Forth be with you!
Re: Statement modifiers
--- 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 such a situation myself:
>
> .method when MyClass given $obj;
> as alternative to:
> $obj.method if $obj.isa(MyClass);
I think this is an unusually clear case, and even then has problems.
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
> except without duplicating $obj, which may be worthwhile if it's a
> longer expression. If multiple modifiers are really a no-no, then
> I think at least the conditionals (if, unless, when) could be made
> lowest-precedence right-associative infix operators, and leave the
> status of "statement modifier" for loops and topicalizers.
lowest? why lowest? Careful with that If you make it a lowest
precedence operator,
$x = $y if $z; # = is higher precedence
Does it get assigned if $z is undefined?
> This would mean that the above would be valid, and also things like:
> .. if .. if .. for ..;
I may be missing something, but
print if $x if $y; # ??
Are you saying "test $y, and if it's true, test $x, and if it's true
then print"? I suppose that might workbut that still makes it high
priority, doesn't it?
> But that multiple nested loops would be illegal using modifiers and
> would require a real block. (which makes some sense, since it's hard
> to think of a construction where multiple loop-modifiers would be
> useful: if you have ... for @a for @b then you'd be unable to
> use the @b-element since $_ would be the loop var of the inner loop)
Maybe not in p6.
print "$x,$y\n" for $x -> @x for $y -> @y; # is that approximate?
Ok, this is hurting my head, and I think I might hurt someone who left
me to maintain it, but I could see how it could be useful, and I think
I see how it could be parsed It would be like
for $y -> @y {
for $x -> @x {
print "$x,$y\n";
}
}
My question is that, though TMTOWTDI is a Good Thing, and in general
dictating style is a Bad Thing, is this much flexibility a Good Thing
or a Bad Thing? And more importantly, will the people writing the
parser become homicidal if it is decided this should be implemented?
Still,
print for @x for @y; # @y's topic masked
would probably make no sense unless it's a rather twisted form of
recursion, and for that I'd recommend writing a function rather than
setting up reference loops
> I also think this gives a nice symmetry of various operators that
> only differ in L2R/R2L and precedence (plus the ability to overload
> ofcourse):
>
> $x and $y $y if $x
> $x or $y$y unless $x
> $x . $y $y <~ $x
> $x ( $y ) $y ~> $x
I have no idea what you mean by this.
Paul
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
