Rationale behind Xtext DSLs

[ilg-ul]

In the Overall design ideas, you start the list with Xtext DSLs for both Configuration & Toolchain.

Can you add more details to support this choice?

What would be the advantages over more ubiquitous solutions like JSON or YAML?

[Kummallinen]

When I looked at this I couldn't map the toolchain definition features I wanted to be able to support into JSON. The same applied to YAML, though that could get closer. Implementation wise using Xtext means we gain both an EMF model which can be used within CDT code as well as a language server which enables external editors effectively for free.

For the configurations, with the Toolchain as a Xtext DSL it makes implementation easier to keep the configurations in Xtext as well as we get a linked model. Additionally the syntax can be more specific and so easier to understand what it will do. Yaml would be workable for this though. There is nothing to stop us using Xtext but making the DSL syntax also valid YAML or JSON, then we keep the some of the Xtext implementation advantages

[ilg-ul]

I couldn't map the toolchain definition features I wanted to be able to support into JSON.

I don't have a mathematical proof, but I think that any definition can be mapped into JSON.

JSON is probably the simplest yet complete format. There are only maps and arrays; from my experience, any collection can be mapped to either a map, if objects have unique properties, otherwise to an array.

YAML is basically the same, just with a simpler syntax.

then we keep the some of the Xtext implementation advantages

If the Xtest files are to be used only by the plug-ins developers, probably it does not matter very much, but if you want power users to extend their own projects with these definitions, then... I don't know if this is a very user friendly solution.

[Kummallinen]

I should have added an "at least not cleanly" caveat for the toolchain definitions. Only having maps and arrays is rather limiting with how the definitions can be structured.

I am open to making the configuration & definition a different format, but I think they'd become harder to read and write then if we used a DSL. At least for the toolchain definitions I think using a full DSL gives a better experience.

I can see some disadvantage to not using a format users would be familiar with but any solution requires the user to understand the definition schema or language. It actually becomes more user friendly to have a DSL as we'd have a built in editor with content assist and validation for the toolchain definition files. Unless you are referring to other people writing their own tools to process the files, which isn't really a use case I'm considering.

[ruspl-afed]

As we discussed in the mailing list, the primary artifact for all this is "the schema of the data" (.ecore).
The suggested DSL may be just one of the possible choices and JSON for sure should be supported.

This prototype is done by XText "straightforward" approach
provide DSL Grammar -> Generate .ecore -> Generate others
but, we can use more advanced and flexible approach:
Provide .ecore -> Provide DSL Grammar that fulfills that .ecore -> Generate others
in that case we are free to support DSL, JSON or whatever can fulfill our schema

[Kummallinen]

It was primarily done the Xtext -> ecore way as this was a quick prototype. I do agree decoupling the model from the Xtext DSL would be better at at future stage.

[ruspl-afed]

Since we preliminary agreed on that, we can switch to discussing .ecore
So, what is described by the single file (JSON or DSL)?

[ilg-ul]

what is described by the single file (JSON or DSL)?

Is this a new topic?

[Kummallinen]

What exactly do you mean by "what is described"? There seems to be several ways of answering that but without knowing exactly what you mean the question is a little vague

[ruspl-afed]

I submitted #5 to discuss this new topic

[ruspl-afed]

Can we close this one?