> The authors were experimenting with new programming languages in the field of naturalistic design. Hereby, the overall process of creating new experimental languages seemed inconvenient to us: the syntax has to be specified in a modified way fitting exactly the grammatical requirements of a particular parser; then, helper code has to be written to dissect the parse-tree. Finally, the semantics (in the form of code fragments) are added by assigning a meaning to the nodes of the parse-tree. We found that this process is very tedious and error-prone; thus, we stipulate that there should be a cleaner and easier way to create new (experimental) languages.

> The use of macros is popular and widespread, ranging over different languages from C to LISP. Macros give the programmers more control over the language. Yet, a lot of contemporary programming languages lack a syntactic macro facility. Current languages are "given" to us by some company, language designer or independent project group. Certainly, we would design some features different in some way or introduce new features sooner as they would maybe happen to come with the next release. A macro facility would be a way to mobilize our creativity for the overall advancement of a language. Therefore, there should be a clean and easy way to syntactically extend languages.

> DSLs play an increasingly important role, in research as well as in practice. This kind of languages – and especially the philosophy behind – addresses the need for well adjusted notations for specific problem domains. Furthermore, DSLs  could be a great help to find a common language with both the customers and the developers to specify the requirements of software. We think that domain specific modeling needs an adequate language, i.e., there should be a clean and easy way to design new domain specific languages and notations.

> Certain ideas of contemporary programming technologies have something very deep in common: they all are the result of (computer) scientists' drive for abstraction. Assembler programmers had to deal with ever repeating tasks in their programs. They would introduce labels so that code-fragments can be reused in an abstract way. Then, they would soon use a stack to pass "values" to the labeled code fragment. What followed is the birth of functions and modules (of functions). Functions in turn led to generic functions and classes, classes led to generic classes and aspects, aspects lead to... ? This whole process is about abstraction. So, our question was: if all advancement in programming languages is abstraction, both semantic and syntactic, why then isn't there a language which is completely dedicated to that paradigm? Would current programming techniques appear as facets of some general abstraction mechanism behind the scene?