Lambda the Ultimate

Why are DSLs so often associated with Haskell? I've read a few DSL papers and they always seem to use Haskell in their examples.

Related, I guess (I have no idea really!) that most DSLs require internal state. Doesn´t that mean that any end-user code written using a DSL embedded in Haskell will have to use the "Monad syntax" (I'm assuming that the target user isn't supposed to understand monads)? Sounds a bit messy.

Suppose you want to add if to an eager language. You cannot write a function to implement this functionality, since if is lazy: the then part is not executed before the if function executes (eager), only when needed (lazy).

Had you used an eager language you'd have to write if as a macro (hopefully the language you use has a good macro facility. Most don't).

So a lazy language gives you flexible evaluation order.

Indeed behind the scenes your are going to use mondas. But these can be hidden from the programmer using the DSL, so this is less of an issue.

The only ways round this that I can think of are to either use unsafe operations or write a parser on top of Haskell. Neither seems very nice.

As long as you program in the DSL itself, their mondaic nature can be hidden from you. When you try to combine it with 'regular' Haskell code, you must take into account the fact that the code is monadic.

BTW, you can find more details of this approach in Hudak's paper (esp. section 5, Modular Mondadic Interpreters).

1. Domain Specific Language
2. Embedded Language
3. Program Generating Language

I'd like to make some comments about an interesting non-functional family of languages that seem to bear two of the above three characteristics.

The Waba language and its forks SuperWaba and Ewe (Open Source) are interesting examples of embedded languages:

• www.ewesoft.com
• www.wabasoft.com
• www.superwaba.org

They use Java's syntax, compiler, and subsets of its class library, virtual machine, and bytecode specifications, to "grow a language" from scratch, re-using the more established language's already existing , thoroughly tested syntax and api's.

Waba is useful yet, because it's small size and re-use of key features in the larger language, easy to understand and comprehend as a whole like the numerous "toy" examples people use to illustrate a point in papers and textbooks.

Are the Waba Languages "Domain Specific" ? They certainly aren't general purpose. They're made for communication, entry, display, and storage of information on small mobile devices. They include special constructs that integrate these capabilities like Ewe's "Live Objects" :

"objects that, in a way, 'know' how to display themselves on the screen, how to allow users to edit themselves, how to validate their own data and how to encode/decode their data to savable text strings." (Programming Ewe - Live Objects)

Waba takes the exact reverse strategy of "program generating languages" . It doesn't even deal with syntax because it's embedded in Java generating and executing Java bytecode. Maybe, "Waba Platform" would be better than "Waba Language" ?

(Kamin defines a "program generating language" to be a "language in which programs are actually specifications for programs in other languages." Apparently, the "host" and "target" languages cannot be the same. (Kamin's host: SML, Kamin's target: C++) The syntax apparently has to be different, the syntax in the host being better suited to specifying programs of a specific domain rendered in the target language. )

Cheers,

Jon Fernquest

One thing I notice about these two languages, though, is that although the motivation was narrow in focus, the languages themselves wind up being general purpose. I'd speculate there is pressure to widen up any DSL, as users attempt to use the language for disparate purposes. What may start out as a DSL, ends up being a full blown programming language.

A special purpose language like Oak that's geared towards devices talking to one another over a network connection, winds up being a be-all language like Java. The problem, of course, is that the design decisions that made sense in a limited domain become an impediment to uses for applications that fall outside of the targeted domain.

On monads, however, the paper is pretty light. It turns out that all the nasty details (and they're pretty nasty to non-Haskell-wizards like me) are in the paper at http://www.cse.ogi.edu/~mpj/pubs/modinterp.html which dives into the details of combining monads etc. Note that the result, while elegant, is fantastically inefficient, hence the need for partial evaluation. Also, they end up dropping Haskell for Gofer because they needed extra oomph.

So I think it's fair to say that Haskell is nice for papers and simple "library DSLs", but for heavy lifting you can get into some deep monads doodah...

How does Haskell compare to Lisp for DSLs? As I see the pros and cons, for Haskell we have type checking (syntax extension is a non-issue when the syntax is as regular as Lisp's). For Lisp we have macros which allow one to write compilers for DSLs, as opposed to interpreters in Haskell. This can get around the performance problem and I think is an important advantage (and hey, you can build type checking into your macros if you want).

Remember that you can usually transform an interpreter into a compiler (or at least do enough partial evluation to speed things up).

This is one of the arguments for embedding DSLs inside general purpose languages. This way you can always use the underlying language facilities. I think Shivers talks about this in his Lambda: The Ulitmate Little Language paper.