[comp.lang.c] gotos and switch statements -- mild proposal

peter@sugar.UUCP (Peter da Silva) (08/21/87)

First of all, I'd like to say that anyone who doesn't like the current
semantics for switch statements is a wimp and a pascal fanatic, but since
I'm a nice guy I won't.

Secondly, all the suggestions you've come up with, both for getting rid of
the fall through and for the case are both irrelevent and dangerous. Yes,
dangerous... because they all lead to semantic ambiguity.

How about the following:

#define CASE(x) switch(x) {
#define OF(y) break; case y: y: ;
#define ESAC }

Now you can gross everyone out:

	CASE(c)
		OF(NEWLINE)
			blah blah blah;
		OF(TAB)
			goto SPACE;
		OF(SPACE)
			blah blah blah wow;
	ESAC

This shouldn't be inefficient if you have a halfway decent compiler.

Happy?
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

dant@tekla.TEK.COM (Dan Tilque;1893;92-789;LP=A;60HC) (08/23/87)

Peter da Silva writes:
>First of all, I'd like to say that anyone who doesn't like the current
>semantics for switch statements is a wimp and a pascal fanatic, but since
>I'm a nice guy I won't.

I'm glad I'm not a wimp, then.  (Actually, I like the current semantics
and am somewhat of an anti-gotoist, which is why I don't like the
alternatives proposed.)


>How about the following:
>
>#define CASE(x) switch(x) {
>#define OF(y) break; case y: y: ;
>#define ESAC }
>
>Now you can gross everyone out:

Including the compiler:

#define SPACE	' '
			/* or most other representations of space that
			   I can think of */

>	CASE(c)
>		OF(NEWLINE)
>			blah blah blah;
>		OF(TAB)
>			goto SPACE;
>		OF(SPACE)
>			blah blah blah wow;
>	ESAC

syntax error

>This shouldn't be inefficient if you have a halfway decent compiler.

A decent compiler is one that reads my mind so that it knows what my
code is supposed to do.  (However they still haven't gotten the bugs
out of the telepathy peripheral yet.)  A halfway decent one has more
explicit error messages than "syntax error".


>Happy?

Not until I get a decent compiler.


---
Dan Tilque
dant@tekla.tek.com  or dant@tekla.UUCP

karl@haddock.ISC.COM (Karl Heuer) (08/31/87)

In article <867@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>In article <929@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
>> In article <2182@zeus.TEK.COM> dant@tekla.UUCP (Dan Tilque) writes:
>>> [switch statements with auto-break breaks "case foo: case bar: ...;"]
>>> One possibility is separating them with commas: "case CR, LF:" which
>>> changes the meaning of the comma operator.
>
>> The comma operator is neither necessary nor useful in a constant
>> expression, and is explicitly disallowed by ANSI.
>
>[Not necessary, but possibly useful in that it might be constructed by a
>general-purpose macro]

Good point (even though I also fail to have an example at hand).  However, the
fact that it *is* currently forbidden means that the proposed syntax would be
fully compatible.  If ANSI later decides to legalize the comma operator in a
constant expression, they could still do so.  This would not conflict with the
proposal -- it would simply create another reason for the macro body to be
enclosed in parens.

In other words, "case CR, LF:" would have the new semantics, whereas
"case (CR, LF):" would be equivalent to "case LF:".  This is no more
problematic than the current overloading of comma for function calls.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint