Re: obarray

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Yes, this much I understood, only it was hard to
> visualize in practice. So: the macro accept code *as
> arguments* (code that isn't evaluated) and transforms
> that code?

Exactly.  Although, let's better say it accepts expressions (it must not
be valid code as such), and transforms them into code without evaluating
them before.  For example:

       (dolist (i '(1 2 3))
                (message "%s" i))

The expressions (i '(1 2 3)) and (message "%s" i) are "arguments" to the
macro `dolist' in this call.  These are not evaluated, but transformed
into code.  You can see the transformed code with `macroexpand':

 (macroexpand '(dolist (i '(1 2 3))
                (message "%s" i)))

==>                

(cl--block-wrapper
 (catch '--cl-block-nil--
   (let
       ((--dolist-tail--
         '(1 2 3))
        i)
     (while --dolist-tail--
       (setq i
             (car --dolist-tail--))
       (message "%s" i)
       (setq --dolist-tail--
             (cdr --dolist-tail--))))))

A macro call with the above arguments will first generate (expand) the
code to an expression like that, and will then execute it.

In the above case, the macro expanded to code that introduces another
variable, --cl-block-nil--.  In our case, it's an interned (!) symbol.
You can see why this isn't good when you try to evaluate

(dolist (--dolist-tail-- '(1 2 3))
  (message "%s" i))

Now you by coincidence use the symbol in the expression to be
transformed that the macro introduces as new variable.  They collide,
and

(dolist (--dolist-tail-- '(1 2 3))
  (message "%s" i))

doesn't work when evaluated.  So, it would be more correct to use an
uninterned symbol instead of '--dolist-tail--, then such a collision
could never happen.  They used a quite exotic name for the symbol so
such a collision is unlikely, but strictly speaking, the implementation
of dolist is not correct.

Defining `dolist' correctly is a good exercise for learning how to write
macros.


Regards,

Michael.