Re: Is it possible for a macro to expand to nothing?

[Alan Mackenzie]

Jeff Clough <jeff@chaosphere.com> wrote:
> From: Alan Mackenzie <acm@muc.de>
> Date: Tue, 24 Nov 2009 16:39:20 +0000 (UTC)

>>> It comes directly from the definition of defmacro,

>>>    defmacro is a special form in `src/eval.c'.
>>>    (defmacro name arglist [docstring] [decl] body...)

>>>    Define name as a macro.  The actual definition looks like
>>>     (macro lambda arglist [docstring] [decl] body...).
>>>    When the macro is called, as in (name ARGS...), the function
>>>    (lambda arglist body...) is applied to the list ARGS... as it
>>>    appears in the expression, and the result should be a form to be
>>>    evaluated instead of the original.

>> Oh, come on!  That last sentence is a tutorial, motivating one,
>> expressed in the slightly loose, colloquial language of the hacker.
>> "a form to be evaluated" is here shorthand for something like "some
>> sort of atom or list structure which fits into the slot where the
>> invocation is housed"

> This is incorrect.  The term "form" has a very specific definition in
> Lisp.  It is a sexp that can be evaluated.  While I'm new to Lisp, I
> have been knee deep in books and documents for the last couple of weeks
> and everything (including the GNU Emacs Lisp Manual) presents macros as
> a way to generate *forms*, not just sexps.

You've missed my point.  The guy who wrote that definition of macro was,
in using the word "form", being somewhat, er, informal.  It was just
easier and more concise to say "form" than "form or (sometimes) other
appropriate list structure".

> If you have a macro that expands to (1 2 3), it's not going to break
> the world, but that macro isn't doing what every hacker is going to
> expect.  I'd call that a style problem.

Just like somebody occasionally using a goto in C.  Pascal was unable to
identify any specific problem a non-form macro expansion causes.

> If, for some reason, you absolutely have to use a macro to generate
> something like that above, at least have it expand to (list 1 2 3),
> that way the macro can still be evaluated and no one gets shafted.

And waste run time evaluating that list every time the defun runs?

> You get the behavior you want and the macro is still expanding to a
> valid form.

Nobody has yet given a valid reason why I should care about a macro
expansion being a "valid form" when the invoker is not going to evaluate
it.  cc-langs.el is chock full of such "invalid forms", yet they make the
maintenance of 7 complicated language modes tractable.

> Jeff

-- 
Alan Mackenzie (Nuremberg, Germany).