I wasn't even trying to guess what it would really parse as so I just Deparse and run it

$ perl -MO=Deparse
print (two + two == five ? "true" : "false")
^Z
print two 'two' == 'five' ? 'true' : 'false';
- syntax OK

$ perl -MO=Deparse,-p
print (two + two == five ? "true" : "false")
^Z
print(two (('two' == 'five') ? 'true' : 'false'));
- syntax OK

$ perl -w
print (two + two == five ? "true" : "false")
print (...) interpreted as function at - line 1.
Unquoted string "two" may clash with future reserved word at - line 1.
Unquoted string "two" may clash with future reserved word at - line 1.
Unquoted string "five" may clash with future reserved word at - line 1
+.
^Z
Name "main::two" used only once: possible typo at - line 1.
Argument "five" isn't numeric in numeric eq (==) at - line 1.
Argument "two" isn't numeric in numeric eq (==) at - line 1.
print() on unopened filehandle two at - line 1.
[download]

I think B::Deparse gets it wrong -- as it sometimes does -- when you add -p:

My theory: When Deparse tries to add parens wherever it can, it treats the first two as a function call (which was my first guess too). But as tobyink correctly surmised, that first two is treated by print as a filehandle.

This is confirmed by the more low-level output of B::Concise:

<Reveal this spoiler or all spoilers in this node or all in this thread>



Dave

Look at the way Deparse uses whitespace, its subtle

<Reveal this spoiler or all in this thread>

I don't think so.

did you recompile the output?

I can't test ATM, but most likely it depends if a function is known at compile time. Contrary to AnoMonk I doubt space matters.

Anyway IMHO the indirect object syntax should be deprecated....

Cheers Rolf

(addicted to the Perl Programming Language)