Il fatto che non si accenni minimamente al DSL Toolkit è assolutamente indicativo:
What is a DSL?
"A thin veneer over top of an API" (Martin Fowler)
Two types of DSL
Internal -- Domain language implemented as a fluent interface in a "standard" language (erg., Ruby, C#, Python)
External -- Domain language that is parsed / compiled as its own language
The Key Attributes of DSLs (Fowler)
1. Should read like a language. This is a subjective criteria, but it should have a type of grammar.
2. Business users (domain users) should be able to make sense of it. In other words, it uses the "ubiquitous language" (Evans) of the domain.
Some Examples of DSLs
1. XAML is a DSL for designers
2. NHibernate is a DSL for O/R mapping and persistence
Possible Pitfalls When Using a DSL
1. The language can become too general very easily. The language must be very specific. Some would say NAnt has drifted too far from its original intent.
2. It can become hard to handle errors and debug a DSL. When this becomes difficult, it's a warning sign that the language is becoming too generic.
3. If you are using an external DSL, you must test the layer between the DSL and the existing API thoroughly.
How to capture a DSL (Fowler). The two approaches
1. Build the DSL over top of an existing domain model and API
2. Capture the DSL with the requirements. Martin noted an experience where a developer had a laptop and was doing some DSL development right with the business expert.
What method should you choose?
No clear winner. It depends on what one you are most comfortable with.
Recommended Tools
1. ANTLr is the tool recommended at the moment for parsing and creating external DSLs.
2. Scott Guthrie recommended the use of debug visualizers to help with debugging and error handling.