2010/10/30 Tim Daly <d...@axiom-developer.org>: > Macros in lisp get used for three general purposes, at least > in my experience. > > The first purpose is efficiency. In common lisp you will find > that you can generate very machine-efficient (aka optimized > fortran level) binary instruction sequences if you add type > information. This gets tedious to do in code so you write a > macro. So (+ x y) has to assume that x and y are anything, > including non-numeric. If you write a (plus x y) macro it > can expand to > (the fixnum (+ (the fixnum x) (the fixnum y))) > which I have seen optimized into a single machine instruction. > Macros could be used to solve the boxing/unboxing issues in > Clojure.
For writing DSLs, consider the excellent speak of cgrand at the conj : (not= DSL macros) Here are the slides: http://speakerrate.com/talks/4895-not-dsl-macros > > The second purpose is novel control structure. Axiom uses a > type-dispatch macro that does a "method lookup" in a "class" > (bad analogy but...) and the type dispatch macro gets expanded > at compile time to a constant-index offset into a fixed-array > data structure. So the total cost is a single index pointer fetch > at runtime. You could write a "domap" macro that works like the > "map" function but isn't lazy. Replace your "map" with "domap" > and solve the lazy issue mentioned in another thread (or just use > seq :-) ) > > The third purpose is a domain specific language. At work my team > always communicates using certain words and phrases such as CCAs, > behavior catalogs, etc. and we use a locally invented notation. > I took the notation and added parentheses in all the right places > and implemented macros for them. Now I can take a specification, > plop in some parens, and execute the specification. This makes it > much easier to ensure the implementation follows the specification. > It also allows me to macro-expand the same line of code for several > kinds of output Our files are XML but our displays are for humans. > Since both outputs come from the same macro I know they match. > > Macros are not hard but you need to think like a compiler rather > than a programmer. You are transforming a program into a program. > > Macros really bring home the point that your program is data and > your data is a program. It is worth learning to write macros just > for that insight alone. > > Tim Daly > > > On 10/28/2010 3:55 PM, Raoul Duke wrote: >> >> hi, >> >> not looking to stir up a pot, looking to learn from people's >> experience. i've heard that in CL land, one is told to avoid macros as >> long as possible. i've heard other folks in the Clojure world say that >> if you aren't using macros, then sorta why bother use a Lisp since you >> are missing out on one of the most powerful differentiators. then >> reading about Conj it sounds like some folks say stay away from macros >> if you can. >> >> any way of teasing out when macros are ok? :-) i mean, are they only >> ok for the internals of the Clojure system? >> >> thanks. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
