From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: New C++ type: boole
Organization: Texas Instruments Inc
Date: Mon, 27 Jul 1992 14:45:23 GMT

In <DOUGM.92Jul26151240@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:

>	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.

This is an incredibly poor choice of symbology.  If it is to be a
discrete boolean type, it would be better to not include either '0' or
'1'.  Just use 'f,t', 'n,y', or 'off, on' in a boolean context and say
that that's a boolean.

>	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.

Sounds like you just broke a big part of the world to me.  This is
also highly non-orthoganal, in that you have a quantity ('ptr') which
you say you are going to issue a warning on in a logical context, but
you can do a simple negation and it becomes acceptable.  It should
work the same way for 'ptr' and '!ptr'; either both should be legal or
both should give warnings.  If you make both give warnings, you have
once again broken a big part of the world.  Hence, neither should give
warnings. 

>	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.

Not really.  You appear not to understand that what people are doing
is using a 'non-boolean' method of altering a 'boolean'.  If I have a
flag that is false and I increment it twice, I expect it to be true.
If you examine that Sun code more closely, I suspect that you will
find that it follows some other code that also checks for errors (and
increments the error flag if it finds one) or it was written by
someone working on a machine with a compiler for which post-increment
was faster than assignment.

If you want to have this, use either the logical negation operator '!'
or the complement operator '~' to do it.

>	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.

Belief isn't good enough.  Have you LOOKED at the amount of work
required to make this work with the rest of the language?

>	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.

Congratulations, you have once again apparently broken a large part of
teh world, since there is a lot of code out there that assumes all
these libraries are going to return 'int'.  In addition, if you want
to hack on the language, you need to GET concerned with library
standardization.  When you want to change a language (as opposed to
designing your own), you have to take into account the impact of your
proposed changes to ALL PARTS OF THE LANGUAGE.

>	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.

It would seem that most peoples' are.

>	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.

Pretty much EVERYONE would have to do this.  So what's the point?

>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.

It would appear not.  You seem more interested in protecting your ego
and flaming critics than you do in listening to constructive
criticism. 

You appear to want to define a new language that looks something like
C/C++ but doesn't act much like it unless this 'extension' is
disabled.  Which it would have to be for most code that exists.

[I didn't read the original proposal, I'm afraid, but what I see of it
here looks bad.]

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
From: wright@hpcc01.corp.hp.com (Jeff Wright)
Date: Fri, 24 Jul 1992 19:45:52 GMT
Subject: Re: Programming guidelines: naming of data members?
Organization: HP IC Business Div Palo Alto