Re: language design tradeoffs [macro mayhem] (Tom Lane)
Fri, 25 Sep 1992 02:41:42 GMT

          From comp.compilers

Related articles
language design tradeoffs (1992-09-07)
Re: language design tradeoffs [macro mayhem] (1992-09-24)
Re: language design tradeoffs [macro mayhem] (1992-09-25)
Re: language design tradeoffs [macro mayhem] (1992-09-26)
Bliss-11 macro facility [was macro mayhem] (long) (1992-09-27)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Tom Lane)
Organization: School of Computer Science, Carnegie Mellon
Date: Fri, 25 Sep 1992 02:41:42 GMT
Summary: semicolons suck
References: 92-09-048 92-09-164
Keywords: C, macros, comment (Mark Tillotson) writes:
>The point is that if SOME_MACRO's expansion is supposed to be a statement,...
>Thus the above I would always code as
>#define SOME_MACRO(A,B) \
> { xxx ; }
>#define SOME_MACRO(A,B) \
> { xxx ; yyy ; }

I'm surprised the moderator let this one slip past. This doesn't work any
better than the simpler version you rejected. Consider

if (condition)

This will cause an immediate barf due to the semicolon between the right
brace and the else. It's reasonably well known that the only way to make
a C statement macro look just like a subroutine call is

#define SOME_MACRO(A,B) \
do { xxx ; xxx; } while(0)

so that both the macro and a plain function call require a following
semicolon in all cases. (And I sure hope your compiler is smart about
constant if-conditions :-).)

The real reason that this is such a pain is not macros, it's C's
misbegotten syntax. If semicolons were statement separators (a la Pascal)
instead of statement terminators, things would work a lot more smoothly.

Incidentally, does anybody reading this list remember Bliss? IMHO no one
should be allowed to design a macro facility who hasn't studied the one
designed for Bliss/11 (and emulated in the various flavors of Bliss
written at DEC). It's amazing that twenty years after that design, we are
still putting up with half-assed macro facilities like C's.

regards, tom lane
[Mea culpa, though I note you can also write ``if(1) { stuff } else'' to
get a statement-like macros. Speaking of Bliss, it looks like it will be
possible to re-issue the classic "Design of an Optimizing Compiler" by Wulf
et al. Details forthcoming when known. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.