🚀 go-pugleaf

andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon) writes:

>That's not my point.  My point is that true and false are *keywords*, not
>identifiers.  I want to know why.

If they are identifiers, they have to be defined somewhere. Where?

Pascal, for example, has the notion of "predefined identifiers". A
lot of the keywords in the language are not reserved. They are
predefined in a notional outer scope that encloses the entire program.
The number of reserved words is small. For better or worse, you can
provide your own definitions of the predefined identifiers.
	procedure p;
	var:
	    boolean, true, false: integer;
	begin
	    ...
	    false := true - boolean;
	    ...
	end;
Procedure p has local integer variables having the names of the
predefined boolean type and boolean constants.  In practice, Pascal
programmers tend not to usurp the predefined identifiers; it's
too confusing.

C does not have the notion of the enclosing scope or predefined
identifiers, and the decision was made not to introduce it into C++.

Without this sort of language change, the boolean type would have to be
defined in a standard header. How do we integrate what amounts to a
user-defined type into the language? That is, if boolean is a typedef,
we can't overload functions on it. If it is an enum, we don't get
implicit conversions to boolean. If for balance we disallow
implicit conversion from boolean, we break all existing code.

Further, what is the result type of the relational operators? If
it remains int, we get some ludicrous results:
	f(bool); // assume bool is not int
	f(int);
	...
	f(true) // calls f(bool)
	f(i>j)	// calls f(int)
If relational operators return the boolean type defined only in a
header, we have a pretty strange situation. Effectively, you have
to include that header in every program, and the situation is
nearly equivalent to having made reserved words.

The solution chosen was to build the boolean type into the language
with reserved words. We get the following good effects:
- a standard boolean type with standard spellings and values.
- the ability to overload reliably on the boolean type with predictable
    results.
- consistent results using boolean expressions. For example,
    f(i>j) will call f(bool) if that overloaded function is declared.
    You can test every boolean variable against 'true' or the value
    1 safely, which is not now the case. (Previously, a "boolean"
    variable could have a value not equal to either true or false.)
- automatic conversion among the numeric types to preserve most all
    existing code.
- the ability to use simply and reliably a one-bit boolean bitfield
    (no concerns about whether it is signed).

As with all design decisions, there are some drawbacks, mostly
in breaking some previously-valid code. But ANY solution adopted
would have broken SOME code. Adopting NO solution would have
left the current intolerable mess. The committee felt the
solution adopted was the best compromise, giving the most utility
and breaking the least amount of existing code.

One more thing: when the boolean type and constants are reserved
words, the compiler will tell you about misuses. If they could
be locally redefined, you could wind up with very subtle bugs
due to different definitions of the "same" type and "same"
constants in different parts of the program due to legacy code.

--
Steve Clamage, stephen.clamage@eng.sun.com