Fully Qualified Name Based Scoping

[we-wake-act21]

Hi Team,

I’m working on building a DSL with scoping similar to Java. As a reference, I've considered the Xtext-based Xtend DSL. When I attempt to write the following code in both Xtext and my Langium-based DSL:

In the Xtext DSL, ddd.hello2 is correctly recognized as a package:

However, in my Langium DSL, ddd.hello2 is not being parsed as a package. Instead, ddd is being treated as a separate entity, rather than resolving ddd.hello2 as a single unit:

How can I resolve this issue? Do I need to add custom logic to the parser, or is this a scoping-related problem?

For reference, below are snippets of my Langium-based and Xtext-based DSLs, which are used to resolve such expressions.

Langium DSL:

MemberCall infers Expression:
    PrimaryExpression
	({infer MemberCall.previous=current} 
    // Member call with function call
        ("." element=[NamedElement:ID] (
		(explicitOperationCall?=('(')
		(
		    arguments+=Argument (',' arguments+=Argument)*
		)? 
		(')')) | (
        (
        arrayAccess?='[' arraySelector+=Expression ']' ('[' arraySelector+=Expression']')*
		)?) )? 
    // Chained function call
        |(
		explicitOperationCall?='('
		(
		    arguments+=Argument (',' arguments+=Argument)*
		)? 
		')')?
        arguments+=MClosure
        )
    )*;

Xtext DSL:

XMemberFeatureCall returns XExpression:
	XPrimaryExpression
	(=>({XAssignment.assignable=current} ('.'|explicitStatic?="::") feature=[types::JvmIdentifiableElement|FeatureCallID] OpSingleAssign) value=XAssignment
	|=>({XMemberFeatureCall.memberCallTarget=current} ("."|nullSafe?="?."|explicitStatic?="::"))
		('<' typeArguments+=JvmArgumentTypeReference (',' typeArguments+=JvmArgumentTypeReference)* '>')?
		feature=[types::JvmIdentifiableElement|IdOrSuper] (
			=>explicitOperationCall?='('
				(
				    memberCallArguments+=XShortClosure
				  | memberCallArguments+=XExpression (',' memberCallArguments+=XExpression)*
				)? 
			')')?
			memberCallArguments+=XClosure?
		)*;

Any insights on how to fix this would be greatly appreciated!

[cdietrich]

in this case it is not pure xtext but xbase.
and in this case xtext links all elements of the a.b.c to the same qualfied element. (if parts cannot be resolved on their own)

i guess you would have to customize the linking behaviour to do the same

• figure out the situation
• figure out the complete name and ask scope by complete name, not the simple name only (DefaultLinker.getCandidate)
• adapt scoping to use the complete name

if a.b.c also can be local you need to figure out the shortest match path as well.
so if there is a a, link to the a, otherwise if there is a a.b link to a.b etc

[we-wake-act21]

hi @msujew,

Thanks for the clarification — I see what you mean now.

Yes, I do understand that in the current setup, each segment before a . is resolved step-by-step into a MemberCall, with each previous field pointing to the preceding element, and eventually leading down to an ElementReferenceExpression like com. So the structure being built is indeed in reverse, which makes sense from the perspective of how Langium handles this.

However, my confusion comes from the fact that in a similar DSL I had previously written in Xtext, the expression com.act21.qwerty.Entity.Input was resolved differently. There, the entire path com.act21.qwerty.Entity was treated as a single qualified name — essentially representing a namespace or package — and Input was resolved as the class (or final element).

So I'm wondering: is there a recommended approach in Langium to achieve this kind of resolution? That is, to treat a long dotted chain as a single logical reference (namespace + class), instead of breaking it down into a MemberCall chain? Or would that require a structural change to the grammar?

Appreciate your input!

[cdietrich]

can you please provide your complete xtext grammar incl. inferrerer. the snippet you have posted is from xbase.
and as i said the magic is done in scoping there
so you need to implement that scoping behaviour in your langium scope provider implementation

[msujew]

I don't think a grammar change is required. Only the scoping needs to be adjusted: In the end, each segment of the fqn references one element. Therefore, in your scope provider, you might need to create synthetic elements that represent packages and their contents. I.e. a Container element named com containing an element named act21 and so on. That way, each reference has some element to resolve to. AFAIK this project has done something like this.

[we-wake-act21]

@msujew , @cdietrich Thanks for the insights.

I actually tried a similar approach where, during workspace initialization, I create an in-memory Langium document that holds all Namespace elements along with their respective classifiers. I’ve implemented a NamespaceProvider service that updates its internal structure using the onUpdate method of LangiumDocuments.

Then, during the scope-computation phase, I ensure that all references to namespace elements are resolved using this precomputed structure — effectively treating each segment in the FQN as a synthetic container element (e.g., com, com.act21, etc.), just as you described.

Does this align with the approach you're suggesting, or would you recommend any changes or improvements to this mechanism?

[davydkov]

In likec4, I went down this path.

My grammar

type Referenceable = DeploymentNode | DeployedInstance | Element | Imported;
FqnRef: value=[Referenceable:Id] ({infer FqnRef.parent=current} '.' value=[Referenceable:Id])*;

I have constraints like:

• Element contains other Elements, i.e cloud.backend.api is a fqn for the api, which sits on 3rd hierarchy level
• DeploymentNode contains other DeploymentNodes or DeployedInstances
• DeployedInstance referencing Element

I have constraints like:

• Element can contain other Elements, e.g., cloud.backend.api is the fully qualified name for api, which sits at the third hierarchy level.
• DeploymentNode can contain other DeploymentNodes or DeployedInstances.
• DeployedInstance references an Element.

To comply with these rules and provide superb code completions, I customized the ScopeProvider.
But before that, I do a preparation step:

1. Listen to onDocumentPhase(IndexedContent), traverse the AST and create a tree-like Index of AstNodeDescription
   Important: I create and cache the index per document.

2. In the custom ScopeProvider, I use a merged index from all documents.
   By the way, I noticed that generators as a source for StreamScope performs better.

With these indexes, I even achieved non-strict FQN referencing. Suppose this tree:

cloud
├── service1
│   └── api
└── service2
    ├── api
    └── db

I can resolve cloud.service1.api - as it is a fully qualified name.
I can also resolve cloud.db, since db is unique within cloud.
But resolving cloud.api fails, because api is ambiguous inside cloud.

You can check this behavior in the playground. Try changing line 36!