"arithmetic if":: Re: Feature for the next C version

[Steven Weintraub]

There have been a lot of articles about generalizing the case statement
to take expressions instead of constants on the case labels.  It should be
pointed out this feature is already there.  A case statement like this is
nothing more than an if-else if-else and any compiler will have to handle
such a case statement as such.  For example take the the following case
(no pun intended).

>  Some interesting ideas:
>	ifcase
>	  (a < b) code; code;
>	  (a == b) more(code);
>	  (a > b) still(more);
>	endcase;

is nothing more than :

      if (a < b)
	{ code ; code; }
      else if (a == b)
	{ more(code); }
      else if (a > b)
	{ still(more) }

In article <359 at twg-ap.UUCP>, dwh at twg-ap.UUCP (Dave Hamaker) writes:
> Applying the idea to switch gives:
> 
> 	switch (lhs) {
> 		case (rhs1): statements
> 		case (rhs2): statements
> 		 ...
> 		case (rhsN): statements
> 		default: statements
> 	}
> 
> where:
> 
> 	the "(lhs)" can be omitted;
> 	if present, "lhs" is an expression, or a *part* of one;
> 	("lhs" stands for "left-hand side");
> 
> 	the "rhs's" are also expressions, or *parts* of same;
> 	the parentheses around a "rhs" may be omitted if it does
> 		not contain a colon (":");
> 	("rhs" stands for "right-hand side");
> 
> 	neither the "lhs", nor any "rhs", may contain part of a:
> 		character constant,
> 		string constant,
> 		parenthesized sub-expression, or
> 		any other token
> 		(this could be relaxed, but it probably would
> 		 not be wise to do so).
> 

You say that the 'lhs' can be an incomplete expression or an complete
expression.

If the 'lhs' is an incomplete expression there are several problems. 
First it is extemely hard to write the syntax for a partial expression. 
Add to that all you are doing with the partial expression is holding a
pointer to a partial expression tree, which just has to completed at each
label anyway.  You might as well use an if-else if structure to do this
because you are not saving any code at cost of complicating the languge.
(I can see some tricks that could be used to generate this tree, but it
would greatly complicate the parser).

If the 'lhs' is a complete expression, then this statement is nothing
more than an extra if-else if structure.  If your worry is evaluation the
statement more than once, then you can always store the expression in a
temporary variable before (or in the first expression) of the if statement.

> 	switch (x) {
> 	case > 0:
> 		signum = 1;
> 		break;
> 	case 0:
> 		signum = 0;
> 		break;
> 	case < 0:
> 		signum = -1;
> 		break;
> 	}

becomes (assuming x to be a complicated expression) :

	temp = (x);
	if (temp > 0)             or if ((temp = (x)) > 0)
		signum = 1;
	else if (temp == 0) 
		signum = 0;
	else if (temp < 0) 
		signum = -1;

> and:
 
> 	switch (p < ) {
> 	case .1:
> 		...
> 	case .5:
> 		...
> 	default:
> 		...
> 	}

generates the same code as: 

       if (p == .1)
	       ...
       else if (p == .5)
	       ...
       else
	       ...

(again p can be place in a temporary if only one evaluation is desired)

The reason for a case statement is that with simple constants as the goals
an if-else if structure can go under a great deal of optimization.  Thus
the case statement is used to tell the compiler this can happen.  To widen
the case statement to take expressions or part of expression, you are adding
nothing more than the if-else if structure you already have at the cost of
losing the case structure, whose purpose is to tell the compiler it can
optimize (Otherwise you'd just have an if-else if).

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                             | O Lord,
...!cs.utexas.edu!oakhill!stevenw              |   let me talk gently,
Motorola Inc.  Austin, Texas                   | for I might have to eat my
(512) 891-3023 (office) (512) 453-6953 (home)  |   words tomorrow.
----------------------------------------------------------------------------