On Friday, 9 August 2013 03:58:40 UTC+8, Jace Bennett wrote: > Thanks, Mike. > > I guess my simple example is too simple. Out of the hypothetical, have you > used techniques like this? >
Not exactly your use case, but I've written probably the two most complex games so far in Clojure... games have a lot of state and interaction with the environment that needs setting up but I still manages to make the game updates themselves purely functional, without any use of macros. Just a thin non-functional wrapper is generally all you need. Also core.matrix maintains a map of "available implementations" which is probably pretty analogous to your endpoint map. > > 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. > Well at some point, if you are going to make the endpoints work at all, they have to be declared. And this declaration has to result in a runtime structure that can be queried as required, which implies some form of state. There are many ways you could express your endpoints: - Pure data (nested maps, vectors, keyword etc.) - but this still needs something else to perform the side effects required to make them live) - Function calls of the "create-endpoint" type - Some form of macros But whichever you use, you will ultimately need to have some functionality to translate these declarations into a data structure that stores your endpoint. > > How do folks usually go about it when they have a desire to query the > running system about its shape and structure? > I would store the information about the running system in a single, immutable persistent data structure (usually nested maps+vectors+sets, occasionally records and immutable Java types). Store this in either an atom, an agent or a ref (depending on how you want to handle concurrent access and updates - typically an atom is sufficient unless you care about transactional updates to this state) > > > > On Thu, Aug 8, 2013 at 2:36 AM, Mikera <mike.r.an...@gmail.com<javascript:> > > 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<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.
