10

I'm debating designing a domain specific language to simplify a given, obscure programming model. Part of the debate is whether to build it (as a script) atop an existing language/runtime (e.g. Java) or to make it stand-alone (own compiler, &c).

Those of you with DSL design experience, do you have pros/cons and or a sure-fire answer to the appropriate approach?

Jé Queue
  • 3,937
  • 2
  • 29
  • 37
  • who's the consumer of this DSL? and what are the potential hosts (you mentioned Java, are you considering other possibilities)? – Mauricio Scheffer Jan 24 '11 at 05:27
  • I consider any possibility for the hosts. Consumer will be those writing asynchronous programs (messages with destinations). – Jé Queue Jan 24 '11 at 05:47

5 Answers5

9

I would recommend creating your DSL on top of an existing language (internal DSL). I've done this a few times with Python, creating systems where the consumer of the DSL writes a python file that is used as a configuration file for the system. The configuration file uses constructs (classes, functions) that I have defined. These constructs form the DSL.

IMO, a language like Python (IronPython or Jython if the host system is .NET or Java) or Ruby (IronRuby, JRuby) is better for basing your DSL on than Java or C#.

In my case the host systems has also been (C)Python, so choosing Python for the DSL has been the natural thing.

Some pros:

  • Lower cost of building. There is a lot less for you to implement. You can focus on the problem at hand instead of spending time to implement a parser/compiler/interpreter.
  • Access to the host language: Your language will have access to the full power of the existing language/platform.
codeape
  • 487
  • 2
  • 10
  • I'm pretty language agnostic, but why do you think Python incarnations are better suited? – Jé Queue Jan 24 '11 at 23:11
  • 1
    Better suited than what? I guess Ruby and Python have many of the same benefits, Ruby is maybe even better suited for internal DSL because of its more flexible syntax. As for Java and C#, I've seen many a fine fluent interface in those languages (and there are constructs in newer versions that make internal DSL creation/use easier, like object initializer syntax) - but IMO the "low ceremony" languages are slightly better suited than "high ceremony" languages. – codeape Jan 25 '11 at 09:19
  • 1
    I chose C# to implement an internal DSL precisely to leverage "free" compile-time static type checking. Dynamic language DSLs don't give too many advantages over external DSLs. – Den Apr 27 '15 at 11:32
  • @Den that's exactly what's disappointed me when I've tried to do iDSLs in Python. In Java your iDSL feels like it gets instant support from the IDE. Haven't found an IDE that will do that for Python. – candied_orange Feb 16 '19 at 13:46
2

Look at Xtext (http://www.eclipse.org/Xtext/) and Xbase (http://blog.efftinge.de/2010/09/xbase-new-programming-language.html). If the users are non programmers I don't think you should base your DSL on an existing programming language. It will be too complicated for them. A "clean" DSL can be very efficient if made correctly.

Henrik
  • 121
  • 3
2

Rather than recommending a particular approach, allow me to recommend Martin Fowler's Domain-Specific Languages as an excellent resource for making the decision. It has an extensive, thought-provoking examination of the relative merits of internal and external DSLs.

eggsyntax
  • 121
  • 3
1

In his book "Domain-Specific Languages", Martin Folwer describes internal and external DSLs.
Internal DSL = is a subset of existing programming language e.g. Ruby/Java etc.
External DSL = you define a syntax and a vocabulary.
An external DSL can be much more expressive, but can require an external parsing and code generation.
While an internal DSL doesn't require an additional processing, but is sometimes hard to understand for non-programming domain experts (e.g. business analysts, testers).

When choosing your type of DSL, it's important to analyze who its users are. If they are mostly non-technical people, then an external DSL can be a better choice. For a small team of experienced programmers an internal DSL can be chosen, if the programming language they use is expressive enough.

olha
  • 179
  • 5
1

There is a third option - build a DSL as a compiler atop of a general purpose language. Any language with some reasonable degree of metaprogramming capabilities will do the job, including even such a low-level thing as C++. I prefer Lisp and similar languages for this kind of things, but Template Haskell or Nemerle could provide the same level of flexibility as well.

SK-logic
  • 8,497
  • 4
  • 25
  • 37