| I don't find the arguments against macros workable since the emergence of syntax transformation while modeling a problem shows many deep relationships between parts of the domain .. in the cases I've seen. Just want to share some stuff that I haven't seen others write about. I don't code much lisp these days (though getting into clojurescript a bit now), but when I used to, the cycle went pretty much like this - 1. Express what you want to express as an s-expression, capturing known structures in the simplest way I can think of. 2. Figure out which aspects can be "functions" straight forwardly and which are macros and implement them. 3. Test and iterate a bit till I like the way domain elements are composing and the way the composition looks in code. Try to reduce the required concepts in each iteration. 4. Document the relationships that have emerged from this process so others can understand it. 5. Usually I'm done, but sometimes (the few) users of my "api" come back with questions, based on which I iterate a bit more. I've mostly followed this in building the "editing style specification language"[1] part of the product "muvee Reveal" (an automatic video editor)[2], built in a custom scheme dialect called "muSE"[3].
(Full disclosure: I've happily worked for muvee Technologies from 2002 to 2011.) Btw - most discussion on macros and lisp seem to first assume that there two things - a) functions and b) macros. There are more, depending on the kind of lisp system you're working with. You could form a taxonomy of sorts based on whether argument forms are evaluated and whether the result form is evaluated - 1. Argument forms are evaluated before "apply", result is a value (i.e. not evaluated). => Function 2. Argument forms are unevaluated before "apply", result is code (i.e. is evaluated). => Traditional macro 3. Argument forms are evaluated before "apply", result is code (i.e. is evaluated). 4. Argument forms are unevaluated before "apply", result is a value. => Traditional macro (depending on system) In the course of using the domain modeling approach above, I've written stuff like functions that create one or more macros, macros that evaluate to function values (not s-expressions) and such stuff that might be considered an "abomination" by the OP ... but in the context of the domain, the concepts are usually clear enough to be used without major issues. [1]: https://code.google.com/p/muvee-style-authoring/
[2]: http://www.muvee.com/en/products/reveal
[3]: https://code.google.com/p/muvee-symbolic-expressions/ |