in reply to BUG when parsing defined-or ?

This is really just a guess, but maybe the logic that disambiguates between defined-or and an empty m// regex (which I remember reading somewhere is fuzzy) is choosing to interpret it as a regex.

$ perl -MO=Deparse -e 'sub foo (&) {}; foo {"foo"} //'
Too many arguments for main::foo at -e line 1, at EOF
-e had compilation errors.
sub foo (&) {
}
&foo(sub {
    'foo';
}
, //);

[download]

Replies are listed 'Best First'.
Re^2: BUG when parsing defined-or? (calls of prototyped subs)
by LanX (Saint) on Jan 25, 2016 at 01:21 UTC
    That was my first idea too ...

    ... but I think something is fundamentally broken with the parsing of prototyped sub calls.

    see how + fails ... 

    lanx@lanx-1005HA:/tmp$ perl -MO=Deparse -e 'sub foo (&) {}; foo {"foo"
+} + 3'
Too many arguments for main::foo at -e line 1, at EOF
-e had compilation errors.
sub foo (&) {
    
}
&foo(sub {
    'foo';
}
, 3);

    [download]
    ... while . works 
    lanx@lanx-1005HA:/tmp$ perl -MO=Deparse -e 'sub foo (&) {}; foo {"foo"
+} . "3"'
sub foo (&) {
    
}
foo(sub {
    'foo';
}
) . '3';
-e syntax OK

    [download]

    Seems like the parser tries to guess if a second parameter follows even if no further parameters are allowed.

    The + fails because it's also a unary operator, so the foo( BLOCK, +3 ) interpretation is preferred, but later rejected, without backtracking into another, binary interpretation.

    I'm no expert of how the lexer works but implementing parsing on such heuristics is a fragile thing.

    Hopefully this can be fixed in the future.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

    update

    that's really a depressing bug, I had much hope in using more block prototypes.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom