osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/06/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Wed, 6 Mar 85 Volume 4 : Issue 5
Today's Topics:
case ranges
----------------------------------------------------------------------
Date: Wed, Mar 6 1985, 9:00 EST
From: attunix!lr (Larry Rosler)
Subject: case ranges
To: attunix!hou2d!osd
[ At my request, Larry offered this comments on this very discussed
subject. -- Mod -- ]
Case ranges were added to the draft in September by a coterie of Pascal
freaks. They were removed in December, largely on my own instigation.
The following is my submission before the December meeting, which was
accepted:
1. The enhancement adds no capabilities
This is pure syntactic sugar, and has the same characteristics as
dietary sugar: It makes things taste better, and perhaps even look
better, and is only a little bit fattening. I think *adding* it at
this point violates two of the Committee's agreed guidelines: to
preserve the "spirit" of C (which is for a small clean language without
too many different ways of saying the same thing and without too much
burden on the compiler); and to add only enhancements of value proven
in existing implementations (in other words, to *invent* only where an
overriding need is perceived, such as for "volatile").
2. The enhancement adds clutter and implies new capabilities.
A new token, .., is added for only this purpose, complicating grammars
and parsers unduly. Now that the new token is there, though, the
pressure for more Pascal-like or Ada-like features such as subranges
will surely follow.
3. The enhancement promises more than it can deliver.
Inevitably, programmers will write stuff like
case 1 .. 10000:
and object when the compiler complains about "too many case constants."
Of course, we *could* require compilers to generate the appropriate
"if" code in such a situation. But then it would have to record an
erroneous
case 123:
also, requiring memory of all values or ranges in any case (pun
intended). What a lot of mechanism in the compiler for such little
benefit!
Even the logic required to generate good code is formidable. Consider
a switch with two cases:
case 1 .. 100:
/*...*/
case 1000:
After deciding not to construct a 1000-element jump table, the compiler
may well build a ladder of 101 comparisons, instead of the three
comparisons that a programmer would have written if this capability
were not available.
4. The enhancement encourages poor programming practice.
Inevitably, programmers will write stuff like
case 'a' .. 'z':
Of course, they could also write that into an "if" statement, but at
least there they could be encouraged to use the function "islower,"
which is provided specifically for that purpose.
5. The enhancement is syntactically ambiguous.
Input such as
case 1..5:
will be parsed as the two floating constants "1." followed by ".5 "!
The apparent cure for this is to replace the punctuator ".." by
something else, and syntactically the comma makes the most sense. But
semantically "1 , 5" seems to imply successive evaluation of the two
constant expressions (which is silly but consistent), not evaluation of
the range between them. Of course, a space could be required after the
first constant expression. [At the December meeting, someone proposed
binary --, which became moot when the whole thing was voted out. --
LR]
6. Summary
I keep hearing about how various compilers are up against the stops in
size already. And many useful new things, such as the "signed" keyword
and the "long double" type, have been added recently. All I can do is
ask again, "Hey, fellows, why are we choosing to do *this* one?" [I
hope it doesn't reappear at the March meeting, but one never knows. --
LR]
Larry Rosler
[ Chairman of the Language Subcommittee, ANSI X3J/11 ]
------------------------------
End of mod.std.c Digest - Wed, 6 Mar 85 11:03:11 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.