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

[Pascal J. Bourguignon]

Alan Mackenzie <acm@muc.de> writes:

> Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:
>> Alan Mackenzie wrote:
>
>>> Your notion of the correct use of macros seems to be a religious idea
>>> rather than one fully thought through.  You justify it with circular
>>> reasoning.  Whilst using a macro to generate an evalable form may be
>>> the most usual thing, there is no reason not to use it to produce
>>> other list structure.
>
>> Except that such macros can only be executed in a particular context
>> i.e.  they depend on something that cannot be expressed via their
>> argument list.
>
> Yes, many lisp structures can only be "executed" in particular contexts,
> `,@' for example, yet nobody slags them off for that.

This is different.  Why can't you see it?

,@ cannot be put outside of a ` context, never ever.

When you define a macro  (defmacro  m ...)
then (m ...) can be put in any form context, always.

Oops! Not when you write a macro that returns not a form.  You've made
an exception, and therefore a lot of complexity for the reader of your
code, and a lot of time lost for the debugger of your code.

Now instead of being able to use a macro at any place a form is
acceptable, we have to go read the source of the macro, and understand
whether it returns a form or data, and if it's the later, we have to
understand how to wrap it in some boilerplate, which was by the way
why macros where invented for in the first place, to avoid
boilerplate!!!  How silly!



>> At best that is poor style, and at worst it is poor engineering.
>
> That is so supercilious - you haven't even given an example of this
> phenomenom, discussing why it is poor style or poor engineering.  There's
> just this vague insinuation that you know better.

Yes, it seems that we have to spell it in all details.


> I will give an example, namely `c-lang-defconst' from cc-defs.el.  Are
> you going to assert that it is poor style, or even poor engineering,
> simply because it generates an internal data structure rather than an
> excutable form?  

You are plain wrong.  c-lang-defconst, as any other macro, generates
only executable lisp code:

(c-lang-defconst test t nil c "abc")
--> test

(macroexpand '(c-lang-defconst test t nil c "abc"))
--> (progn (c-define-lang-constant (quote test) (quote (((c-mode) . "abc") 
(t))) (quote (\83))))



> If so, then it's up to you to say how it could have been
> done better, preferably submitting a patch.

There's no need it already returns lisp CODE, as it should.

-- 
__Pascal Bourguignon__