Hi Jace, this is my first answer in this group. Maybe I'm at the same point you are, except my background is in Java, so I just want to share what I understood in the hope to expand your question for the comunity.
I found myself to use a lot of code generation in Java to have the glue among components written for me by various technologies. Maybe this is the same you do with reflection. Lot of metadata and conventions above configuration to avoid configuration getting more complex than the system itself. Maybe functions are your components in Clojure and you can explore defined functions with ns functions (http://clojure.org/Namespaces). I think these are the metadata you talk about and you don't need to accumulate them in macros. I don't know how to explore functions metadata (i.e. their arguments) but it shoud be a matter of function itself to establish its arguments meaning. Maybe you can use macros to have the glue code written for you or maybe you can use other functions for this purpose. You cannot learn about this in 21 days (http://norvig.com/21-days.html). I found this interesting link googling the sentence: "Bad programming is easy. Idiots can learn it in 21 days, even if they are Dummies." found in HtDP ( http://www.ccs.neu.edu/home/matthias/HtDP2e/) :) I don't know how SICP compares to HtDP but thank you for the reference. I can point you to the next book I'll read about macros: let over lambda (http://letoverlambda.com/), but as stated in the introduction macros are the last step to become a well rounded (Lisp) programmer, maybe other aspects of FP itself should be known before. In the hope this little can be useful, Luca Il giorno giovedì 8 agosto 2013 04:19:15 UTC+2, Jace Bennett ha scritto: > > 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 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.
