For a pretty decent cover of when and how to use macros, On Lisp[1] is a pretty good book. It's written mainly for Common Lisp but most of it translates to Clojure well enough. I find that for common code, writing macros isn't so useful as most of the goods ones are already part of clojure.core. But if you ever find yourself in the position where you'd really like to have a control structure just for your program, or introduce a compile-time code generator, or subtly add a new paradigm to the language, a macro is your ticket.
1. http://code.google.com/p/onlisp/ On Friday, August 9, 2013 9:55:14 AM UTC-4, Jace Bennett wrote: > > Obviously I've encountered the advice "no macros unless you know you need > them" before. And I even sort of know the syntax and what they do. I don't > think that's my problem. > > I think I've lived a life without macros. I mean, clearly > dynamic-functional and even OOP styles are perfectly capable of building > most anything (within my now constrained view of what is feasible). And my > head is full of techniques (what an experienced lisper might call > workarounds) to deal with their limitations, so I'm habituated to the pain, > and the narrow view of 'what is feasible'. > > So, it's not about whether I need a macro at all, because I could deal > indefinitely. There are an endless supply of problems I could solve without > them. It's about wisdom, discerning whether its a good tradeoff to use a > macro in a given situation. I wish this was the kind of thing that could be > taught. Instead, I fear, it must be learned. > > > > On Fri, Aug 9, 2013 at 9:50 AM, Jace Bennett <jace.b...@gmail.com<javascript:> > > wrote: > >> Thanks again, Mike. That's really helpful. >> >> I'll take a look at the core.matrix stuff to try and understand >> implementation and motivation better. >> >> What games did you make? I'd love to check them out. >> >> Jace >> >> On Fri, Aug 9, 2013 at 4:10 AM, Mikera <mike.r.an...@gmail.com<javascript:> >> > wrote: >> >>> On Friday, 9 August 2013 05:07:10 UTC+8, Jonathan Fischer Friberg wrote: >>> >>>> I'd suggest avoiding macros until you absolutely know that you need >>>> them. Usually they aren't necessary. >>>> >>>> >>>> Problem with this is that you don't really know when you need them >>>> unless you know what they do. >>>> >>> >>> I'm not saying "don't learn how macros work". Learning is always good. >>> >>> My recommendation is just that your default approach should be to avoid >>> using them unless you have tried very hard to achieve your goal with pure >>> functions first, and convinced yourself that it isn't possible. >>> >>> Macros are only *needed* IMHO when one of the following applies: >>> - You want to create new language/DSL syntax that isn't expressible with >>> normal function application rules (e.g. short-circuiting evaluation, new >>> control structures etc.) >>> - You need to do custom code generation at compile time for some good >>> reason (e.g. performance, since macros enable you to do compile-time >>> specialisation of code) >>> >>> I wrote about these and gave some examples in a blog post a few months >>> back for anyone interested: >>> >>> http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-in-clojure/ >>> >>> >>> >>> >>>> >>>> On Thu, Aug 8, 2013 at 9:58 PM, Jace Bennett <jace.b...@gmail.com>wrote: >>>> >>>>> Thanks, Mike. >>>>> >>>>> I guess my simple example is too simple. Out of the hypothetical, have >>>>> you used techniques like this? >>>>> >>>>> I have this nagging feeling that there is a more direct and idiomatic >>>>> way to glean this sort of information from my code. I mean, that's why we >>>>> use AST's, right? So we can process them? I shouldn't need a data >>>>> structure >>>>> like the endpoint map in the first place. I just don't know how to >>>>> capitalize on this rather abstract and vague notion. >>>>> >>>>> How do folks usually go about it when they have a desire to query the >>>>> running system about its shape and structure? >>>>> >>>>> >>>>> >>>>> On Thu, Aug 8, 2013 at 2:36 AM, Mikera <mike.r.an...@gmail.com> wrote: >>>>> >>>>>> I'd suggest avoiding macros until you absolutely know that you need >>>>>> them. Usually they aren't necessary. >>>>>> >>>>>> Prefer writing pure functions (without side effects) - these are >>>>>> easier to reason about, easier to test, simpler to write correctly and >>>>>> easier to plug together / compose via higher order functions. >>>>>> >>>>>> For example, in your endpoint example I would probably just use three >>>>>> functions: >>>>>> - a pure "add endpoint metadata to an endpoint map" function >>>>>> - an impure "update endpoints" function that updates endpoints using >>>>>> an endpoint map >>>>>> - a function that calls both of the above to declare and launch a new >>>>>> endpoint >>>>>> >>>>>> There might be a few other helper functions as well but hopefully you >>>>>> get the idea. >>>>>> >>>>>> >>>>>> On Thursday, 8 August 2013 03:19:15 UTC+1, Jace Bennett wrote: >>>>>>> >>>>>>> Thanks to the community for a wondrous programming environment. I >>>>>>> discovered SICP last year, and fell in love with the idea of lisp. But >>>>>>> I've >>>>>>> come to a point where I think I need practice on moderately sized >>>>>>> projects >>>>>>> before more reading will help. >>>>>>> >>>>>>> When starting on almost any moderately scoped effort, I quickly run >>>>>>> into a class of problems which I think may be a fit for macros, but I >>>>>>> want >>>>>>> to understand what is the idiomatic way to approach them in clojure. >>>>>>> >>>>>>> Most of my professional experience is in .NET, and that is probably >>>>>>> coloring my thought patterns a bit. In that context, I often use >>>>>>> reflection >>>>>>> scans and type metadata to configure infrastructural bits and dry >>>>>>> things >>>>>>> up. Instead of having to explicitly register components in the more >>>>>>> dynamic >>>>>>> areas of my app, I use conventions to select components to register >>>>>>> from >>>>>>> the metadata I have about my code. >>>>>>> >>>>>>> I can imagine using macros in clojure to accumulate metadata about >>>>>>> my declarations so that I can query them at runtime. For example, maybe >>>>>>> a >>>>>>> "defendpoint" macro that sets up a handler AND adds it to the routing >>>>>>> table >>>>>>> (or more directly an "endpoint map" which I then use to make routing >>>>>>> decisions among other things). >>>>>>> >>>>>>> Admittedly, something about the sound of the phrase "it's just data" >>>>>>> tells me I'm sniffin up the wrong tree here. But I don't know how to >>>>>>> turn >>>>>>> that nagging feeling into working code. >>>>>>> >>>>>>> Is this a reasonable use of the macro? What about doing the >>>>>>> registration at macro-expansion time vs emitting runtime code to do it? >>>>>>> How >>>>>>> should one approach the problems space otherwise? >>>>>>> >>>>>>> Thanks for your time. >>>>>>> >>>>>> -- >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Clojure" group. >>>>>> To post to this group, send email to clo...@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+u...@**googlegroups.com >>>>>> >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Clojure" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to clojure+u...@**googlegroups.com. >>>>>> >>>>>> For more options, visit >>>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>>>> . >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@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+u...@**googlegroups.com >>>>> >>>>> For more options, visit this group at >>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to clojure+u...@**googlegroups.com. >>>>> >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>> >>>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com<javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> 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 unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
