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

[pjb@informatimago.com (Pascal J. Bourguignon)]

Alan Mackenzie <acm@muc.de> writes:

> Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> This is the problem!  Macros shouldn't return a _list_, they should
>> return a _form_.  If you write a macro that returns a list, or you use
>> it so that it returns a list, that is not a valid form, then it is not
>> good style, even if you catch up.
>
> Is that right?  I think you should be required to justify this assertion
> of "good style".  If that "good style" really is good style, then the
> whole of cc-langs.el (which uses intense macro magic to generate data
> structures with both compile-time and run-time behaviour) is attrocious
> style.  

If that was the case, yes, I would think so.  Macros are designed to
generate code, not other data.  If you are generating general data,
then using functions will be easier and clearer.

But cc-langs.el only defines four macros and they all generate
perfectly good lisp code.


> Fact is, though, it allows a simple tabular writing of constants
> which vary between C, C++, java, ....  Kudos to Martin Stjernholm, who
> wrote it.

Unfortunately, most of emacs lisp code is bad code.  Functions one
kilometer long, chained with one or more others one kilometer long.
Copy-and-pasted chunks instead of abstracting it away.  Etc.

I cannot say that I've read a significant percentage of it, but the
code I had to peek at in my 20 years of use of emacs, I cannot say I
was impressionned by its good quality...

Now of course, I had a peek at code that had bugs or missing features
in the first place.  Perhaps the good quality emacs lisp code I hadn't
a peek at because it worked well enough so I didn't need to.


>> Because it is a better style.  It avoids abusing the ifdef macro.
>
> Where does this notion of "abuse" come from?  What is its rationale?
> (This is a genuine question.)

The general contract of a macro is that it returns valid forms.

In all fairness,  ifdef does return valid forms, when provided valid
forms as argument.

(defmacro ifdef (expr &rest body)
   (and (eval expr) `(progn ,@body)))

(ifdef t (setq bar 2))
--> 2

It's only when provided invalid argu-ment that it returns an invalid
form:

(ifdef t ((setq bar 2)))
--> Debugger entered--Lisp error: (invalid-function (setq bar 2))


The fact that such a macro call embedded in another form building form
that processes it properly doesn't mean that it is not bad style: it
has to do something special to the result of ifdef to make it work.
If you extract that ifdef call to run it at the repl, it just cannot
work.


-- 
__Pascal Bourguignon__