Re: The NOT construct

On 20-01-2025 16:33, John Lumley wrote:
>
> For example in
>
> functionCall: QName ¬ keyword,-"(", arguments, -")".
> keyword: "if" | "return" | ....
>
> would match i(...) oriff(..) but not if(...).
>
> But using the NOT operator:
>
> functionCall: !keyword, QName,-"(", arguments, -")".
> keyword: "if" | "return" | ....
>
> would succeed fori(...) and fail for if(...), as expected, but would 
> also fail for iff(...) which is not the intent as the leading two 
> characters match keyword and cause the rest of the production to fail.
>

This is indeed a potential pitfall of negative look-ahead.
A better way of doing the above would be:

    functionCall: !(keyword, "("), QName,-"(", arguments, -")".
    keyword: "if" | "return" | ....

which makes sure that the function name is not a complete keyword. I 
have used constructions like this with PEG parsing, and it works. But 
then whitespace might be allowed between a function name and the opening 
parenthesis, and other syntactic constructions, and things get 
complicated quickly.