Thu Sep 3 21:28:25 CEST 2009



Kathleen Fisher
Charles Consel

Gabor Karsai
Juha-Pekka Tolvanen
Marjan Mernik

Cameo of Walid Taha during Q&A.

What I take from this is the divide between DSLs for programmers and
DSLs for end users.  The former take mostly the form of embeddings in
gp languages, while the latter tend to be more like advanced raphical
configuration tools.

In other words, using the following two components:

   - a language L (formally specified or not)

   - an implementation map L->B which translates L to some base
     language B.  this map possibly serves as the only specification,
     and possibly encoding knowledge in the form of implementation

It is important to distinguish applications based on whether the end
user will be changing the L->B map.  The vast majority of commercial
applications of DSL this seems to be _not_ the case.

I.e. for RAP based abstractions, you're not only interested in L
(highlevel description of problem/solution) but also in the
implementation choices made by L->B.

Simply put, if user of DSL == creator of DSL, very different rules
apply then when this is not the case.

One more remark: I think it was Gabor Karsai that mentioned that DSLs
work really well, but the problem is integration: merging DSLs with
other DSLs.  To me it seems this problem disappears when you embed a
DSL in another language: for interfacing, there is always the host
language to fall back to, and it being a `real' language, will have
decent, general composition mechanisms.