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

[Tim X <timx@nospam.dev.null>]

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.
>
>
>> 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.
>
> 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?  If so, then it's up to you to say how it could have been
> done better, preferably submitting a patch.

I have found this an interesting discussion. I'm not sure which side of
the fence I fall on. 

Pascal/s assertion this is not good style has considerable merit. In
general, I think most do expect the result from a macro to be a form
that can be evaluated. 

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. 

To some extent, I would suggest this is one of those situations where
its ok to break the 'rules' provided you understand what the rules are
and you make it explicit in your comments/documentation that this is an
exception to the more common usage. In other words, Pascal is correect
that generally, good style would dictate that a macro returns a form
that can be evaluated. At the same time, if there is a situation where
using a macro in a way that isn't totally in keeping with good style
will result in code that is easier to understand/maintain, then it is
reasonable to do so provided this is documented and made clear. to some
extent, this follows Alan's example regarding goto. While good style
suggests you should avoid goto, there are situations where using goto is
the clearest and most maintainable solution, especially if avoiding its
use makes you jump through a whole lot of hoops to simply avoid
something that  someone has said is bad style. 

The whole notion of what is and is not good style is all about making
your code easier to understand and maintain. Style should not be viewed
as a set of rules that can never be broken (or change for that
matter). If anything, style guidelines are simply that, guidelines on
how to write your code to make it easier to understand and
maintain. When first programming, its a good idea to follow style
guidelines quite religiously. However, once you understand why the
guidelines are there and you become more experienced, you should
understand the difference between good and bad code and know when you
can break the rules.  

There is also a certain amount of personal taste/style that needs to be
considered. I've seen code that follows all recommended style guidelines
that is still almost impossible to understand and I've seen code that
appears to break many style guidelines that is very clear and easy to
follow. What I've found to be far more important is consistency. When
working with someone elses code, you get a feel for their style and way
of programming. Provided they are consistent, this isn't too bad
regardless of their adherence to common style guidelines. The worst is
code that sometimes adheres to guidelines and sometimes does not. My
view is to try and follow the 'accepted' style guidelines for the
language you are working in and document situations where you thought it
necessary to do something different that is outside normal style
conventions.

Tim
 

-- 
tcross (at) rapttech dot com dot au