Multi language support

[cdietrich]

Hi, what are the plans for multi language (see each other) support? stick with one grammar and hope its unambigous?

[msujew]

Hey @cdietrich,

We haven't discussed this extensively internally yet, but my plan was to have a structure similar to this:

grammar somegrammar;

import "./grammar1.fb";
import "./grammar2.fb";

// maybe as part of the language, maybe in a json/yaml config file
config {
  languages {
    language1 {
      entry: grammar1.SomeEntryRule,
      fileExtensions: [".some1"]
    },
    language2 {
      entry: grammar2.SomeOtherEntryRule,
      fileExtensions: [".some2"]
    }
  }
}

The parser would then accept an int as the entry rule, corresponding to the index of the respective rule that should be called. We can generate this out, similar to what we already do with the keywords/tokens we generate from the grammar for the Token#Kind property. Some service like LanguageSelector could be overriden by adopters to make the language selection more fine-grained.

WDYT?

[cdietrich]

so with the imports we would be able to do "type sharing" (needed for references and base rules, this looks good.
we use the following pattern for extensions
.sub1.main, .sub2.main
thus a programmatic approach like
langiums getServices in the service registry would be helpful

[msujew]

Yep, that makes sense. Hence the LanguageSelector service. We don't plan to split the services anymore. This led to a lot of complexity in Langium that we don't want to replicate in Fastbelt. Instead, everything is in one service container and then we have some generated code that performs a few switches based on the specific language. This is essentially only required for the lexer and parser.

[spoenemann]

👍 yes, "shared services" / multiple language services would undermine the simplicity we're aiming for in this project. Just check current file ext and switch implementation where really needed.

The majority of framework users don't need more than one language, so let's make sure the code is not more complicated than necessary for them.