parsingabstract-syntax-treedslmpsdsl-tools

What approach graphical DSL workbenches use: Parsers or projections?


To my knowledge there are 2 approches that DSL editors use:

1- Parser based approach to develop textual DSLs: The user specifies a grammar and the workbench generates a parser that recognize this grammar. The parser builds an Abstract Syntax Tree that is used by code generators and so on.

2- Projectional approach: here there is no parser. The Abstract Syntax Tree is directly edited by user's gestures and projection rules specify how The Abstract Syntax Tree is rendered. This allow the use of different notations (Textual, graphical, tabular... ) at the same time.

Now When I look at graphical only DSL workbenches (such as DSL-tools from Microsoft) I wonder what approach they use and what are the steps involved behind the definition of the DSL. If it's the projectional approach so why is it limited to graphical notation only?

My idea is that it uses both. The projectional approach to make the notation graphical but the models are saved in a specific format (XML for exemple) and parsed.

Thank you.


Solution

  • Well, strictly speaking, any "graphical" editor is projectional. The ability of a language workbench to have different notations, like in MPS, is enabled by the fact that the tool has these notations built in, together with the ability to define several editors for the same piece of model. In the case of MPS it's even possible to create new notations as a plugin (so without having to change MPS itself).

    I would say that saving the models to any storage medium can't ultimately be anything else than textual or binary. Any editor that wants to save models will serialize to one of those two options, even MPS. So since it wouldn't make sense to say that there is a projectional way to save models, you can either say that both DSL-tools and MPS have the textual approach for saving and a projectional editor, or (my preferred option) simply that both DSL-tools and MPS can produce projectional editors.

    Also, I wouldn't agree to call DSL-tools a language workbench. As you can read in https://homepages.cwi.nl/~storm/publications/lwc13paper.pdf a program has to meet a bunch of criteria (more than DSL-tools can meet in my opinion) to be a language workbench.

    In general, I would say that any "graphical" language workbench (i.e. a language workbench that produces editors that are not plain text) uses the projectional approach.