Implementing existing DSLs with Xtext – a case study, part 0
This is the first installment in a series of blog posts on how to implement a “typical” existing DSL using Xtext. It’s intended as an informal guide showing how I tend to go about implementing a DSL, solving often-occurring problems and making design decisions. I’m actually going to implement two DSLs: CSS (version 3, on average) and Less. These are technical DSLs rather than domain DSLs, but I’ve only got a finite amount of time per week so live with it, alright?
The case of existing DSLs is both an interesting and a common one: we don’t have to design the language which means we can focus purely on the implementation and don’t have to bother with everything that goes into designing a good language. On the other hand, we are often forced to deal with “features” which might be cumbersome to implement in the “parsing tech du jour”. In the green field case, you’d have the freedom to reconsider having that feature in the language at all, but not here.
For this case study, I chose Less because it appealed to me: I kind-of loath working with CSS directly. Although Less provides a way of getting feedback on syntactical and semantic validity through less.js and highlighting/language assist modules have been developed for various editors, I’d rather have a full-fledged editor for the Less language instead of a tedious “change-compile-fix type” development cycle. Also, it seemed a rather good showcase for Xtext outside of the now-popular JVM language envelope.
It became apparent early on that I’d also need a full implementation of CSS as well since Less extends CSS, which gives me a chance to show how to do language composition as well as grammar generation with Xtext. Other aspects which will be addressed, are: expression sub languages, type systems, evaluation and code generation using model-to-model transformation.
This post doesn’t have any technical details yet: sorry! You can follow my efforts on/through Github, which holds the sources as well as a downloadable ZIP with deployable Eclipse plug-in JARs.
Some weeks ago, I started a project with quite the same scope: Defining a less-like DSL. Now I will stop my own work and will follow your efforts.
BTW: Do you know a solution for Bug 362655 with Xtext 2.1?
You didn’t have any code in a public repo yet, did you? I searched for existing implementations (Xtext or not) but didn’t find any outside of less.js.
For the SimpleNamesFragment thing: have a look at this class in my LessCss repo.
I look forward to it! I’ve been looking for something like this, and now I get both inspiration and code to look at. And perhaps the license will let me use it, too.
License is the usual MIT-style “hopefully it’s useful” license, so yes: no problem to use it.