Interesting. Thanks for your response. On Apr 14, 10:06 am, Ken Wesson <kwess...@gmail.com> wrote: > 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
