5 ms·
While I agree with all of the benefits of DSL writing, I kind of feel like DSLs in Ruby are a bit silly now. There is always a thin line between "lots of functi
by tel 12y ago
While I agree with all of the benefits of DSL writing, I kind of feel like DSLs in Ruby are a bit silly now. There is always a thin line between "lots of function abstraction" and DSL (e.g. a shallow embedding is pretty tough to distinguish from... well, just a library) and that line is even thinner in the fast-and-loose world of Ruby DSLs.
It's a vague enough question to lead to nothing but religious wars, but I really want to push people who are interested in (e)DSLs to consider their implementation in typed languages. Haskell is, of course, a favorite of mine, but you can achieve similar things in Scala and the ML family. You can even go much further using something like Idris, mostly by using its stronger dependently typed system.
- sklogic 12y agoHaskell is not very suitable for the efficient and straightforward eDSL implementation. Template Haskell is a nice thing, but it is staged (cannot use the template definition from the same module) and enforces explicit template syntax. And the usual Haskell DSLs are in fact all just ad hoc interpreters, missing all the benefits of having an underlying compiled runtime environment. And typing is not a big deal, once you have a proper metaprogramming, you can easily add typing on top of your underlying language.
- tel 12y agoYou can take advantage of the Haskell compiler with a shallow embedding, you can do your own compilation steps with a deep embedding, you can do partial evaluation to speed up compilation. You can introduce your own type system, of course, but it's really nice to have most of that infrastructure pre-built for you (otherwise why embed?).
- sklogic 12y agoThe only reasonable ways of implementing fully compiled DSLs in Haskell are standalone DSL compilers (e.g., as in Happy) or Template Haskell (restricted syntax, stages, limited reflection). Both ways are not as convenient as with the more metaprogramming-oriented languages, plus the lack of reflection limits the potential for integrating DSL into the host language and the other DSLs. Yet, TH is really nice. I cannot stand languages without any metaprogramming capabilities at all, and TH just ticks the box for me.
- tel 12y agoMost of the benefits of DSLs can be achieved without "full compilation" I strongly believe. DSLs are great, eDSLs are a great intermediate sweet spot.
- sklogic 12y agoCompilation 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.
- tel 12y agoI 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.
- sklogic 12y agoIf 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.
- tel 12y agoI 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.