in reply to Re: Re: If / elses
in thread If / elses

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";

[download]
        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: If / elses
by jeroenes (Priest) on Mar 13, 2001 at 17:38 UTC
    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]

In Section Seekers of Perl Wisdom