Keywords that can also be identifiers

SyntaxEditor for WPF Forum

Posted 10 years ago by Kevin Fournier
Version: 14.1.0602
Avatar

I have a grammar that is not quite so LL as I would like. My newest stumbling block is that any keyword can also be an identifier. For example, the language has a delete statement, but there is also a built-in Delete method. Plus, I could just use Delete as a variable name:

Delete Table, Key else
    // Handle Error
end
NewArray = Delete(Array, 1, 0, 0)
Delete = "Hello, World!"

Here are the relavant grammar rules:

AssignmentOrMethodStatement
    : VarOrMethod ( PostfixExpression? (
        @Plus
      | @Minus
      | @Colon
      )? @EqualSign Expression )? StatementTerminator
    ;

DeleteStatement
    : @Delete @Cursor? Expression @Comma Expression ThenElse
    ;

VarOrMethod
    : Identifier ( @OpenParenthesis ExpressionList? @CloseParenthesis )?
    ;

Identifier
    : @IdentifierTerminal | @VariabelAt | @VariableDollar | @VariablePercent | @LabelInGoSub
    ;

If I add @Delete to the Identifier alternation, then I'll get an ambiguity issue that I don't see as being easily solved using a CanMatchCallback.

It seems what I need is the ability for parser to always look at AssignmentOrMethodStatement first and, if it errors out, to then try the DeleteStatement. I see there is are OnErrorIgnore and OnErrorContinue options, but that doesn't solve the ambiguity issue unless I can somehow convert the delete token's id and classification on the fly at that exact moment to make it a standard identifier.

I know the language I bring to you is unusual: it's a deriviative of BASIC that allows for some very nasty code:

If Return = Return() then
    Return
end else
    Return = Return()
end

I guess I'm trying to determine if I need to cut my losses and abandon the LLParser framework in favor of a custom IParser. I thought I'd check first to see if there is something I overlooked.

Comments (2)

Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Kevin,

These situations can be tricky.  The only way to really solve them would be to use a can-match callback.  You would have to order the non-terminal with the can-match to be earlier in the alternation list than the other ambiguous.  The non-terminal you select to be the one with the can-match callback is generally going to be the easiest one to write the callback for.  I don't know your grammar, but if the DeleteStatement always has a Delete keyword, optionally followed by a Cursor keyword, and then an expression that has to start with an Identifier, you could fairly easily look for that scenario in a can-match callback to resolve the ambiguity.


Actipro Software Support

Posted 10 years ago by Kevin Fournier
Avatar

I probably jumped the gun with this post. After some thought, I decided to try a CanMatchCallback for the AssignmentOrMethod production. The reason I wanted to go that way is so that I can cover all other keywords by checking this first. As it turns out, it wasn't as hard as I had feared. It only took about thirty lines of code.

At any rate, I'm very pleased the framework is flexible enough to handle these odd scenarios, even if it doesn't strike me right away. Thanks for you time.

The latest build of this product (v24.1.1) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.