Extend the grammar language to declare additional types

[spoenemann]

Xtext uses EMF and related technologies (e.g. Xcore) to generate AST types. I have seen quite often people using unreachable "dummy rules" in Xtext grammars so they can leverage the automatic AST model generation to avoid the hassle of maintaining an externally defined Ecore model. My idea is to make this explicit in Langium: instead of using unreachable rules (I'd mark those with warnings), we could introduce a new construct to declare types.

Example:

type MyType {
    myProperty1: string
    myProperty2: MyOtherRule
}

One question I have is how to deal with the auto-generated types of parser rules. On one hand that's very useful, but on the other hand it means we cannot use cross-references when writing a reference to a type like [MyType | ID]. We could solve that by making the reference target (MyType) a simple string instead of a cross-reference, and customizing editor features such as go-to-declaration for our grammar language.

Alternatively, we could enforce the explicit declaration of all types. That makes migration from Xtext more difficult and leads to larger grammar files, but it can make it easier to detect problems.

[OLibutzki]

I'm not sure what's the best approach to solve this, but I want to confirm that whenever the grammar becomes more complex than "HelloWorld" I want to fine-tune the underlying AST.

In Xtext those dummy rules are the last resort before switching to a model-first approach.

I like the idea of defining types as part of the grammar definition, but I fear that it might always miss some features like additional methods and you start building a complex DSL for generating Typescript in the end.

[spoenemann]

I would keep methods completely out of the AST. We don't generate any implementation classes for the AST interfaces, but rather create plain JS objects on-the-fly.

[OLibutzki]

Ok, I see. Sounds reasonable to me and it matches your Langium start small approach.

[pluralia]

The current design of the idea assumes having 2 ways to declare types: interface-like and alternatives.

interface-like

type MyType = {
   myProperty0: number;
}

type OneMoreType = {
    myProperty1: string;
    myProperty2: MyType;
}

Here a type of an attribute can be only another declared type or a build-in type.

alternatives

MyRule :
  '@' name = ID;

type MyAlternativesType = MyType | OneMoreType | MyRule;

An alternative type is one of declared types or a grammar rule. So, it's a way to rise grammar rules on the type level.

[spoenemann]

This topic is now continued here: #406