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!
