Menu

Is Fortress the Ultimate Language for DSLs?

Sun has released a new programming language (i.e. Fortress ) that’s been promoted as being designed to support high-performance computing particularly the kind required for scientific computation. In other words, it isn’t a language designed to target the masses, but a language to be used by a niche of developers primarily concerned with scientific pursuits. So Java is the language for the masses, and I guess Fortress is the language for the intellectuals.

But despite this kind of billing, could it be that Fortress may be the ultimate language for developing Domain Specific Languages (DSLs)? A quick peek at some of its features leads one to the conclusion that indeed, Fortress despite being ivory tower like, is a language designed specifically to support DSLs.

Users can freely define new languages which are fully
integrated with each other.

The primary source of information is a persistent abstract
representation.

Language designers define a DSL in three main parts:
schema, editor(s), and generator(s).

Language users manipulate a DSL through a projectional
editor.

A language workbench can persist incomplete or
contradictory information in its abstract representation.

There are several basic ways to build a domain specific language. One way is to write a compiler (using tools like antlr or javacc) to translate one’s ‘little language’ into a form that’s interpretable. A second way is to use a sufficiently maleable language (see syntax extension )to express one’s little language in. Then there’s a middle ground approach where you translate one language to another (see: Compiling to Javascript).

The second approach based on my personal experience is actually the easiest. However, you have to make tradeoffs in that you have to live with certain syntactic features that can’t be changed in the base language. That’s all right when you don’t care about whether a conditional is coded like “if () {} then {}” or “if begin … end then begin … end”. It isn’t such a bad tradeoff, I don’t thing there’s a massive congitive leap from one conditional constuct to another.

The second approach is the approach that one would take if you used Fortress. The language according to Guy Steele is designed to ‘grow’. The first feature that leaps out in Fortress is the fact that the language text can be displayed in a variety of forms. Just like an HTML can be displayed differently using CSS style sheets. The second feature is the sophitication of the parser, if you could write something like “A B” and the compiler deduces that there’s an operator in between infers the types of each object, then surely that’s a feature that’s difficult to replicate starting from parser generators.

The final more subtle feature of Fortress that has a big impact on DSL development is the generalized comprehensions, that is, most languages have very little syntactic support for expressing collections of things (think json). For the more advanced languages like python and ruby that support comprehensions life is a bit better. However, Fortress takes a step further where the definition of comprehensions is a library function and therefore quite maleable.

Transforming a domain specific language to a target programming language is easy when the tranformation is isomorphic. Unfortunately, one of the main reasons why one invents a DSLs is because it’s difficult to express a solution in the target language. One reason why it may be difficult is that that there the structure of the solution domain is quite different from how it coded. Reducing the impedance mismatch between the expression of the solution and how it’s coded is one of the core principles of Object Oriented software development.

Object Oriented software development breaks down when one is confined to the structural relationships imposed by it. One would assume that the world can be accurately expressed in term of entities and their relationships. However, the fact that DSLs exists (apart from reducing tedium) is an indication that there’s more to expressing a solution than defining entities and relationships. It’s the same reasoning why many are skeptical of Model Driven Architecture.

Fortress is a language designed to allow programmers to express their solutions in a manner similar to mathematical notation. One could have not found a better starting point for the design of a language for writing DSLs. After all, one cannot find a richer and semantically consistent collection of DSLs as one finds in math and science. That is Fortress’s design derives from the experience of a community that has been developing complex abstractions for centuries. Most other DSL approaches tend to derive their design experience from relatively impoverished sources.

Figure 1: On the right is the actual Fortress code to implement the specification on the left.