Support extending DSLs with DAP

[georg-schwarz]

It would be awesome to simplify creating debuggers for the DSLs created by Langium.

In VS Code this would be supporting the Debug Adapter Protocol (DAP).

Are there any plans in that direction? Or is there already a good example on how to extend Langium-generated VSCode extension with a debug feature?

[spoenemann]

I don't think we can simplify that in the general case because debug adapters depend on the execution runtime of your language. There are two main scenarios:

1. You generate code of a general-purpose language from your DSL. In that case you can use the debugger of the chosen target language. If that debugger supports source maps, you can generate such source maps along with the actual code.
2. You interpret your DSL, e.g. using the AST obtained with Langium. Then you need to write a debug adapter based on vscode-debugadapter-node which acts as a remote control for your interpreter.

Both scenarios can't be generalized.

Except... if we'd create a library to ease the implementation of interpreters. Such a library could define a common API that can be generically connected to DAP 🤔

[msujew]

@spoenemann @georg-schwarz In my opinion, any good interpreter built using Langium should actually just generate JavaScript code and source maps. Maybe add some domain functionality using an additional package, but there's really no reason to build your own interpreter for a Langium based language. Packages such as astring already perform the code generation (including source maps), one only needs to transform a Langium AST to a JS AST.

[georg-schwarz]

Thanks for the very fast response! I think I owe you some more context:

We went down the route to implement our own interpreter in the Jayvee project (case 2 mentioned above). First user feedback reported that they'd want a debugger like they are used from by general-purpose languages. Our first research led us to the Debug Adapter Protocol (DAP) with the repo vscode-debugadapter-node you mentioned.

I can imagine this is a common scenario for langium projects (?), thus I hoped you've already made some experiences in that regard and we could tap into your expertise.

Except... if we'd create a library to ease the implementation of interpreters. Such a library could define a common API that can be generically connected to DAP thinking

Obviously, that would be an awesome addition to your langium ecosystem!

Do you have any projects at hands that went down the same road for inspiration? Otherwise, I'd be happy to share our experiences once we successfully went down that rabbit hole ;-)

[spoenemann]

IMO there are still important use cases for an interpreter:

• Custom widgets showing live results for DSL text
• Security: you might not want to send the generated JS somewhere to execute it. In distributed scenarios, sending and interpreting the DSL text is much more secure.

Do you have any projects at hands that went down the same road for inspiration? Otherwise, I'd be happy to share our experiences once we successfully went down that rabbit hole ;-)

I know of projects connecting an existing runtime/debugger to the DAP, but I haven't seen a debug adapter for a TS/JS interpreter yet.