
Domain-Specific Languages made simpler - draegtun
http://jeffreykegler.github.com/Ocean-of-Awareness-blog/individual/2012/dsl.html
======
draegtun
This was also cross posted to blogs.perl.org
([http://blogs.perl.org/users/jeffrey_kegler/2012/08/domain-
sp...](http://blogs.perl.org/users/jeffrey_kegler/2012/08/domain-specific-
languages-made-simpler.html)) where comments can be made.

------
skrebbel
I 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
Yeah, 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
_> 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.

------
p4bl0
For 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/>

[2] <http://queue.acm.org/detail.cfm?id=2068896>

