🚀 go-pugleaf

In article <1990Mar3.051019.13096@wolves.uucp> ggw@wolves.UUCP (Gregory G. Woodbury) writes:
>In article <16039@haddock.ima.isc.com> karl@ (Karl Heuer) writes:
>>Definitions.  Let `CX' be the language C with multiple valued cases, with
>>automatic break-switch at the end of each case block, and with the `break'
>>keyword denoting only the break-loop operation.  `CX with jumpcase' is CX
>>with an explicit keyword to denote the fall-through operations (overriding
>>the default behavior of an automatic break-switch).
>>
>>Claim 3.  CX with jumpcase would be better than C.
>
>ASSUMING that the multiple valued case is done "right", this is only
>moderately untrue.  If a person really wants to have this, it is a simple
>matter to put a front-end between your code and the C compiler to fix-up the
>syntax.

(a) Of course I'm assuming it's done right.  (b) Your statement is not
incompatible with mine; even if CXWJ could be implemented with a simple
preprocessor, it would still be a better% tool than C.  (c) Although one can
certainly write such a front end, it's not what I'd call simple.  It's easy
enough to implement automatic break-switch and explicit fall-through, but
fixing the overloaded keyword is nontrivial: it cannot be done in cpp or even
m4, unless you also change the loop syntax.  Note that
	while (...) { ... switch (...) { ... break; ... } }
is a valid CX fragment which breaks from the *loop*.


>>Claim 4.  CX itself would be better than CX with jumpcase (and hence better
>>than C); the extra keyword doesn't buy you enough to be worth adding, and it
>>would destroy the commutativity of case blocks, which is a useful property of
>>CX.
>
>Now here there is a severe problem.  This assumes (like most language
>arguments) that the programmer doesn't care about having to repeat (a
>potentially large) block of code in order to handle certain situations.

First, note that the extension (the addition of jumpcase to CX) solves only
one minor instance of the problem: the situation where the tail of one case is
the entirety of another.  If you have *two* cases that would both like to flow
into a third, you can only reduce one of them this way.  (This alone suggests
that fall-through is not the best way to solve the problem.)  It's also common
to have two cases with a common tail, but each needs to do some case-specific
code first, so neither can fall directly into the other (unless you test the
selector again, to skip over the head of the second case).

Checking my own code now, I find that I seem to use fall-through even less
often than goto.  I wouldn't be particularly bothered if, in those rare
instances when I need to have one case merge into the beginning of another, I
had to do the same thing& that I already have to do in the other situations
described above.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
________
% Modulo the disclaimer in my original article, that we're ignoring the fact
  that C already exists and is popular.
& This action may be repeated code, a subroutine call, or a goto, depending on
  the circumstances.