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

Reply via email to