I am interested in Domain specific languages, coming from the limited perspective of Fit tables. Fit is a framework for automated storytests, developed by Ward Cunningham. Ward has pointed out that Fit can support the development of DSLs based on the table format.
Tables are used in Fit so that Customers don't need to be so concerned about syntax, as the tables structure the tests. The first row of a table identifies the name of a class of a "fixture" for interpreting the rest of the table. Fixtures are used to provide the "semantics" for what is expressed in the "language" of tables.
ColumnFixture is one such general fixture for managing calculation (function) tests, in which each row of the table specifies an expected result given some values. For a particular test, a subclass of ColumnFixture is written to manage the actual call into the SUT to check whether the actual result matches the expected one.
When the storytests are run, a report is generated. The report is in the same form as the storytest, except that it is annotated and colored to show the results of running the tests.
Fit is a general framework for expression based on tables, and so allows DSLs to be developed, based on that restricted notation. It manages parsing of tables into cells. It provides support for mapping between the notation and the interpretation, handling data type conversion, object creation and method calling in a general way.
I have added to the core fixtures in Fit with the FitLibrary. This allows storytests to be expressed more succinctly, such as with DoFixture. This provides a different interpretation model, so that a sequence of tables are more closely tied together at the fixture level and much less fixture code is needed.
In FitLibrary, I have expanded the structure of the notation beyond tables to include simple graphics and trees in table cells, as well as embedded tables.
I have used Fit for other tasks, such as a build tool and for providing a simple batch-ui into code. I am curious about building a programming language with it for fun, as well as defining type systems with it.
Storytests are a good example of how a DSL can support agile development.
For me, it's important that a language can evolve for expressing storytests. I see storytests as being concrete examples that express things about business objects, processes, calculations and constraints. To understand these and what a system will do, it's necessary to invent and evolve a way of talking about the domain and the system, in the sense of the 'ubiquitous language' of Eric Evans. The requires good examples and good abstraction skills from the team evolving the storytests.
Key to the aims of understanding and communicating the requirements specification is the development of the language in a suitable notation. The business Customer needs to be able to read and write these, so it can help if the formal notation is kept simple.
As with program code, storytests evolve and change as the domain and needed system get clearer and change. So refactoring, etc tools are needed to support them.