Precedence of ? :
h...@crypt.org
HV> Stephen McCamant <sm...@mit.edu> wrote:
SMcC> % perl -e 'print $_ ? 1,2 : 3 for 0, 1'
SMcC> syntax error at -e line 1, near "1,"
SMcC> I can't see any reason for this restriction, and it's an easy
SMcC> change to the grammar to remove.
HV> Super stuff - I've long wondered at the restriction; I'm surprised
HV> it turns out to be such a seemingly simple fix.
I guess I should have asked Larry instead of wondering; it turns out
he has a rather different take on this:
LW> The thing that bothers me about making ?: behave like parens is that
LW> it makes the "then" dwim in a way that you can't make the "else" dwim.
LW> For instance, the following C<and>s are not equivalent:
LW>
LW> $x = $cond ? $a and $b : $c and $d
LW>
LW> The final "and" is a precedence error. Making the middle one work
LW> without making the final one work is inconsistent, but there's no
LW> way to make the final one work without an "end if" delimiter. It's
LW> even worse with
LW>
LW> $x = $cond ? $a = $b : $c = $d
LW>
LW> because we often see the outer assignments in real life with the lower
LW> precedence:
LW>
LW> $x = $cond ? $a : $b
LW> $cond ? $a : $b = $c
LW>
LW> Making ?: guess they actually meant ?(): is not really helping them
LW> to learn the precedence. I think it's more useful to blow up with
LW> a syntax error if they use a low precedence operator inside, because
LW> then they'll learn the actual precedence faster. I think half-baked
LW> dwimmery is worse than no dwimmery.
Hugo
Ton Hospel
operations:
perl -wle '1 ? print 4 : 5'
4
perl -wle 'print 6 ? not 0 : 5'
1
you can quible about these, but = is a sort of binary operator:
perl -wle '1 ? $a=3 : 5; print $a'
3
Larry's argument would imply this should blow up too.
Personaly I prefer consistency and make it all work.
Stephen McCamant
TH> In article <200212200035...@crypt.compulink.co.uk>,
TH> h...@crypt.org writes:
HV> Stephen McCamant <sm...@mit.edu> wrote:
SMcC> % perl -e 'print $_ ? 1,2 : 3 for 0, 1'
SMcC> syntax error at -e line 1, near "1,"
SMcC> I can't see any reason for this restriction, and it's an easy
SMcC> change to the grammar to remove.
>>>>>>> "HV" == Hugo <h...@crypt.org> writes:
HV> Super stuff - I've long wondered at the restriction; I'm surprised
HV> it turns out to be such a seemingly simple fix.
...
HV> I guess I should have asked Larry instead of wondering; it turns
HV> out he has a rather different take on this:
LW> The thing that bothers me about making ?: behave like parens is
LW> that it makes the "then" dwim in a way that you can't make the
LW> "else" dwim. For instance, the following C<and>s are not
LW> equivalent:
LW> $x = $cond ? $a and $b : $c and $d
LW> The final "and" is a precedence error. Making the middle one work
LW> without making the final one work is inconsistent, but there's no
LW> way to make the final one work without an "end if" delimiter.
LW> It's even worse with
LW> $x = $cond ? $a = $b : $c = $d
LW> because we often see the outer assignments in real life with the
LW> lower precedence:
LW> $x = $cond ? $a : $b
LW> $cond ? $a : $b = $c
LW> Making ?: guess they actually meant ?(): is not really helping
LW> them to learn the precedence. I think it's more useful to blow up
LW> with a syntax error if they use a low precedence operator inside,
LW> because then they'll learn the actual precedence faster. I think
LW> half-baked dwimmery is worse than no dwimmery.
TH> However, ?: already DOES work as brackets for lower priority
TH> operations:
TH> perl -wle '1 ? print 4 : 5'
TH> 4
TH> perl -wle 'print 6 ? not 0 : 5'
TH> 1
TH> you can quible about these, but = is a sort of binary operator:
TH> perl -wle '1 ? $a=3 : 5; print $a'
TH> 3
TH> Larry's argument would imply this should blow up too.
TH> Personaly I prefer consistency and make it all work.
Of course, consistency isn't necessarily the highest value in Perl's
design. I was originally motivated by a different sort of consistency,
with C's rules, but I think Larry's point about why ?:'s precedence is
confusing (the syntactic asymmetry between the semantically symmetric
second and third arguments) is well taken.
The case with assignment operators is particularly annoying, I'd say,
and bites C programmers because C won't let you use a ?: as an lvalue,
while Perl will. It's too late to make something like your example
illegal, but I don't think it would be unreasonable to make it give a
warning:
% perl -wle '1 ? $a=3 : 5; print $a'
Suggest parentheses around assignment in argument to ?: at -e line 1.
3
Your other examples with low-precedence prefix operators (listops and
'not') are I think a little less compelling because these operators'
low precedence is rightward, and won't cause the same problem if moved
to the third argument:
% perl -wle 'rand(100) < 50 ? print 1 : print 2'
-- Stephen
h...@crypt.org
:>>>>> "HV" == Hugo <h...@crypt.org> writes:
:
:HV> Stephen McCamant <sm...@mit.edu> wrote:
:SMcC> % perl -e 'print $_ ? 1,2 : 3 for 0, 1'
:SMcC> syntax error at -e line 1, near "1,"
:
:SMcC> I can't see any reason for this restriction, and it's an easy
:SMcC> change to the grammar to remove.
:
:HV> Super stuff - I've long wondered at the restriction; I'm surprised
:HV> it turns out to be such a seemingly simple fix.
:
:I guess I should have asked Larry instead of wondering; it turns out
:he has a rather different take on this:
Patch now taken out again, as change #18336.
Hugo