From: utzoo!decvax!harpo!eagle!mhuxt!mhuxa!mhuxh!mhuxm!pyuxjj!pyuxll!jse
Newsgroups: net.unix-wizards,net.lang
Title: if statement ambiguity and the C preprocessor
Article-I.D.: pyuxll.282
Posted: Wed Sep 22 16:25:06 1982
Received: Thu Sep 23 04:39:38 1982


There is a problem with the kind of syntax used for if statements
in languages like C that is well known,
but nobody seems to complain about it too much.  
The problem is the ambiguity of which if an else belongs to.
The standard way of dealing with this is to say that an else
matches with the closest unmatched if.
	I always thought the better way of dealing with the problem
was to use if..then..[else]..fi instead.

Like many C programmers, I have grown quite used to this, and it
rarely causes any problems.  I like C in general, and I also
like not having to type fi.

The following situation is one in which it does bother me occasionally.
Suppose I want to define a macro which is an if statement without an else,
e.g.:

	#define mymacro	if (e1) s1

Now I want to use it somewhere, e.g.:

	if (e2)
		mymacro;
	else
		s2;

Well, this will not do what I probably wanted it to do,
namely associate the else with "if (e2)".
You might think that the solution is to try

	#define	mymacro	{ if (e1) s1; }

but that won't help either, because then the else won't be associated
with any if statement at all because of the semicolon before the else.

Questions: Is there some way to do this cleanly in C?
Why do languages continue to be designed with this syntactical
ambiguity?  Does it bother anyone else?  (To be fair, it doesn't
really bother me that much; I just don't try to use that construction).

	Jan Edler		pyuxll!jse	(btl piscataway)
				cmcl2!edler	(nyu)