If the macro arguments are evaluated, the macro does not need to expand the language. All you can do with functions:
(eval-some-code '(.. some code here ..)) Even VisualBasic can do this: eval_some_code ".. some code here .." On 28 сен, 12:57, ru <soro...@oogis.ru> wrote: > Dear Michal, > > You and others explain me how Clojure (or Common Lisp) handles my > code. Very detailed and thoroughly. I want to draw attention to > another point: > The documentation says that the macro function is called with the > arguments unevaluated. So I write code for that function on that > assumption. And when I run this code the arguments being evaluated. It > does not matter why or how and when! They mustn't evaluated never in > that case in accordance with the documentation! That is the question! > Because the unevaluated arguments is an important feature that allows > you to expand the language using macros. > > On 28 сен, 00:35, Michał Marczyk <michal.marc...@gmail.com> wrote: > > > > > > > > > Hi Ru, > > > let's input your macro definition at the REPL: > > > user> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#))) > > #'user/infix > > > So far so good. Now let's try use it in a function: > > > user> (defn foo [] (infix (5 + 4))) > > #'user/foo > > > Well now -- it compiled! So, there's no exception being thrown when > > the macro is expanded at compile time; otherwise foo would not have > > compiled. > > > How about calling foo? > > > user> (foo) > > ; Evaluation aborted. > > user> *e > > #<ClassCastException java.lang.ClassCastException: java.lang.Long > > cannot be cast to clojure.lang.IFn> > > > There's your exception: at runtime. By this time there is no trace of > > your macro in the running code (you could undefine it -- by saying > > (ns-unmap 'user 'infix) -- and this would have no effect on foo). > > > Once again: (5 + 4) *is not evaluated when the macro is expanded*. It > > is only evaluated at runtime -- and only then does it explode, as > > expected. The key point is that a macro is just a function called upon > > by the compiler to transform your program prior to it being compiled > > into JVM bytecode (in the case of Clojure, or perhaps native code in > > the case of some Common Lisp implementations and execution by the > > interpreter in interpreted Lisps); if it generates erroneous code > > (like this version of infix!), that erroneous code will be compiled by > > the compiler and eventually explode when you run it -- an unpleasant > > occurrence completely distinct from a macro-expansion-time exception. > > > Sincerely, > > Michał -- 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
