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

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

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

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

<Reveal this spoiler>



Dave

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)

Look at the way Deparse uses whitespace, its subtle

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.

That is not the way I read it :) Usually, Deparse doesn't add extraneous space to function calls, its always "foo( ... )" its never "foo ( ... )"

so the way I read that deparse output is as filehandle not function call

For example

$ perl -MO=Deparse 2
sub two {
    rand;
}
print two(two() == 'five' ? 'true' : 'false');
2 syntax OK

$ perl -MO=Deparse,-p 2
sub two {
    (rand);
}
print(two(((two() == 'five') ? 'true' : 'false')));
2 syntax OK
[download]

When I look at Re^2: Tiny Perl puzzle I see  print( filehandle ... );