Great answer.
For some reason, I expect that several people will be tempted to transform this into:
print ( $foo == 1 ) ? "hi" : "bye";
and I just wanted to note that doing so will break it, printing either "1" or "" and then returning the value of "hi" to the "void context" unless the print failed. (But if you have warnings enabled, you will get a warning for the above code.)
Two ways to fix this are:
print( ( $foo == 1 ) ? "hi" : "bye" );
print +( $foo == 1 ) ? "hi" : "bye";
-
tye
(but my friends call me "Tye") | [reply] [d/l] [select] |
Hmm. I don't grog why the parens change the precedence. Or
is it that the parens cause a list context, which is gobbled
up by the print?
The parens fix is easy to see. But the '+'? Is it that
the compiler seeks something to add to void? And than
encounters the ternary? Alternatively, if my
list-context-gut-feeling ;-) is correct, it would force
a scalar context to the $foo==1, preventing the print's
greedy behavior. In that cause, the '+' could be replaced
by a '.', isn't it?
Cheers, Jeroen
"We are not alone"(FZ)
| [reply] |
This was a change in how Perl parses things. The new rule
is "if it looks like a function call, treat it as a function
call" and it has to do with what to do when you have a an
identifier followed by an open paren but with whitespace
in between.
So the code:
print ( $foo == 1 ) ? "hi" : "bye";
is now parsed as:
print( $foo == 1 ) ? "hi" : "bye";
or, with an extra set of parens to make it clear:
( print( $foo == 1 ) ) ? "hi" : "bye";
It used to be that the first case was more ambiguous. Sorry,
I don't recall the details. I think part of the original
reason this was looked at was that "print (" was parsed
differently than "print\n(", but I think there were other
"interesting" cases. So this became one of the relatively
few places where Perl chose consistancy over DWIM.
So you can "thwart" this case by putting some non-whitespace
between the identifier ("print") and the open paren. The
cases I showed of this were adding a "(" [and a matching
")"] or adding a "+". A long time ago uniary "-" was
made to work with barewords (not just numbers), primarilly
to support the argument passing syntax that came from
Python tcl when Tk was ported to Perl:
meth( -foo => "bar" );
The "-" is just prepended to the bareword giving use the
result of
meth( "-foo", "bar" );
for that code. Later, unary "+" was made to work with
just about anything as a way to give Perl hints about how
to parse things. In the case of unary "+", it is just
dropped completely (it doesn't even impose a scalar context
on its operand).
Update: Sorry for "blaming" the wrong language there at first.
-
tye
(but my friends call me +Tye)
| [reply] [d/l] [select] |