83 karma · joined October 5, 2016
(The author is left as an exercise for the reader)
Sure it's an intuitive way of representing your data. Is it the most appropriate though? See an example [0] about using Projectional Editing in order to use mathematical notations for formulas.
[0]: http://voelter.de/data/pub/gemoc2014-voelterLisson-MPSNotati...
Your AST is what EMF calls a "model". By default the "backend" and ecosystem surrounding EMF is skewed towards Java for historical reasons, but there have been some prototypes with other languages as well. You can serialize your AST in any way you like, although by default it relies on XMI files. You can implement your own textual concrete syntax, or rely on a database. The EMF ecosystem has tools for implementing textual or "graphical" concrete syntaxes. You can combine them (e.g. usually a specific subset of your AST gets edited in a certain way that's best for your targetted end users). The ecosystem also has tools for performing comparisons and plugging them into your editing means.
Of course all of this tooling requires a lot more work than an LSP server.
I couldn't find the "B by b" syntax from the Kotlin docs, can you tell me that this does ?
How do you expect the visual syntax to integrate with VCSs? Do you have an algorithm and UI to present visual conflicts? How is the layout after a Git merge?
Cheers