[Haskell-cafe] Re: Re: What *is* a DSL?

[Ben Franksen]

Emil Axelsson wrote:
> Ben Franksen skrev:
>> minh thu wrote:
>>> 2009/10/7 Günther Schmidt <gue.schmidt at 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.

If it is a stand-alone DSL (i.e. with its own parser), then yes. But I was
referring to Embedded DSLs, i.e. DSL as a library in a host language (eg
Haskell). In this case the user sees the host language by construction,
which means she has less need of function abstraction /inside/ the DSL.

Cheers
Ben