Domain-specific modelling languages (DSMLs) and the underpinning infrastructure of IDE support, model transformations, code generation… are essential to this.
In class, you have learned about many of these technologies, and have applied them in a small way to
a fairly small language. In this piece of coursework, I challenge you to go larger: pick a domain-specific
language of your choice and build infrastructure for it. You can pick any existing domain-specific language—either a technical language like Docker or jHipster, or a language addressing concerns in
a non-technical domain (e.g., SBML from biological modelling, or public space patterns from urban
modelling). Don’t know where to start? Here is a great conversation on Twitter, where many people
have suggested their favourite languages. If you really want to impress me, you can pick a domain for
which there isn’t yet a language.1
In any case, you need to develop the following pieces of the language’s infrastructure:
1. A working editor with syntax highlighting, code completion etc. for textual languages and efficient edition support for graphical languages;
2. Validation support both for syntax, static semantics (well-formedness), and at least one advanced semantic check (dynamic semantics or some form of type checking, static verification
3. Language semantics to enable some form of execution either through analysis (simulation
based or other) or actual execution (interpreted or compiled) depending on the type of language. For some existing languages, this may be easiest to do by building an improved version
of the existing language and writing a transformation that translates to the original language.
Think carefully about what validation and semantics are most useful for your chosen language. This
will be different for different languages. In fact, even when two students have chosen the same language you may still end up focusing on different validation and semantics, depending on the purpose
you are considering most important. For example, for a jHipster implementation you may choose
to focus on generating running application implementations (different from those already generated
by the existing jHipster infrastructure) or, alternatively, may provide analysis of potential performance bottlenecks in the modelled application. You may also choose to build a better jHipster and
translate down to jHipster. Or why not translate from webmachine to jHipster?
A Git repository with the implementation of your language, including a README file indicating
how to use the language infrastructure and an example project that can be used to demonstrate the capabilities of your language and infrastructure. It is your responsibility to ensure
that the instructions in the README file can be used on a fresh machine (Windows or Linux)
to explore the capabilities of your language at least in the context of the example project