 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 
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
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
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.
|
|
|
|