GNU gettext - Bugs: bug #49818, Incomplete list of Perl functions...
You are not allowed to post comments on this tracker with your current authentication level.
bug #49818: Incomplete list of Perl functions without arguments
Submitter: | Bruno Haible <haible> | ||
Submitted: | Fri 09 Dec 2016 07:55:26 PM UTC | ||
Category: | Perl | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | gflohr |
Open/Closed: | Open |
Mon 12 Dec 2016 01:32:01 PM UTC, comment #1: |
Guido Flohr <gflohr>![]() ![]() |
Fri 09 Dec 2016 07:55:26 PM UTC, original submission:
The list of "Perl built-in function that does not accept arguments" in function x_perl_lex (file x-perl.c, around line 2780) has two oddities:
|
Bruno Haible <haible>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
1) Fixed in e4796a6
2) I have to re-check the list.
I had used the command "perldoc perlfunc" as the base for the qualification of keywords, and I think it is more complete than http://perldoc.perl.org/index-functions.html
A handful of the items are operators ("if", "else", "and", ...) and are already handled. But there could be new ones that should be added.
Then there a keywords like "break", which can oddly enough be used like a parameterless function call "break()". Others from the same group, for example "__FILE__" can only be used as such ("__FILE__()" is a syntax error).
At first glance it looks like it makes sense to treat all of the "Non-function keywords" either as operators or functions for our purposes.
I will go through the list one by one. It contains a lot of additions to the Perl language that are not yet handled by x-perl.c.
At the end of the day, the parser actually does not care whether a certain symbol represents a function name, a keyword, an operator or whatever else. We are trying to disambiguate this case here:
foo / bar / gm;
One interpretations is a chained division:
foo() / bar() / gm()
The other one is an invocation of the function foo() with a regex/pattern match as its argument:
foo(/ bar /gm)
That can only be disambiguated at run-time, but knowing the prototypes of the builtin functions helps at least a little.