I've done some compiler work in Haskell like writing programs (semantic actions) as algebraic data structures and then transforming or interpreting the tree. Would I gain something by using Lisp macros in this instance?
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
That's close, but not quite the wording I remember, so I must have seen it somewhere else as well. That's a pretty good description of what I was referring to, though.
In preface:
As well as writing their programs down toward the language, experienced Lisp programmers build the language up toward their programs.
Then later in 1.2 "Programming Bottom-up", pg rephrases that statement:
In Lisp, you don’t just write your program down toward the language, you also build the language up toward your program
The easiest answer to that is, there's no syntax, which makes reimplementing your own Lisp parser trivial (one single function call, in fact). This in turn makes reimplementing your own Lisp, inline in Lisp, similarly trivial.
That sounds like something out of an SICP exercise - and it is - but the same properties make it easier to reason about your code in a way that's far more abstract than other languages let you. Once you start treating your code as data that other parts of your code can manipulate, you can start refactoring in ways that simply aren't possible in other languages. This explanation by a well-known Perl programmer explains it very well: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h...
Another way I've heard it (this may have been pg, but I can't remember), is that, when writing idiomatic Lisp, you first think, "What language would make solving this problem really easy?" and then proceed to implement that language.