Emil Axelsson wrote: > 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.
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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
