On Thu, Apr 14, 2011 at 12:26 PM, Armando Blancas <armando_blan...@yahoo.com> wrote: > I wonder in which cases this code is a good choice: a function that > returns uneval'ed code. Something about macros not being an option > where a function is expected, or a kind of lazy eval? Will this be any > better or worse: (defn m [f s] (fn [] (map f s))) then doing (foo) > instead of (eval foo)?
It is quite common to write functions that return sexps to simplify writing macros; macros can call other functions to build parts of their output. The OP may also have been debugging a macro and reduced his problem to a simple, reproducible example using such a function to generate the problem part of the macro output and eval to trigger it. There are also cases where eval is needed at run-time, such as dynamic on-the-fly runtime function creation. Some of the most sophisticated optimizations involve exploiting patterns in the input not discovered until runtime, or compiling on the fly a version of an algorithm specialized to a particular input; e.g. if you're going to try to factor a big number, you might have code actually generate and compile code to search for a factor for *that specific* number and then execute it, and it might run faster than if that number were an in-theory variable in the code, especially if the algorithm can be changed depending on properties of the number. -- 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
