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:
>> Tim X <timx@nospam.dev.null> writes:
>
>>> On the other hand, Alan's arguments also have merit. If a macro can be
>>> useful in generating something other than a form that can be
>>> evaluated, such as a data structure and can do so in a way that is
>>> cleaner/simpler or just easier to understand than doing the same using
>>> functions, then it would make sense. His examples from the C modes
>>> seem to be a case in point.
>
>
>> Perhaps Alan's problem with functions comes from the confusion between
>> backquote and macros.  Since backquote (and , and ,@) are often used in
>> macros, some people believe they can be used only in macros, and that
>> they ARE what macros are.
>
> Er, do I actually have a problem with functions?  But no, I don't suffer
> that particular confusion between backquotes and macros, and have indeed
> used backquote when there hasn't been a macro within zeptoparsecs.
>
>> Far from it!  I don't know any language more orthogonal than lisp.
>
> Maybe not, but even lisp only gets to about 89 degrees.  It is missing an
> operator which does the same as ,@ outside backquote.  This is one of the
> lacks which makes it so difficult to write an equivalent of C's #if.

Yes, emacs lisp is missing reader macros.  In Common Lisp there's #+,
#- and #., and reader macros may return 0 object.


>> Backquote can be used in a function to build a s-exp (including part of
>> a form) as it can be used anywhere.
>
>> Therefore it is really not easier to use macros to generate parts of a
>> form than function.
>
> It is if you need "side effects", like c-lang-defconst and friends do.

Well, I'm not sure about emacs, but in the case of Common Lisp, you
have to be careful with side effects in macros, because it is not
specified how many times, and when, macro functions are called.

I'd say that with emacs you at least have the same problem if you load
and/or eval the contents of a file and then you byte-compile it, the
macros may be executed twice.

So that's one more difficulty you have to cater to with macros, that
you don't have with functions.


> [ Stuff read and appreciated.  My brain's not up to it so early in the
> morning].
>
>> If you wanted to use macros, in addition to the complexity of having
>> to use macroexpand to use it, you would have the difficulty of passing
>> the parameters, since a macro gets it's parameters from the source
>> form.  In the case of a function, you have the choice to quote or not
>> to quote the parameters, with macros they're always quoted for you.
>
> In the case of a function, you've GOT to quote, which can get very
> tedious in some circumstances.  That's probably the reason that Martin
> Stjernholm wrote c-lang-const etc. as macros.

Read again my example, I hadn't to quote the arguments to the function
because they weren't the literal arguments, but variables containing
the arguments, because the function was called from another function
or macro (macro in this case) who got them as parameter.

If you had to forward arguments to a macro, it would be much more
complicated. Then you would have to use macroexpand.  

-- 
__Pascal Bourguignon__