On Tue, Dec 29, 2009 at 6:36 AM, Kim-Ee Yeoh
Conal gives a lot of useful advice on DSL design. One way to start is to articulate existing pain. Where and why is SQL painful? Another trick is to work backwards: What kind of code do you really want to write?
A bit of unsolicited opinion: Be careful with the latter tactic. It is a good way to get ideas flowing, but to cling to it is to commit yourself to a possibly inferior solution. The code we "want" to write is that which matches the way we think, and I suspect most people who have learned Haskell (at least me) have experienced their way of thinking being inferior. Haskell is more beautiful and powerful than the best language I could have designed before I learned it. My way is to think hard about what the best way to think about things is. FRP is a beautiful example: reasoning with functions of time. If there is not something immediately obvious, or the obvious thing is too complicated, scour the brains of smart people and wikipedia for mathematical abstractions which capture the same thing you are trying to capture -- mathematicians spend a lot of time thinking about how to think about things. The best API design will come from inventing the perfect abstraction -- if it has already been invented, chances are it has been written approximately as well as it can be (modulo minor details). The best API will teach its users to think better -- but the designer must have already retaught himself to have invented the API in the first place.
Whether you employ GADTs, initial datatypes, finally-tagless codata, etc. isn't really relevant at this stage. Prematurely latching on to a particular tool gets everything treated like a nail, even when they're nowhere close.
Amen! Luke