Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!ico!ism780c!news
From: news@ism780c.isc.com (News system)
Newsgroups: comp.lang.c
Subject: Re: "arithmetic if":: Re: Feature for the next C version
Message-ID: <30985@ism780c.isc.com>
Date: 3 Aug 89 20:44:43 GMT
References: <55480@tut.cis.ohio-state.edu> <1989Jul20.152935.14872@utzoo.uucp> <67@motto.UUCP> <18764@mimsy.UUCP> <1389@crdgw1.crd.ge.com> <8515@batcomputer.tn.cornell.edu> <1429@crdgw1.crd.ge.com> <1287@atanasoff.cs.iastate.edu>
Reply-To: marv@ism780.UUCP (Marvin Rubenstein)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 66

In article <1287@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes:
>>  Some interesting ideas:
>>	ifcase
>>	  (a < b) code; code;
>>	  (a == b) more(code);
>>	  (a > b) still(more);
>>	endcase;

>    Imagine extending the concept:
>
>       if (expr) s1; [else s2;]
>
>    to:
>
>       negative (expr) s1; [zero s2;] [positive s3;]
>
> 
>    I can hear the C-purists screaming in agony :-)
>
>John Hascall

As a language designer, I dislike this idea.  I also dislike the C construct
'if (expr) s1; [ else s2;]' (borrowed from algol) for two reasons.  First it
requires the introduction of begin-end (sometimes spelled, {} ).  This is
required so that s1 and s2 can be more than a single statement.  Second and
more important, it causes the dangling 'else' problem (if s1 is an 'if'
statement, which 'if' does the 'else' go with?).

The proposal exacerbates the dangling 'else' problem.  It gives us dangling
'zero' and 'positive', it introduces additional keywords, and it is less
general than the 'ifcase' construct quoted above.  Also the 'ifcase'
construct eliminates the need for begin-end.

Note that it is not hard (as compiler writing goes) to build a compiler which
when given:

	  if
	   ((expr)<0) <statement-list>
	   ((expr)=0) <statement-list>
	   ((expr)>0) <statement-list>
	  fi

Would produce exact same code as for above proposal; assuming each <expr> is
the same and has no side effects.  And the above construct extends naturally
to cover things like IEEE floating arithmetic e.g.

	  if
	   ((expr) = INFINITY)  <statement-list>
	   ((expr) = -INFINITY) <statement-list>
	   ((expr)<0) <statement-list>
	   ((expr)=0) <statement-list>
	   ((expr)>0) <statement-list>
	   else       <statement-list>
	  fi

The 'else' case would be executed when the evaluation of <expr> producdes
a NAN.

I guess I am a C purist.  I feel that adding warts to a toad will not make
it more beautiful.  Why not just leave C as it is?  At least it is now a
reasonably well defined and well documented language.  And it is quite
useful.

Now lets hear the flames from the C-ophiles :-)

    Marv Rubinstein