Language Workbenches and DSLs

Martin Fowler has an interesting piece on Domain Specific Languages here, which manages to go beyond the usual ‘what is a DSL’ line to give some consideration to the pros and cons of working with DSLs inside and outside of your main language.

He defines external and internal DSLs. An external DSL is a custom format which is parsed by custom code written in your main language. An internal DSL is defined using a subset of your main language - dynamic languages like Ruby are good at this, but he argues that the curly-braces brigade can tackle this too, albeit less elegantly.

Using a DSL with an IDE raises an interesting issue, as the IDE typically won’t understand your DSL syntax. (I found the same issue with jython when I moved from text editors to eclipse. All the refactoring support etc. narrowed the gap between writing java and writing jython, which had previously been gazillion times more productive.) One potential problem that Mr. Fowler raises with an internal DSL is the need for the language’s user to master the full syntax of the base language, any of which could potentially creep in. If editing inside an IDE, there will be far more power-tools available that are necessary to do the job.

I wonder whether an IDE could offer profiles for it’s language suport features. A default profile allows everything, but special profiles for DSL’s could be offered that limit the language support - even the syntax - to a subset of the full thing. Imagine being able to write a DSL in java inside Eclipse, but get red squiggles if you try to import a class, or use a for() loop or whatever.

Crazy plan, but it might just work. Does anyone out there with more experience with coding IDEs know if this sort of thing is feasible?

Comments are closed.