Lambda the Ultimate

inactiveTopic Introduction to Special Issue on Domain-Specific Languages
started 9/18/2002; 12:42:18 AM - last post 9/18/2002; 1:06:37 AM
jon fernquest - Introduction to Special Issue on Domain-Specific Languages  blueArrow
9/18/2002; 12:42:18 AM (reads: 1749, responses: 3)
Introduction to Special Issue on Domain-Specific Languages

Most papers on DSL's focus on specific implementation technologies such as Haskell or ASF-SDF, so I'm always a little uneasy when I refer to something that doesn't use these technologies as a DSL, e.g. Mathematica, S-PLUS, SAS, SPSS, or Autocad. The definitions in this very short introduction help clarify what might legitimately be called a DSL by providing some historical context. At the far end of the spectrum even domain specific libraries used in general purpose languages might qualify:

The poor man's approach to DSL implementation is to implement a library to be used via an API in the general-purpose language of choice. This approach is not suitable when the domain requires: dedicated notation, that is, syntax, dedicated abstraction mechanisms, dedicated scoping or typing rules, domain-specific optimizations, domain-specific analyses, domain-specific error reporting...

There were DSL's long before the term DSL arose: "The idea of DSL's is presumably as old as the notion of programming languages." (APT developed at MIT in 1955 is cited as the first DSL.) A "DSL provides built-in abstractions and notations specific to the domain of concern" and it is usually declarative. The introduction also enumerates the costs and trade-offs of DSL's. [Special Issue Homepage] (Special Issue on Domain-Specific Languages Guest Editors' Introduction, Ralf Lammel1 and Marjan Mernik, 2001)

Posted to DSL by jon fernquest on 9/18/02; 12:50:10 AM

jon fernquest - Re: Introduction to Special Issue on Domain-Specific Languages  blueArrow
9/18/2002; 1:06:34 AM (reads: 623, responses: 1)
Recently, I was thinking of posting the Weka Data Mining library (Java) and its GUI interface to LTU as a DSL example. The GUI allows you to sequence calculations on data in the same way a statistical DSL like SAS or SPSS would, so I thought: "Isn't it a DSL?"

According to the definition given above I guess it does lie on the far edge of the DSL spectrum, but the introduction of syntax (like a normal programming language) to capture the DSL-like functionality of the GUI would have one very useful benefit: it would make the GUI portable. The GUI is written in Swing which makes the GUI and its DSL-like features a lot less portable than the library (which I run under Personal Java on the iPAQ all the time, Personal Java = Java 1.8 AWT only).

Ehud Lamm - Re: Introduction to Special Issue on Domain-Specific Languages  blueArrow
9/18/2002; 2:55:48 AM (reads: 660, responses: 0)
Not that quibbling about words is very important, but...

I tend not to regard libraries as DSLs, unless they really provide a language embedding (e.g., syntax extension).

For me this is about the distinction between different kinds of abstraction mechanisms. A programming lanuage provides a set of features to enable the programmer to create abstractions (e.g., subroutines, modules, templates). When these are not enough, you start thinking about extending the underlying language mechanisms.

This analysis, of course, doesn't work for languages that provide language extension mechansims (e.g., macros) as part of the core language (e.g., Scheme).

It is a fine line, but I find this distinction helpful.