I'm writing a GOLD Parser grammar for VBScript. Here is an extract:
<CallStmt> ::= 'Call' <CallExpr>
| <CallExpr> <ParameterList>
!| <CallExpr> '(' <Expr> ')'
| <CallExpr> '(' ')'
<AssignStmt> ::= <CallExpr> '=' <Expr>
| 'Set' <CallExpr> '=' <Expr>
| 'Set' <CallExpr> '=' 'New' <CallExpr>
<CallExpr> ::= '.' <LeftExpr>
| <LeftExpr>
<LeftExpr> ::= ID
| IDDot <LeftExpr>
| ID '(' <ParameterList> ')'
| ID '(' <ParameterList> ').' <LeftExpr>
!VBScript allows to skip parameters a(1,,2)
<ParameterList> ::= <Expr> ',' <ParameterList>
| ',' <ParameterList>
| <Expr>
|
! Value can be reduced from <Expr>
<Value> ::= <ConstExpr>
| <CallExpr>
| '(' <Expr> ')'
I have a conflict concerning the <CallStmt> ::= <CallExpr> <ParameterList>
rule. This rule describes calling a sub without surrounding parentheses. For example the following statements are syntactically correct:
obj.sub1(1, 2).sub2 1, 2
obj.sub1(1, 2).sub2(1),(2)
Call obj.sub1(1, 2).sub2(1, 2)
How can i discriminate between a sub call with surrounding parentheses sub1(1, 2)
and a sub call with parentheses surrounding the arguments sub2(1),(2)
?
The problem you're having is that the VBScript syntax is ambiguous.
Which variant is
obj.sub1 (1)
? The one with parens around the arguments, or the one without and the first argument happens to be in parens?If we cannot tell, then neither can the parser... we can only tell for sure when we have multiple arguments, e.g. a comma. Therefore, let's say that by default we choose to only use parens for arguments when we encounter more than one parameter or no parameter at all.
In your efforts to solve the issue you have started to make over-competent terminals which also include the dot. This is a bad idea, since it doesn't work (spaces around the '.' are allowed but not matched by these terminals) and it can lead to unexpected tokenization behavior and degraded performance. Typically it indicates a problem in your grammar.
Here's a grammar I hacked together which parses your samples just fine, and in fact should also handle assignments and constructor calls correctly. Note that the
<ParameterList>
will only match two or more parameters but not zero or one parameter; this is key to work around the ambiguity which causes your issue.