Enum types with literals different from keywords

[AresEkb]

I need to parse the following code:

class SomeClass
abstract class SomeAbstractClass
interface SomeInterface

Here is the grammar:

grammar ClassModel

entry ClassModel:
    classes+=Class*;

Class:
    kind=ClassKind name=ID;

type ClassKind = 'Regular' | 'Abstract' | 'Interface';

ClassKind returns ClassKind:
    ClassKind_Regular | ClassKind_Abstract | ClassKind_Interface
;
ClassKind_Regular returns string: 'class';
ClassKind_Abstract returns string: 'abstract' 'class';
ClassKind_Interface returns string: 'interface';

hidden terminal WS: /\s+/;
terminal ID: /[_a-zA-Z][\w_]*/;

I get the following AST:

{
  "$type": "ClassModel",
  "classes": [
    {
      "$type": "Class",
      "kind": "class",
      "name": "SomeClass"
    },
    {
      "$type": "Class",
      "kind": "abstractclass",
      "name": "SomeAbstractClass"
    },
    {
      "$type": "Class",
      "kind": "interface",
      "name": "SomeInterface"
    }
  ]
}

But I need kind attribute to have one of the values: 'Regular', 'Abstract' or 'Interface'. How to implement it in Langium?

[msujew]

Hey @AresEkb,

doing that with enum-like types isn't possible. You could do something different however:

Class:
  (
    {infer RegularClass} 'class' |
    {infer AbstractClass} 'abstract' 'class' |
    {infer Interface} 'interface'
  ) 
  name=ID;

That should resolve this issue within the type system by giving you RegularClass, AbstractClass and Interface types that you can use to differentiate between those elements.

[AresEkb]

The problem is that I have an existing metamodel and I'm trying to make AST as close as possible to that metamodel. So I can transform model <-> AST automatically. We develop a modeling tool that allows users to edit models using diagram and table editors. And now trying to add a textual notation for models. We use a metamodel-first approach, not grammar-first

Also our users can define their own metamodels. And we can't force them to use subclasses instead of enums.

I think Xtext's approach is optimal for us:

enum ClassKind:
    Regular = 'class' | Abstract = 'abstract' 'class' | Interface = 'interface';

The ideal variant for us is to import an external metamodel as in Xtext.

Or probably something like the following could work:

grammar ClassModel

entry ClassModel:
    classes+=Class*;

Class:
    ('class' {Class.kind='Regular'} | 'abstract' 'class' {Class.kind='Abstract'} | 'interface' {Class.kind='Interface'} ) name=ID;

hidden terminal WS: /\s+/;
terminal ID: /[_a-zA-Z][\w_]*/;

[AresEkb]

However I understand that all these stuff (enums, external metamodels, complex parser actions) could complicate Langium. Probably instead we should provide our users a simple tool to write model <-> AST transformations. It's usually a good idea to split one complicated task (code <-> model) into separate simple tasks: code <-> AST <-> model

The problem is that we want to make it as simple as possible for our users, provide them a no-code tool. Probably we could extend Langium grammar (add enums, formatting annotations (or printing instructions) as in EMFText) and generate from that extended grammar a Langium grammar and TypeScript code for formatters and value converters

Maybe someone faces the same problems and these thoughts will be useful

[AresEkb]

I think the following grammar works fine for me:

grammar ClassModel

entry ClassModel:
    classes+=Class*;

Class:
    kind=ClassKind name=ID;

ClassKind:
    {infer ClassKind_Regular} 'class' |
    {infer ClassKind_Abstract} 'abstract' 'class' |
    {infer ClassKind_Interface} 'interface';

hidden terminal WS: /\s+/;
terminal ID: /[_a-zA-Z][\w_]*/;

I can automatically transform an AST node of the form { "$type": "ClassKind_Regular" } to a enum literal ClassKind::Regular. So we don't have to implement a custom AST <-> model mapping for each grammar and metamodel

And also such a grammar works fine for code printing (AST to code transformation)

[msujew]

Thinking about this again, you can probably go with your original idea and simply use a ValueConverter override to transform the value into the expected format.