Resolve grammar ambiguity

[idiosyncrasy00]

Hello all. So I got a grammar rule like this:

ObjVarCS:
	(isMatched?='$')?name=UnrestrictedName ':'
	(type=[ClassCS:UnrestrictedName]
	| type1=PrimitiveType 
	| type2=Type2)
;

Type2:
	(type2=IDENTIFIER ('('anytype1=UnrestrictedName')')?);

PrimitiveType returns string:
	'String'
	| 'Real'
	| 'Date'
	| 'Integer'
	| 'Boolean'
;

The problem seems to lie in here, since I want to the type is referenced as either class type (type), primitive type (type1) or OCL type (type2), because with the ambiguity, it only recognizes class type, not primitive type or OCL type without parenthesis:

(type=[ClassCS:UnrestrictedName]
	| type1=PrimitiveType 
	| type2=Type2)

How can I resolve this issue, in a case that class type, primitive type and OCL type (without parenthesis) share a common prefix?

[msujew]

Hi @LockedAwya,

What exactly is your UnrestrictedName rule there? Without knowing how it looks, it's difficult to fix the ambiguity.

[idiosyncrasy00]

@msujew Here it is.

UnrestrictedName returns string:
	PrimitiveType
| IDENTIFIER //the default terminal ID of langium (terminal IDENTIFIER: /[_a-zA-Z][\w_]*/;)
| INT //the default terminal INT of langium (terminal INT returns number: /[0-9]+/;)
| EnumerationLiteralName //return string type, like expression PrimitiveType
|'annotation'
|	'documentation'
|	'invariant'
|	'literal'
|	'opposite'
|	'serializable'
|	'sysml'
;

P/s1: Btw I have edited some part of original post due to some changes. You can check it out.
P/s2: Well I can simply reorder the following statement from this:

(type=[ClassCS:UnrestrictedName]
	| type1=PrimitiveType 
	| type2=Type2)

to this:

type2=Type2
| (type=[ClassCS:UnrestrictedName]
| type1=PrimitiveType 

And it still works eventually. But that's not really a good solution since the parser just treats ObjVarCS type as OCL type if the input is just a string ID, not class type or Primitive type.

[msujew]

How do you expect the system to deal with this? As far as parser theory is concerned, you're building an alternative looking something like this (IDENTIFIER | PrimitiveType | IDENTIFIER | PrimitiveType) and expect it to be able to pick the correct alternative based on the fact that the user intended to use a reference to ClassCS there and not create a new declaration of a type. It's literally impossible to know whether the IDENTIFIER is supposed to be a reference or a new type, since the file that contains the referenced element might not even be parsed at this point.

You should rethink your language/semantic design, since this is very unsound. The obvious approach would be to introduce a marker character like @ that indicates that the following identifier points to a reference instead of declaring a new inline type.

[idiosyncrasy00]

@msujew You can check out the grammar definition in my playground here:

Link to the example