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