> > Huh? It produces the list ((setq bar 2)), assuming `ifdef'
> > acts like `and'
> Yes. And ((setq bar 2)) is not a valid form.
Of course it's valid - it's a list.
Perhaps you are trying to _evaluate_ it? What you should be evaluating is the
entire list that results from macroexpanding the defmacro body. That list is a
defun sexp in Alan's case, and there is no problem evaluating it.
> So it is not a good idea, not a good style...
> >> This is not a good property. It would be
> >> better to keep the contract of macros, that is they take code, and
> >> they produce code, that is, valid forms.
> > No idea what you are talking about.
> Yes, that's the problem.
> > It's simple, really: The code resulting from macroexpansion
> > is a list.
> No. CODE resulting from macroexpansion should be CODE. Not
> just a list. If you want to get random lists, then use functions,
> not macros.
The CODE resulting from the macroexpansion here is a _list_ whose car is
`defun'. It is a perfectly valid defun expression that can be evaluated without
error. It is CODE.
But the fact that the body of a defmacro should macroexpand to something that
can be evaluated without error is just background info. It is true for all
macros. It has nothing to do with the specific question Alan raised.
[And BTW, a sexp whose evaluation raises an error is not necessarily "invalid".
Validation requires validation against something (e.g. a syntax definition or a
specification). Lisp _syntax_ can be said to be invalid if it raises a read-time
error. But just because evaluating a sexp raises an error doesn't mean the
syntax is invalid. The list (bar) is not "invalid" if evaluating it raises the
error that bar's function definition is void.]