From: dougm@titan.cs.rice.edu (Doug Moore)
Subject: Re: New C++ type: boole
Organization: Rice University Computer Science, Houston, Texas
Date: Sun, 26 Jul 1992 21:12:40 GMT

>>>>> On Sun, 26 Jul 1992 17:59:44 GMT, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) said:

	Dougm> P. S.  The latest draft of the proposal follows.
	Dougm> Constructive feedback is still welcome.  Shall I
	Dougm> officialize it and send it off to our beloved standards
	Dougm> committee?

	Fergus> Um, well, no.  Without intending to insult anyone, I
	Fergus> have to say that this proposal has so many flaws that
	Fergus> I don't know where to start. I couldn't be bothered
	Fergus> replying the first time, reasoning that someone was
	Fergus> bound to shoot it down soon enough anyway :-). But
	Fergus> before you send it off to the committee, at the very
	Fergus> least it needs some substantial improvements. Oh well,
	Fergus> here goes...

I won't take offense to your criticisms if you won't take offense when
I find them largely groundless.  Generally I find that the "so many
flaws" you refer to boil down to just one: C++ with any builtin
boolean type is flawed.  So naturally, you wouldn't like this proposal
either.

	Dougm>  programming idiom.  No proposed change to C++ can invalidate such
	Dougm>  expressions.        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	Fergus> ^^^^^^^^^^^^^
	Fergus> To most of us, that point is enough to convince us
	Fergus> that any attempt to add a boolean type to C++ is not
	Fergus> going to buy us enough that it is worth the effort
	Fergus> required to implement it.

So you don't want a boolean type.  Fine.  That is a matter of taste
and programming style, not a technical criticism.  To make one of
those, you have to argue that the proposed changes *will* "invalidate
such expressions".

	Fergus> 0t ??
	Fergus> This is woefully counter-intuitive. If you *have* to
	Fergus> have syntactically special values for true and false,
	Fergus> at least make it "1t".  (What's wrong with
	Fergus> "boole::false" and "boole::true" or some such?)  C++
	Fergus> is hard enough on beginners already, let's not add yet
	Fergus> another complicated and counter-intuitive syntactic
	Fergus> construct.

You claim 1t is more intuitive, but that is only because you think
that 1==true and 0==false are the natural way of thinking about
things.  They are not.  The beginners about whom you are concerned are
the ones who write

#define TRUE (1==1)
#define FALSE (0==1)

because they're not entirely sure that *their* C compiler produces 1
and 0 for truth values.  Programmers in Fortran have no conceptual
problem with .TRUE.  and programmers in Scheme have no trouble with
#t.  C++ programmers are just as capable of understanding 0t.

	Fergus> So you are going to give me a warning if I write

	Fergus> 	if (ptr) ...

	Fergus> but not if I write

	Fergus> 	if (!ptr) ...   ?

Yes, I am.

	Fergus> Sounds very counter-intuitive to me.

Well, I am sorry for that.  To many people, the idea that a pointer to
that character over there is also "true" and a pointer to no character
at all is also "false" is counter-intuitive.  I don't claim to have
data to support the assertion that one set of intuitions is more
common than another.

I suggest that you disable boolean warnings.

	Fergus> Can you stick to proposing one extension at a time, please?

I can, but I view this as a single extension.  So I think I'll keep it
as one.

	Fergus> The merit of &&=, ||= is very debateable, as is the
	Fergus> idea of introducing a new idiom ++ for toggling
	Fergus> logical values. (Why not just use "negate(t)" instead
	Fergus> of "t++"? The former seems to convey the meaning much
	Fergus> more clearly.)

To call a thing "debateable" is not quite as useful as actually
debating it.  The idiom ++ for toggling logical values is not new.
Here, for example, is an example taken from the Sun manual page for
the getopt C library function:

               while ((c = getopt(argc, argv, "abo:")) != -1)
                    switch (c) {
                    case 'a':
                         if (bflg)
                              errflg++;
                         else
                              aflg++;
                         break;
                    case 'b':
                         if (aflg)
                              errflg++;
                         else
                              bproc ();
                         break;
                    case 'o':
                         ofile = optarg;
                         break;
                    case '?':
                         errflg++;
                    }
               if (errflg) {
                    (void)fprintf(stderr, "usage: . . . ");
                    exit (2);
               }

Is negate(t) clearer?  I don't know.  Is rem(a,b) clearer than a%b?
Is deref(p) clearer than *p?  I only know that plenty of people
already use '++' for logical negation.

	Fergus> Also you are asking for a lot of work for the compiler-writers.

That's their job.  But if they are short of time, they can stop
working on exception handling (try, etc.) because I don't have any use
for it, I find it counterintuitive, and I find that it might cause all
my programs that use "try" as a variable name to break. :-)

Besides, I do not believe that the work required would be exceptional.

	Fergus> One more comment: what about all the standard library
	Fergus> routines?  Are you going to change isdigit() etc. to
	Fergus> return booles?

Were I concerned with library standardization, which I am not, I would
suggest that routines that return only true and false values, like
isdigit, should return booles, and that routines that return integers
that indicate ordering, like strcmp, would not change.

	Fergus> Can you imagine all the conflicts you are going to
	Fergus> get, whichever way you decide to go?

I am confident that your imagination is more vivid than mine in that
regard.

	Fergus> I strongly suspect that even if this proposal was
	Fergus> accepted and implemented, programmers would just
	Fergus> disable the warnings rather than bother fixing all
	Fergus> their old code.

Some would.  You would.  And how would you suffer damage?  You would
have to add -fdisable-boole-warnings to your makefile somewhere.

There are several reactions to my proposal that I can respect.  They
are:

1.  I don't like it, because I like to mix types as I now can in C.
2.  I don't like it, because it is fundamentally flawed.
3.  I don't like it, becuase <some aesthetic issue about 0t or somesuch>.
4.  It is flawed, but fixable; here's how.
5.  Such insight!  We'll get it in our compiler right away!

You claim to belong in category 2.  You belong in category 1.  I sense
that the substantial improvements you would have me make would be in
the nature of shortening the proposal.  Possibly to a single blank
character.

I can accept that some people don't want change, or don't want a
boolean type in particular.  If you hold that opinion, express it and
I won't argue with you.  But don't state that a proposal is full of
holes (i.e. ambiguities, self-contradictions, contradictions with the
current standard, etc.) unless you are willing to present them.

*Constructive* feedback is still welcome.

Doug Moore
(dougm@cs.rice.edu)