Defining the defmacro function using only LISP primitives?

The problem with trying to do this on a machine like McCarthy's LISP machine is that there isn't a way to prevent argument evaluation at runtime, and there's no way to change things around at compile time (which is what macros do: they rearrange code before it's compiled, basically).

Up vote 10 down vote favorite share g+ share fb share tw.

(including Scheme and Clojure) macros clojure lisp scheme primitive link|improve this question edited Aug 21 '10 at 2:47Isaac Hodes4,13421038 asked Aug 21 '10 at 2:02hawkeye2,2041344 85% accept rate.

1 Defmacro is a macro itself, not a function. – Svante Aug 21 '10 at 3:12 2 @Issac Hodes: Check again, defmacro in Clojure is a macro – Brian Aug 21 '10 at 14:38 1 Isaac, you are missing something. Look immediately after the end of the (def ...).

– dreish Aug 21 '10 at 16:11 2 Every macro in Lisp is just a symbol bound to a lambda with a little flag set somewhere, somehow, that eval checks and that, if set, causes eval to call the lambda at macro expansion time and substitute the form with its return value. If you look at the defmacro macro itself, you can see that all it's doing is rearranging things so you get a def of a var to have a fn as its value, and then a call to . SetMacro on that var, just like core.

Clj is doing on defmacro itself, manually, since it doesn't have defmacro to use to define defmacro yet. – dreish Aug 22 '10 at 1:40 1 Right, that does make sense—I suppose that does mean I should be considering it to be a macro. I was coming at it from the wrong perspective I suppose!

Thanks for getting me on the train :) – Isaac Hodes Aug 22 '10 at 14:01.

The problem with trying to do this on a machine like McCarthy's LISP machine is that there isn't a way to prevent argument evaluation at runtime, and there's no way to change things around at compile time (which is what macros do: they rearrange code before it's compiled, basically). But that doesn't stop us from rewriting our code at runtime on McCarthy's machine. The trick is to quote the arguments we pass to our "macros", so they don't get evaluated.

As an example, let's look at a function we might want to have; unless. Our theoretical function takes two arguments, p and q, and returns q unless p is true. If p is true, then return nil.

Some examples (in Clojure's syntax, but that doesn't change anything): (unless (= "apples" "oranges") "bacon") => "bacon" (unless (= "pears" "pears") "bacon") => nil So at first we might want to write unless as a function: (defn unless p q (cond p nil true q)) And this seems to work just fine: (unless true 6) => nil (unless false 6) => 6 And with McCarthy's LISP, it would work just fine. The problem is that we don't just have side-effectless code in our modern day Lisps, so the fact that all arguments passed to unless are evaluated, whether or not we want them to, is problematic. In fact, even in McCarthy's LISP, this could be a problem if, say, evaluating one of the arguments took ages to do, and we'd only want to do it rarely.

But it's especially a problem with side-effects. So we want our unless to evaluate and return q only if p is false. This we can't do if we pass q and p as arguments to a function.

But we can quote them before we pass them to our function, preventing their evaluation. And we can use the power of eval (also defined, using only the primitives and other functions defined with the primitives later in the referenced paper) to evaluate what we need to, when we need to. So we have a new unless: (defn unless p q (cond (eval p) nil true (eval q))) And we use it a little differently: (unless (quote false) (quote (println "squid!

"))) => "squid" nil (unless (quote true) (quote (println "squid! "))) => nil And there you have what could generously be called a macro. But this isn't defmacro or the equivalent in other languages.

That's because on McCarthy's machine, there wasn't a way to execute code during compile-time. And if you were evaluating your code with the eval function, it couldn't know not to evaluate arguments to a "macro" function. There wasn't the same differentiation between the reading and the evaluating as there is now, though the idea was there.

The ability to "re-write" code was there, in the coolness of quote and the list operations in conjunction with eval, but it wasn't interned in the language as it is now (I'd call it syntactic sugar, almost: just quote your arguments, and you've got the power of a macro-system right there. ) I hope I've answered your question without trying to define a decent defmacro with those primitives myself. If you really want to see that, I'd point you to the hard-to-grok source for defmacro in the Clojure source, or Google around some more.

Explaining it fully in all its details would require an awful lot of space and time for an answer here, but the outline is really pretty simple. Every LISP eventually has in its core something like the READ-EVAL-PRINT loop, which is to say something that takes a list, element by element, interprets it, and changes state -- either in memory or by printing a result. The read part looks at each element read and does something with it: (cond ((atom elem)(lambda ...)) ((function-p elem) (lambda ...))) To interpret macros, you simply (?) need to implement a function that puts the template text of the macro somewhere in storage, a predicate for that repl loop -- which means simply defining a function -- that says "Oh, this is a macro!

", and then copy that template text back into the reader so it's interpreted. If you really want to see the hairy details, read Structure and Interpretation of Computer Programs or read Queinnec's Lisp in Small PIeces.

I can't find much mention of them in the PDF with a quick search. – Isaac Hodes Aug 21 '10 at 4:40 This may be an oversimplification, but are you saying that if I wrote my own eval function I'd be 80% of the way there, provided my eval function knew what a macro declaration was, and what a subsequent call to that macro was. – hawkeye Aug 21 '10 at 13:32 If you want the semantics of macros to match CL/Clojure, eval would first call macroexpand-all on the form and then pass the result to a primitive eval that doesn't need to know about macros.

I have implemented a small lisp this way and it works quite well. – Brian Aug 21 '10 at 14:48 @Brian oh nice, that's pretty interesting. I'm considering doing the same myself: what language did you write it in?

And is the source posted somewhere? – Isaac Hodes Aug 21 '10 at 20:15 @Issac Hodes: The repl and primitive eval are written in Clojure, the fancy eval and macroexpansion code are written in itself. I just made the project available at github.com/qbg/strange – Brian Aug 21 '107 at 4:08.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.