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

[Pascal J. Bourguignon]

Alan Mackenzie <acm@muc.de> writes:

> Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>> When you define a macro (defmacro m ...) then (m ...) can be put in any
>> form context, always.
>
> No.  When _you_ define a macro that might well be the case, but with me
> there are no guarantees.  


Which would lead me to label you a bad lisp programmer.


> I might want a macro to generate an arm of a
> cond form, for example.  Unlikely, but possible.

Just say No.  Use a function.



>> 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.
>
> Right.  We now get down to weighing up the difficulties a non-form macro
> may cause to its readers compared with the simplicity in the manner of
> expression which it would allow.

That's silly!   It is much simplier to use and to write a function
than a macro here!



>> 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!
>
> No, not silly - it all depends.  In the example which sparked off this
> intelligent discussion, avoiding non-conformity required inserting an
> artificial `progn'.  

Not always, as I showed later.  It's simplier to put progn always,
(works with 0, 1 or n forms), but you can special case.


> It's a matter of judgement which is the more
> difficult to read and understand.

Again, if you don't believe me, you could try to ask this question on
cll and see what happens.  There seems to be more lisp hackers and
guru on cll.  



>>> 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:
>
> Yes, I was wrong.  Sorry about that.  I'm beginning to see what you're
> getting at.
>
>> (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))))
>
> I still don't see the _reason_ for macros always to return forms.  

Because that's what they're defined to do. This is the fundamental
contract of a macro.  When you don't know anything about a macro, you
know that it will return code.


> I think you're saying that anything else is so unusual that it would create
> problems for somebody reading or debugging it.  Do you have an example of
> somewhere where a macro expanding to a non-form has lead to difficulty?
> I can't imagine anybody having difficulty understanding code like this:
>
> (cond
>  (try-incoming-call event)  ; expands to a full cond arm
>  (try-incoming-data-call event)
>  (try-battery-low-notification event)
>  (try-keyboard-press event)
>  ....
>  )
>
> , where all these event handler macros are defined centrally just once
> (and the comment is actually present in the source).

To begin with, the above cond form doesn't do what you think.  In the
best case it will signal a void-variable error, in the worst cases it
will return the value of event.



> I'll quite happily use a goto in C code if it makes the code easier to
> read and understand, though I've only done this 3 or 4 times in my entire
> career.  Similarly, I'd use a non-form macro if this were better.

Why stop at non-form macros?  Functions are perfect for that task!


> Usually it wouldn't be.


-- 
__Pascal Bourguignon__