GLSP LSP, Model Server, Code Gen

[paulfrench]

I'm new to all this. I started with EMF Cloud, read up on EMF as recommended then started to try and understand the steps required to build a web based modelling tool where you can use a text grammar or diagram builder etc. Hence you get pushed to look at the web based coffee editor as an example.

So I'm very interested in Langium but trying to understand whether I can still achieve what I need to do. So I can create my own grammar, great! I can create a VScode language extension for my grammar. What about GUI editor support, can this still be done. Do I need a model server?

What about code generation? If Langium is aiming to stay in the Typescript/Javascript tech stack world what code gen frameworks can I use? For example https://plopjs.com/ is quite a simple and powerful templating system for code gen that we have used.

Basically will I be able to create an equivalent of the coffee editor (text and gui editors kept in sync) using Langium and choose a nice code gen framework to suit?

In the current example of the coffee editor Xtend is used as the code generator language. Xtend seems almost redundant with java supporting text blocks (java15 I think) plus we need a jvm.

I've lots of questions but that's enough for now. Your thoughts would be great!!

[msujew]

Hi @paulfrench, thank you for your question.

In the current stage of the Langium project, we aim to improve the editor support (LSP features, and related stuff) as a first priority. However, there are plans to integrate the visualization library Sprotty to Langium in a separate package soonish (there are a few changes to Sprotty that need to happen before that). I'm not sure about GLSP integration, as I haven't worked with that a lot so far.

Do I need a model server?

Assuming you are running a Langium based language server in vscode, the necessary requests for visualization support can target the language server directly, without the need of a separate server.

What about code generation?

We currently provide a thin API to generate code using a GenerateNode structure. However, downstream users of Langium are free to use their own templating libraries/systems. We generally try to keep Langium at dependency minimum, and therefore don't include any libraries for that. plopjs looks like it does the job quite well.

Basically will I be able to create an equivalent of the coffee editor (text and gui editors kept in sync) using Langium and choose a nice code gen framework to suit?

While at the current stage of the project, it would be quite a lot of work to implement a gui editor for a Langium based language server, I assume that will be way easier once we integrate Sprotty in there.

[paulfrench]

Many thanks Mark. I'll have a play with Langium in the meantime and also look forward to Sprotty integration. Great stuff.

[spoenemann]

I hope by the end of this year we will have a ready-to-use integration of Sprotty and Langium that enables automatically generated graphical views from a text file. The other direction, synchronizing changes from a graphical editor to the text, is not in the current roadmap for Langium.

[paulfrench]

Okay thanks for the info. I'll have to decide up front whether sync editing is required (from graphic to text) and if so will have to stick with a language server using xtext/java instead of Langium.

As for Langium so far all looks good! Got an extension working nicely with my grammar and now looking at code gen, just trying to get to grips with the AST Typescript model generated.

What limitations does a VSCode DSL extension have using Langium (Chevrotain) over Xtext ?

[msujew]

Got an extension working nicely with my grammar and now looking at code gen, just trying to get to grips with the AST Typescript model generated.

That's great to hear. If you have any blockers, feel free to ask another question on this board :)

What limitations does a VSCode DSL extension have using Langium (Chevrotain) over Xtext ?

From a parser perspective, Xtext supports LL(*) (unbounded lookahead) grammars, while Langium only supports LL(k) (with k being generally 3, but users can modify that). However, I'm currently in the process of building a LL(*) lookahead mode for Chevrotain, so hopefully, that won't be an issue for too long.

Of course, Xtext is currently way more feature complete, supporting a few more LSP features/language features like formatting and serializing DSL data (i.e. writing a file in your DSL format based on an AST model). But we plan to add most of that to Langium as well. So there's no real limitations for Langium compared to Xtext in regards to VSCode extensions.

[paulfrench]

Hello @msujew,

Your thoughts would be appreciated. So currently if I want to achieve a coffee type editor functionality i.e. form based, gui based editors as well as text (all synchronized with each other) I need to stick with Xtext for now. Is that correct? I've managed to get an XText Lanaguage Server working but it was painful due to some not obvious bugs and the latest stable Eclipse XText is still pulling in LSP4J 0.10.0 which has a horrible bug eclipse-lsp4j/lsp4j#478 that is difficult for a newbie to find. I had to go and debug VScode as well as the language server in Eclipse to find the problem. In the end installing Eclipse Xtext latest milestone build (2.26.0.M2) was required so that LSP4J 0.12.0 is used in your eclipse ide project. To me that is a painful introduction to XText language server.

Cheers

[spoenemann]

An integration with Sprotty is already in preparation: #308