The D Programming Language (was: Still more new operators)

Doug Gwyn gwyn at brl-smoke.ARPA
Sun Feb 28 10:32:41 AEST 1988


In article <1988Feb25.202237.8688 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>Most machines cannot handle bits with anywhere near the efficiency
>with which they handle bytes; the appropriate base unit for efficient code
>*is* the byte.

Be careful; cause and effect are circular here.  I've been contacted by
more than one computer architect who wanted bit addressability but had
trouble convincing management to accept the slightly added expense because
they would observe that such a facility could not be exploited from popular
high-level languages.  In fact, I have many applications for bit arrays
and bit maps, and there is a severe performance penalty caused by lack of
hardware support for them (and high-level language access to such support).

My "short char" proposal did not REQUIRE bit addressability, but it did
allow it to be exploited if the implementor decided it was wanted.
(1 = sizeof(short char) <= sizeof(char).)  The other main implementation
would be to let a "short char" be an 8-bit byte and a normal "char" be
big enough to hold an entire textual unit (typically 16 bits in Japan).
Unfortunately not many committee members seem to be bit-map programmers...

>Please explain how avoiding superfluous words and keeping necessary ones
>short is consistent with changing {/} to begin/end for no particular reason.

A better reason for a change here is the problems cause by "dangling else"
and accidental ";" after the closing ")" of a while().  The idea that such
clauses control a single statement (which might be a compound statement)
makes C susceptible to such errors; using unique bracketing keywords would
be safer.
	while condition do ;-separated_statements done
	if condition then ;-separated_statements else ;-separated_statements fi
If would also be nice if such statements could return values (so ?: could
be dispensed with).  Better yet, adopt notation more supportive of concurrent
processing, such as Dijkstra's "guarded" commands.  Why not support the future?



More information about the Comp.lang.c mailing list