5 ms·
Domain-Specific Languages made simpler
- draegtun 14y agoThis was also cross posted to blogs.perl.org (http://blogs.perl.org/users/jeffrey_kegler/2012/08/domain-specific-languages-made-simpler.html http://blogs.perl.org/users/jeffrey_kegler/2012/08/domain-sp...) where comments can be made.
- p4bl0 14y agoFor those interested by the topic, you may also want to give a look at Racket[1]. See for instance this ACM Queue article[2] by Matthew Flatt. [1] http://racket-lang.org/ http://racket-lang.org/ [2] http://queue.acm.org/detail.cfm?id=2068896 http://queue.acm.org/detail.cfm?id=2068896
- skrebbel 14y agoI might be missing something but how does "a new parsing algorithm" imply "easier DSLs"? I mean, with stuff like xtext/xpand around and things? You can describe a DSL grammar in a pretty straight forward way and immediately get excellent (Eclipse) IDE support for the grammar and your newly generated spec. And with JetBrains MPS around, and so on?
- wonderzombie 14y agoYeah, this proposition had me scratching my head, as well. I guess the OP's method is, in some sense, easier, but it doesn't strike me as easy. When I imagine easy, I imagine ad-hoc DSLs in Ruby or (dare I say it) Lisp.
- draegtun 14y ago> When I imagine easy, I imagine ad-hoc DSLs in Ruby or (dare I say it) Lisp. These are what Martin Fowler calls an internal domain-specific language. These Ruby/Lisp/Perl/Scala/etc embedded DSL's blur the lines between an API and a DSL. What the OP is referring to is a full blown (external) DSL.