Compilation is much simpler than interpretation, especially an ad hoc one, in a Haskell or Ruby idiomatic style.

Compiled DSL implementations are much more declarative - they simply define how a DSL is mapped to the other DSLs or a host language.

Compiled DSLs are more efficient - you don't want an interpreted regexp engine, don't you?

Compiled DSLs are IDE- and static-analysis-friendly, at no additional cost.

Compiled DSLs are more modular and reusable - by sharing the same runtime environment, they can be easily mixed together, their fine grained properties can be picked individually and mixed into new DSLs.

Having said that, I see no single advantage of the interpreted DSLs.

I simply disagree with all of that, or at least partially with the 3rd point. But I also don't see the point in continuing this argument. Sorry.

If you can provide me with any evidence that interpretation can be more efficient than a static compilation outside of the marginal cases, I'd be very grateful.

I did a lot of research in tracing JITs, runtime partial specialisation and all the related stuff, but so far there is no practical and useful implementation of any of such techniques which could beat a mere straightforward static translation.

I never claimed it could be more efficient. I'm completely in agreement that compiled DSLs are more capable. I'm even a big fan of eDSLs which produce compiled output. I don't find completely static, compiled exterior DSLs to be as frequently useful, however, due to the massive increase in maintenance cost---this holds especially true when you have a sufficiently expressive type system to embed the type system of your eDSL into.

Then I did not understand your reference to the 3rd point.

I'm not talking about fully standalone compiled DSLs (totally agree they're usually unmaintainable) - I was referring to the metaprogramming-based compiled eDSLs, implemented as macros on top of a host language (or a range of host languages). This way it's really easy to mix traits into your DSL design, including various type systems, not even necessarily directly compatible with the host language type system.

I found it very productive to have Prolog (or anything comparable) as one of the host languages, it's trivial then to map most of the practical type systems to it.