<p>Yes, in fact it's quite similar to evaluating <code>DEFUN</code>. Of course, in the paper <code>EVAL</code> has no rule for evaluating <code>DEFUN</code>, since it's treated as an abbreviation. From the definition of <code>DEFMACRO</code> in emacs LISP (<a href="http://www.gnu.org/software/emacs/elisp/html_node/Defining-Macros.html" rel="nofollow noreferrer">link</a>):</p>
<blockquote>
<p>Special Form: defmacro name argument-list body-forms...</p>
<p>defmacro defines the symbol name as a macro that looks like this:</p>
<p><code>(macro lambda argument-list . body-forms)</code></p>
</blockquote>
<p>It's easier if we ignore the name of the macro and treat that as an abbreviation. Then we have simply to create the list <code>(macro lambda argument-list . body-forms)</code> and set <code>name</code> to be shorthand for that list, the same way a <code>(defun name (arguments) (body))</code> sets <code>name</code> as a shorthand for <code>(lambda (arguments) (body))</code>. As for evaluating a macro, that is also easy --- just pass the function inside the macro your arguments, but WITHOUT evaluating them first.</p>

CC BY-SA 2.5
2010-09-07T11:05:08.920Z
Are you saying that defmacro would need to be implemented by both a modification to eval and a new primitve? (Being similar to defun)
hawkeye
CC BY-SA 2.5
2010-09-07T11:31:54.360Z
The name binding part would need a new primitive, or however it's actually handled in eval --- since the paper treats the name-binding part of defun as an abbreviation. AFAIK, an interpreter keeps a lookup table with variable bindings, and defun etc. will add an entry to that table saying "this variable is now bound to this function". So, if you ignore the name-binding part, you need only modify eval.
Evgenij Thorstensen
CC BY-SA 2.5
2010-08-28T03:19:32.773Z
2010-08-28T03:19:32.773Z
2020-06-17T09:38:08.363Z
Evgenij Thorstensen
<p><a href="https://stackoverflow.com/questions/3683388/given-the-the-following-lisp-eval-function-what-is-required-to-add-defmacro">This</a> shows macro expansion as a 'code template' to solve this problem. </p>

CC BY-SA 3.0
2012-12-06T07:51:15.980Z
link is not a good answer. Could you please expand this? Thanks.
Kaveh
CC BY-SA 3.0
2010-09-12T06:39:04.140Z
2012-12-07T12:35:20.600Z
2017-05-23T12:40:09.333Z
hawkeye
<p>In this <a href="http://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf" rel="noreferrer">paper</a> McCarthy sets out the following primitives: <code>QUOTE</code>, <code>CAR</code>, <code>CDR</code>, <code>CONS</code>, <code>EQUAL</code>, <code>ATOM</code>, <code>COND</code>, <code>LAMBDA</code> and <code>LABEL</code>. </p>

<p>He then sets up the following abbreviations: <code>T</code>, <code>NIL</code>, <code>DEFUN</code>, <code>NULL</code>, <code>CADR</code>, <code>LIST</code>, <code>AND</code>, <code>ALT</code>, and <code>SUBST</code>.</p>

<p>He rounds it up with an incredible definition of the <code>EVAL</code> function used in the reader. </p>

<p>Given the above set of LISP primitives, is it possible to extend the <code>EVAL</code> function to evaluate defmacro?</p>

CC BY-SA 3.0
2012-12-07T13:04:45.700Z
The book: Lisp in Small Pieces by Christian Queinnec presents an implementation of macros in Scheme that might be useful.
Dave Clarke
<functional-programming>
Given the following set of LISP primitives, is it possible to extend the eval function to evaluate defmacro?
hawkeye
# Given the following set of LISP primitives, is it possible to extend the eval function to evaluate defmacro?

(Asked by: username_0 on 2010-08-28)

In this [paper](http://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf) McCarthy sets out the following primitives: `QUOTE`, `CAR`, `CDR`, `CONS`, `EQUAL`, `ATOM`, `COND`, `LAMBDA` and `LABEL`.

He then sets up the following abbreviations: `T`, `NIL`, `DEFUN`, `NULL`, `CADR`, `LIST`, `AND`, `ALT`, and `SUBST`.

He rounds it up with an incredible definition of the `EVAL` function used in the reader.

Given the above set of LISP primitives, is it possible to extend the `EVAL` function to evaluate defmacro?

**Tags:** functional-programming
> **Comments:**
> **username_1**: The book: Lisp in Small Pieces by Christian Queinnec presents an implementation of macros in Scheme that might be useful.  

---

## 2 answers

### Answer by username_2 on 2010-08-28. Score: 2 | Accepted answer

Yes, in fact it's quite similar to evaluating `DEFUN`. Of course, in the paper `EVAL` has no rule for evaluating `DEFUN`, since it's treated as an abbreviation. From the definition of `DEFMACRO` in emacs LISP ([link](http://www.gnu.org/software/emacs/elisp/html_node/Defining-Macros.html)):

> Special Form: defmacro name argument-list body-forms...
>
> defmacro defines the symbol name as a macro that looks like this:
>
> `(macro lambda argument-list . body-forms)`

It's easier if we ignore the name of the macro and treat that as an abbreviation. Then we have simply to create the list `(macro lambda argument-list . body-forms)` and set `name` to be shorthand for that list, the same way a `(defun name (arguments) (body))` sets `name` as a shorthand for `(lambda (arguments) (body))`. As for evaluating a macro, that is also easy --- just pass the function inside the macro your arguments, but WITHOUT evaluating them first.

> **Comments:**
> **username_0**: Are you saying that defmacro would need to be implemented by both a modification to eval and a new primitve? (Being similar to defun)  
> **username_2**: The name binding part would need a new primitive, or however it's actually handled in eval --- since the paper treats the name-binding part of defun as an abbreviation. AFAIK, an interpreter keeps a lookup table with variable bindings, and defun etc. will add an entry to that table saying "this variable is now bound to this function". So, if you ignore the name-binding part, you need only modify eval.  

---

### Answer by username_0 on 2010-09-12. Score: 1

[This](https://stackoverflow.com/questions/3683388/given-the-the-following-lisp-eval-function-what-is-required-to-add-defmacro) shows macro expansion as a 'code template' to solve this problem.

> **Comments:**
> **username_3**: link is not a good answer. Could you please expand this? Thanks.  

---

