generalized switch

[karl at haddock]

inset!dave (Dave Lukes) writes:
>FLAME WARNING:

I have resisted the urge to make this a counter-flame.

>In article <86900006 at haddock> karl at haddock.UUCP writes:
>>I think one should be able to specify a list.  "case 1,4,10:" is neater than
>>"case 1: case 4: case 10:",
>
>Sure, but
>a)	is ``neatness'' the only criteria for a language feature??
>	What about usefulness??

I thought I explained why I thought it would be useful.  I'll try again below.

>b)	I never actually type large case lists,
>	I just type the constants then use an editor to insert
>	the ``case''s and the ``:''s.

That makes it easier to write, but it doesn't help the person who has to
read the code later.  "The editor can fix it" doesn't wash.

>>Better yet would be a list of ranges.  "case 'a' to 'z', 'A' to 'Z':"
>>requires 52 labels in the current syntax; this is where I normally rewrite
>>as if-else.  (Yes, I know that's better anyway because I can use the more
>>portable test isletter().  But there are other uses for range cases, and
>		 ^^^^^
>One would have thought that someone proposing extensions to C would know
>the correct name: isalpha().

Oops, a Freudian slip.  I've always thought it *should* have been called
isletter(), since I prefer to use "alpha" for "alphanumeric".

>Also: what ``other uses''?
>First you suggest a way of using something which you admit can be done better
>in other ways, then you suggest it has ``other uses'' without saying what
>they are!!

("The obvious is often left unsaid in favor of brevity" -- UPM.)  Okay, how
about "case '0' to '7'" for octal, or "case '0' to '9', 'A' to 'F'" for
uppercase hexadecimal?  (Yes, I know about isxdigit().  But "dc", for
example, reserves lowercase a-f for commands.)  If the isascii() function
goes away (as in X3J11), "case 0 to 0x7f" may be useful on ASCII systems.
Moreover (lest you flame about portability again), the switch value need not
be a character; I've written programs that wanted to test some integral
expression against one or more ranges.  (Sorry, I can't give enough context
to prove the program was useful.)

>>one could always "#define UPPER 'A' to 'I', 'J' to 'R', 'S' to 'Z'" for
>>EBCDIC systems, to retain portability.)  It should also be possible to
>                    ^^^^^^^^^^^^^^^^^^
>
>So that's your definition of ``portability''??
>``It works on ASCII and EBCDIC''.

Oh, come on.  You define it as "'A' to 'Z'" on ASCII systems, the mess above
on EBCDIC, and *whatever it needs to be* on other systems!  If your machine
has the brain-damaged collating sequence "AaBbCc...Zz", you have to define it
one letter at a time, but the *use* of the macro is portable.  (The macro
itself can be defined in a standard header file.)

>What happens when we introduce more (i.e. international) character sets??
>(-:Don't you care, or do you make your money by porting non-portable code? :-)

Assuming the character set is known at compile-time, you add the national
characters to the macro.  Otherwise, you use an "if".  I am *not* trying to
make "switch" into a glorified "if-else"; my proposal simply generalizes the
*constant comparisons* already handled by "switch".  *This is important*.

>>specify open-ended ranges, to allow things like "switch (strcmp(s, t)) {
>>case LT: ... case EQ: ... case GT: ... }" where LT and GT are #define'd as
>
>What's wrong with ``if''??

It requires a temporary variable.  Also, with "if" you make two of the three
tests, and the third case falls into "else"; with "switch" there is a nice
symmetry among the three cases, making it more readable.  (And it's likely
to be more efficient, if you care.)

>>intervals extending to minus and plus infinity.
>                                       ^^^^^^^^
>What is ``infinity''?
>This just seems like another encouragement to non-portability.

I don't understand your misunderstanding.  Assume a bracket notation with an
empty string denoting infinity.  "(a,b)" would match any value x such that
a < x && x < b.  "GT" would be defined as "(0,)" which (suppressing the upper
limit) would match any value x such that 0 < x.  What's nonportable?

>In summary:
>the suggested ``feature(s) are useful only if you intend to write non-
>portable code or save a few seconds typing and thought:
>we have enough problems already with non-portabilities in C code without
>adding more rope for turkeys to hang themselves with.

I've already answered the portability question.  As for saving time and
thought, that's what computers are for.  (Not to imply that one shouldn't
think, just that one shouldn't need to worry about details the compiler can
handle easily.)

>(-:(-: From what you have said, I think you should be forced to withdraw your
>.signature on the grounds of misrepresentation!
>:-):-):-):-):-):-):-):-):-):-)

Well, this discussion has very little to do with "lint", so there's not much
to misrepresent.  Anyway, it's not a .signature (file); I type my signature
and attribution-markings by hand (with assistance from an editor).  This is
partly because of some braindamaged software, and also because it helps me
resist the urge to include a cute quote or other such nonsense.  Also, I
like postscripts and footnotes to come after the signature.  I'm explaining
all this because I realize I'm contradicting the spirit of the last clause
in my previous paragraph.

>>*   "[a,b)" is the American notation for a half-open interval.  The European
>>    notation is "[a,b[", which would be even worse.
>
>Actually: the ``European'' (by no means universally European) notation is a

Well, I didn't mean to imply that all American/European sources follow this
convention, but there does seem to be a correlation, and I had to call them
something.

>LOT better: you don't have to stare at the equation trying to disambiguate
>different kinds of parenthesis (especially useful if your printer's
>character set is lousy, or the copy is badly handwritten),
>although I'm used to the ``American'' notation, which ``looks nicer''.

Don't have to disambiguate?  "[ ... [ ... ] ... ]" could denote either nested
brackets, or a left-closed and a right-closed interval.  In the C context,
when the string "[a,b[" has been scanned, the last character could be either
a terminator for the half-open interval, or the beginning of a subscript for
the array "b".  I guess one character of lookahead will resolve it, but it
may still be a problem for the user.  Anyway, unless and until the semantics
are agreed on, the syntax is a moot issue.

Now, in case you missed this point in my previous posting: this proposal can
be implemented in an upward compatible way, and it would eliminate the need
for most fall-through cases.  This *may* make it possible to phase out the
switch-break.  (I believe one of the authors of the language has acknowledged
that this was a botch.)

Karl W. Z. Heuer (ihnp4!ima!haddock!karl), The Walking Lint