I need to start writing the second part of the book soon. This one is supposed to take a DSL implementation through all the interesting stages that I would like to cover. However, I am not sure yet what the subject of the DSL will be. I need something that has enough scope to last for about a hundred pages, complex enough to expose usual problem when writing DSL and not tied to a specific domain so strongly that it would be hard to outsiders to grasp.

I am also interested in knowing what kinds of patterns and problems you would like me to cover.

My current line of thinking is to build several DSL around the backend of an online store. That domain should be fairly familiar to all, and it is rich enough to offer a lot of things to discuss. It is also a good place to discuss several types of DSL.

I was thinking of the following DSL:

Message routing / dispatch DSL

Order processing DSL

Then we will extend that to be a generic rule engine DSL

Perhaps creating a testing DSL for those DSL or for the domain itself

The main problem that I have now is that building those DSL is very simple, I don't think that it would be enough to cover everything the we need to build DSL. In that light, I am looking for either more ideas or challenges on the use of the above mentioned DSL.

Yeah Ayende, just like code generators, right? I think the point is the same: having a tool generating an underlying syntax via a gui interface or some wizards versus a having a language.

On top of that you could push supported features as you like, to have it complex as you like ("...it has to be complex enough...") and regular expressions is something quite known... not deeply known maybe, but for who runs with scissors it is surely something at least known ("...be useful and familiar enough...").

Auto manufacturing / auto dealer would be a good subject, as you can have different lines of products with different sub-products and rules that govern what can be included in a final car package. Supply chain can be incorporated as well for part and automobile locations, etc.

Plus, you have the opportunity to represent current CAFE standards as well as the mandate for a flexible rules engine that supports new CAFE standards, ala what's been passed recently in the US.

one problem domain that is general and still close to many customers' world is questionnaires. I have created a DSL for that purpose, although using Gold Parser and not Boo.

Questionnaires tend to (like most other things) start out pretty simple, but soon the customer wants to be able to define for instance questions that yield other questions, or to define new types of possible answers.

The downside of my suggestion (related to your book) is that it's an example of a 100% declarative DSL, where as Boo gives the power to mix declarative and imperative DSLs, and is strongest at imperative ones.