PPI differs from perl: pi < 1

[happy-barney]

Test expression:

if (pi < 1) { }}

(issue mentioned some time ago on p5p IRC channel)

Implications: another example where Perl uses FUN0 to parse code differently

How PPI parses it:

ppi-dump.pl 'if (pi < 1) { }}'
PPI::Document
  PPI::Statement::Compound
    PPI::Token::Word  	'if'
    PPI::Token::Whitespace  	' '
    PPI::Structure::Condition  	( ... )
      PPI::Statement::Expression
        PPI::Token::Word  	'pi'
        PPI::Token::Whitespace  	' '
        PPI::Token::Operator  	'<'
        PPI::Token::Whitespace  	' '
        PPI::Token::Number  	'1'
    PPI::Token::Whitespace  	' '
    PPI::Structure::Block  	{ ... }
      PPI::Token::Whitespace  	' '
  PPI::Statement::UnmatchedBrace
    PPI::Token::Structure  	'}'

How Perl parses it

Depends on prototype of pi:

• sub pi ();
  • treats < as comparison operator
• sub pi;
  • treats < as opening token of <>

[wchristian]

Past discussion has so far led us to the conclusion that PPI does not have sufficient information to decide what the prototype of a function looks like.

And while perl parsing defaults to assuming it's a <> token, the problem here is that most code written will be functional and have a working prototype for the function call, and have < be the operator.

Thus i do not think the default choice of PPI can be changed, since it lacks the information to decide when the prototype is present to make the code functional.

[happy-barney]

this was created only as reminder of sometimes unexpected behaviour of Perl.

To be able to solve it there should be proper detection of fun0 first. I will try to do it first by postprocessing PPI document (with unknown timeline)

[wchristian]

Alright, i'll file this as a problem for the future, caused by the current inability to handle prototype-triggered parsing undecidabilities.