Boolean Operators Slighted in C

[KW Heuer]

In article <268 at valid.UUCP> valid!sbs (Steven Brian McKechnie Sargent) writes:
>A Boolean data type distinct from integers clutters the language

I disagree.  I think an explicit boolean datatype *simplifies* the language.
The way I see it, booleans already exist internally.

>and removes handy idioms like
>	foo[x == 0] = bar;

I'd guess that would still be legal, just like "float x = 0;".  The compiler
could know how to convert bool to int.  At worst, you could write "(int)" to
force it.  (I prefer to write "foo[x==0 ? 1 : 0] = bar;", which is no less
efficient since that's how the compiler converts the "internal bool" into an
int anyway.)

>(Vide the "enum" type, which doesn't participate in address arithemtic
>either.)

I'd like to see a syntax to declare an array which is subscripted by an enum
instead of an int.  Having to use a cast is a pain.  (In the example above,
you didn't mean to imply that foo[] would only be indexed by bool, did you?
If so, cancel my comment about "?:".)

>Arguments that boolean functions make for more efficient implementations
>are pretty puny:
>> o  A function returning a bool could be implemented on some machines by
>>    setting the condition codes instead of storing a full integer value in
>>    the return register.
>If the caller wants to use the result of the function as a value, rather
>than as input to a branching decision, then it must write branches anyway
>to set the value appropriately.  Result: bigger slower code.

No slower than putting the same branch in the called function!  Anyway, I
suspect that most boolean functions *are* used in a boolean context rather
than an integer context.

>> >o  Multiple flag variables with local scope and no address operator (e.g.
>> >   variables declared "register bool") could be packed into a single word.
>Last I checked, (flags&BOOLEAN_VALUE_OF_MERIT) did what you want.  Packing
>and unpacking don't come for free, in space or time.

"Packing and unpacking" don't need to be done except in an integer context.
The boolean operations are single instructions.  As for (f&CONST), I'd just
like to reduce the ugliness.  Cf. bitfields.

>**
>Builtin functions confuse language implementation with programming
>environment implementation; C lives in enough different environments
>that this is just plain bad planning.  "Inline functions," a la those
>of C++, are another matter entirely (although they have been mentioned
>repeatedly in discussions of builtin functions).  The benefits that
>inline functions offer over CPP macros are: simpler cleaner syntax,
>more flexibility because they admit arbitrary control structure within,
>and avoidance of horrible botches like putchar(*p++).  The disadvantage,
>at least in my mind, is uncertainty as to what happens to the free
>variables of an inline function.  Are they bound lexically where the
>inline is declared, or are they bound at the point where the inline is
>used, assuming the nearest enclosing scope?  Consider: [example deleted]

I think I agree about builtins.  There's no problem with "putchar(*p++)",
I believe you're thinking of "putc(c, *fp++)".  It's my understanding that
"inline" has the same semantics as "static", but is a hint to the compiler;
your example may force the compiler to forgo the inline expansion.

>**
>New operators like "< =" ...

I originally mentioned this just to point out that there exist operators
which cannot be extended with "op=".  The one person who thought it would be
useful was confusing it with "MAX=".  (Mark Brader has pointed out that B,
a sibling* language to C, actually has these operators (spelled "=<", etc.)
for completeness.  I still think they're useless.)

>**
>... I have yet to see a feature proposed that fixes a crippling problem of
>the language.

Do you know of any "crippling problems" that require new features?

Anyway, it's useful to keep in mind that much of what is said here (by me,
certainly) is not a "proposal", but just an idea to be tossed around in the
think tank.  As an example of such, here's an idea which I do *not* want to
see in the next ANSI draft.

In stepping through a linked list (recursive structure), one often writes
"p=p->next;".  The logic that creates "+=" would suggest that this could be
written "p->=next".  However, "->" is not really an operator since its right
"argument" is not an expression.  An alternate notation would be "p=>next",
where "=>" is a sort of overstrike between "->" and "=".  (I actually had a
case once where this would've been useful -- "p" was an expression with side
effects!)

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
*The original B was a parent language of C; modern B is a sibling.