Boolean Operators Slighted in C

[Root Boy Jim]

> > In article <778 at bentley.UUCP> kwh at bentley.UUCP (KW Heuer) writes:
> > >Btw, you can't have *all* operators extended with "=".  How would you write
> > >"v = v < e;"?  (Not that it's useful.)
> > I think it's useful! ...
> ... [ deleted usual arguments for "op-assign" operators ]
> > James F. Carter            (213) 206-1306
> > UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024
> > UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc  ARPA:jimc at locus.UCLA.EDU
> 
> I think the quality of suggestions is degenerating rapidly.  This is a
> blatant type clash.  The "op-assign" interpretation of " <= " is
> self-contradictory nonsense.  The expression "v < e" has the
> (nonexistent) type "boolean", which implies that the destination is
> also boolean.  But that implies that you are using a boolean variable
> in the " < " relation, which would be nonsense if "bool" were a real type.

It would be nonsense IF boolean was a real type. There is no need to
make any distinction between them. It just gets in the way of coding.
APL, the most mathematical language, treats booleans exactly like C.
THERE IS NO SUCH THING AS A BOOLEAN DATA TYPE (to which Doug Gwyn will
reply `there is no such thing as an integer either :-). There may be
boolean OPERATORS, but their range and domain is integers.

> Instead of proposing yet another obfuscation of the language, why don't
> we discuss ways that we can simplify and improve the clarity of our
> coding style within the confines of the current language.  Better yet;
> quit talking, and do something about it.

Like what? Make it like Pascal :-)

> Griff Smith	AT&T (Bell Laboratories), Murray Hill
> Phone:		(201) 582-7736
> Internet:	ggs at ulysses.uucp
> UUCP:		ulysses!ggs  ( {allegra|ihnp4}!ulysses!ggs )

A couple of wild suggestions myself. In the tradition of APL one liners,

1) Chain Lvalues. I would like to be able to write:

	((n *= 10) += (c -= '0');		instead of
	c -= '0'; n *= 10; n += c;

2) More of the same. We all know about *++p. But what if I want to jump
	more than one element? I can't write *(p += 2); Or maybe I
	want to write `p = &(i += 5).

3) Exchange operator. This has probably been discussed before, so pardon
	me if I blunder into that pit. BUT, DMR has stated that one of
	the reasons that exponentiation was left out was because no
	(or few, if any) machine could do it inline, and therefore
	all the compiler would be doing is a function call anyway.
	By the same reasoning, exchange CAN be done efficiently by
	some machines, and the hack of a temporary variable and
	three assignments is a rather stale idiom. The three
	statement XOR trick avoids the temporary, at the expense
	of execution time and clarity.

4) Allow complex statements to be considered as expressions so that
	the comma operator can be used to avoid braces, as in

	if (e) x = y, return z;

5) Allow immediate constants. Currently, there is only one special
	case, that of a character array. One can say char *p = "string";
	and have the string squirreled away and the (magic) address
	stuffed into the pointer. Why not int *p = &5; where the
	integer five is whisked away and replaced by its address.
	Sure would eliminate a lot of housekeeping variables.

6) Eliminate arrays altogether! Well not exactly, but make all
	arrays vectored in all dimensions. This would show
	those quiche eaters what a real tough language C is :-).
	Array syntax would still be available of course, but would
	be translated into glorious pointer notation. And it wouldn't
	matter whether a variable was defined differently than it
	was declared (char x[] or char *x).

7) Negative Structure Offsets. After reading those last few, I don't
	expect anyone to take me seriously, but I am serious. These
	can be real useful for such things as communications, where
	each block is wrapped in another layer. We can even use the
	entry keyword for this (quick before ANSI takes it out :-).
	The advantage is real and twofold. First, all offsets are]
	known at compile time, and second, if the data is redone,
	only the code that uses it need be recompiled. This could
	be a win, especially if other programs used the same data.

8) Allow formal arguments to be declared AFTER the opening brace.
	This would allow prioritization of register variables.

Well that should be enuf to chew on. I'm not really seriously
suggesting munging the language. This is just a thought experiment
in the art of the possible. I'm not even going to mention such
radical changes as explicit end statements (gid rid of braces),
an #include MACRO from FILE, or using backquotes as explicit
substition characters (to allow concatenation of tokens, but it
would break strings with backquotes in them, be them ever so few)
as these would be major redefinitions. Now I will go on vacation
until all the flames die out :-).

	(Root Boy) Jim Cottrell		<rbj at cmr>
	"One man gathers what another man spills"