Game Development Reference
In-Depth Information
data, which can be used for arbitrary application domains. SQL is an example of a technically oriented, external DSL.
Altogether, we can categorize DSLs that abstract a technical problem space as highly technically oriented (as has been
done similarly by Kleppe, 2008
6
).
In contrast, there are languages that describe non-technical domains. For example, Inform, currently in its
seventh installment, features a declarative DSL with a very natural language-like syntax to create interactive fiction
applications, as shown in Listing 13-4. Inform 7 abstracts a non-technical domain to allow users to create their own
interactive fiction without handling technical issues.
Listing 13-4.
Rule Description in Inform 7
Instead of throwing something at a closed openable door, say “Or you could just use the handle like
anyone else, of course.”
Figure
13-2
provides an overview of possible DSL forms of interest in this chapter. While a DSL is either internal
or external, the dimension of technical orientation is certainly somewhat blurry, allowing DSLs to address different
fields of application. As it is especially hard to think of a popular internal DSL with a low technical orientation,
Figure
13-2
shows an example of a made-up language, which could be embedded in C++ to equip characters and set
some properties.
Figure 13-2.
A DSL landscape
Note that DSLs do not have to be textual, but can be graphical, contain tables, or mix different kinds of
representations. Although it is a major decision whether to use a textual or a visual language, this differentiation is of
no further concern for the workflow presented here. The decision should always be made individually in a very early
phase of language engineering and should depend on which representation best fits the domain at hand.
6
Kleppe, Anneke. Software Language Engineering: Creating Domain-Specific Languages Using Metamodels. Amsterdam:
Addison-Wesley Longman, 2008.
