Where the type checking function should be called

[luan-xiaokun]

Hey guys, I'm working on the type system of my DSL. Both the document and #706 suggest that the type checking process should take place after ComputedScopes state and usually before linking. langium-lox also provides a useful example for type checking. Still, there are some implementation details I'm not so sure about and want to make sure I'm on the right track. Thanks in advance.

1. The first thing is about the callback function. The document says that type checking can be called as a callback function using the onBuildPhase method of DocumentBuilder. This means that this callback function should store the result in the langium document, but the current document interface does not have such a property. Do I need to write my own custom document interface?
2. The second question is related to the first one. The linker needs the type checking result to do linking, but I'm not sure if the linking takes place after the execution of the callback function. If not, the type checking result may not be available to the linker.
3. langium-lox takes a different approach, where type checking is lazily called in the scope provider, so the checking result is always available to the scope provider. It occurs to me that type checking can be called inside the scope provider when it is created. Is this a good idea?

[spoenemann]

Do I need to write my own custom document interface?

TypeScript supports interface declaration merging, so you can simply add optional properties to LangiumDocument and assign / use them as you like.

The linker needs the type checking result to do linking, but I'm not sure if the linking takes place after the execution of the callback function.

Usually linking takes place in the linking phase, which visits all cross-references in the document and tries to resolve them. But in case you add a callback between scope computation and linking, and your function accesses the ref property of a reference, lazy linking is triggered by such an access. So if your callback function produces information that is used by the scope provider or linker (e.g. attached to the LangiumDocument), then you should avoid visiting any cross-reference in that function.

It occurs to me that type checking can be called inside the scope provider when it is created. Is this a good idea?

Yes, I would actually start with such a lazy approach because it's simpler. Computing types as part of the build process and storing type information with the document is a performance optimization to avoid computing the same information twice. But as always with optimization, I would not do it until you actually see performance problems.

[luan-xiaokun]

TypeScript supports interface declaration merging, so you can simply add optional properties to LangiumDocument and assign / use them as you like.

That's a good feature to know, now it becomes much easier for me (a newbie in js/ts).

Thanks for the detailed explanation on the lazy linking, and I agree that optimization should not step in too early. Now I feel more clear about how to implement my thought, thanks again!

[msujew]

In addition to what @spoenemann already said, there is a scoping guide in progress over at eclipse-langium/langium-website#79 (see this live link). It goes into more detail on how scoping/linking interacts with a type system, using the lox language as an example.

Note that the actual "type checking" phase usually happens during validation, where we actually show errors for where the type checking/assignability check fails. During scoping we only perform type inference, not assignability checking.

[luan-xiaokun]

That's a great guide! Exactly what I need. Thanks for the documentation!

I often confuse type checking with type inference, what I mean here is type inference.