Ben Franksen skrev:
minh thu wrote:
2009/10/7 Günther Schmidt <gue.schm...@web.de>:
I've informally argued that a true DSL -- separate from a good API --
should have semantic characteristics of a language: binding forms,
control structures, abstraction, composition. Some have type systems.
That is one requirement that confuses me, abstraction.
I thought of DSLs as "special purpose" languages, ie. you give your DSL
everything it needs for that purpose.
Why would it also need the ability to express even further abstractions,
it is supposed to *be* the abstraction.
Programming abstractions at the DSL level, not to further abstract
what the DSL covers.
Functions, for instance, are typical abstraction means offered by
programming languages. Even if your language is specific to some
domain, being able to create your own functions, and not only rely on
those provided by the DSL implementation, is important.
Imagine a (E)DSL for 3D programming (e.g. shading language): the
language is designed to fit well the problem (e.g. in this case, 3D
linear algebra, color operations, ...) but you'll agree it would be a
shame to not be able to provide your own functions.
But isn't one of the advantages of an _E_DSL that we can use the host
language (Haskell) as a meta or macro language for the DSL? I would think
that this greatly reduces the need to provide abstraction
facilities /inside/ the DSL. In fact most existing (and often cited
examples of) EDSLs in Haskell do not provide abstraction.
I would say that the DSL is what the user sees. In this view, I think
it's correct to say that many (or most) DSLs need function abstraction.
Whether or not the internal data structure has function abstraction is
an implementation detail.
/ Emil
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
