Question

I’d like to know good strategies for deploying a domain-specific-language which must run under at least 2 languages (Java, C#) and probably more (Python, and possibly Javascript).

Some background. We have developed and deployed a domain-specific language currently written in C#. It’s deployed though a series of method calls whose arguments are either common language primitives (string, double, etc.), Collections (IEnumerable, HashSet, …) or objects in a domain-specific library (CMLMolecule, Point3, RealSquareMatrix). The library is well tested and the objects have to comply to a stable deployed XML schema so change will be evolutionary and managed (at least that’s the hope).

We hope the language will become used by a wide and partially computer-literate community, used to hacking their own solutions without central control. Ideally the DSL will create a degree of encapsulation and produce the essential functionality they need. The libraries will manage the detailed algorithms which are many and varied but fairly well known. There’s a lot in common with the requirements of the DSL in Domain-specific languages vs. library of functions.

I’d appreciate ideas on the best architecture (clearly once it’s deployed we cannot easily backtrack). The choices include at least:

• Creation of an IDL (e.g. through CORBA). The W3C did this for the XML DOM – I hated it – and it seems to be overkill
• manual creation of similar signatures for each platform and best endeavour to keep them in sync.
• Creation of a parsable language (e.g. CSS).
• declarative programming in XML (c.f. XSLT). This is my preferred solution as it can be searched, manipulated, etc.

Performance is not important. Clarity of purpose is.

EDIT There was discussion as to whether application calls contitute a DSL. I have discovered Martin Fowler’s introduction to DSLs (http://martinfowler.com/dslwip/Intro.html) where he argues that simple method calls (or chained calls) can be called a DSL. So a series like:

point0 = line0.intersectWith(plane);
point1 = line1.intersectWith(plane);
midpoint = point0.midpoint(point1);

could be considered a DSL

Answer 1

There seems to be some ambiguity in the question between language and library. The terms “internal DSL” and “external DSL” are useful, and I think are due to Martin Fowler.

An “external” DSL might be a standalone command-line tool. It is passed a string of source, it parses it somehow, and does something with it. There are no real limits on how the syntax and semantics can work. It can also be made available as a library consisting mostly of an eval-like method; a common example would be building a SQL query as a string and calling an execute method in an RDBMS library; not a very pleasant or convenient usage pattern, and horrible if spread around a program on a large scale.

An “internal” DSL is a library that is written in such a way as to take advantage of the quirks of a host (general purpose) language to create the impression that a new language can be embedded inside an existing one. In syntactically-rich languages (C++, C#) this means using operator overloading in ways that seriously stretch (or ignore) the usual meanings of the operator symbols. There are many examples in C++; a few in C# also – the Irony parser toolkit simulates BNF in a fairly restrained way which works well.

Finally, there is a plain old library: classes, methods, properties, with well-chosen names.

An external DSL would allow you to completely ignore cross-language integration problems, as the only library-like portion would be an eval method. But inventing your own tool chain is non-trivial. People always forget the huge importance of debugging, intellisense, syntax highlighting etc.

An internal DSL is probably a pointless endeavour if you want to do it well on C# and Java. The problem is that if you take advantage of the quirks of one host language, you won’t necessarily be able to repeat the trick on another language. e.g. Java has no operator overloading.

Which leaves a plain old library. If you want to span C# and Java (at least), then you are somewhat stuck in terms of a choice of implementation language. Do you really want to write the library twice? One possibility is to write the library in Java, and then use IKVM to cross-compile it to .NET assemblies. This would guarantee you an identical interface on both of those platforms.

On the downside, the API would be expressed in lowest-common-denominator features – which is to say, Java features :). No properties, just getX/setX methods. Steer clear of generics because the two systems are quite different in that respect. Also even the standard way of naming methods differs between the two (camelCase versus PascalCase), so one set of users would smell a rat.