home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11576 < prev    next >
Encoding:
Text File  |  1992-07-26  |  7.3 KB  |  189 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!rice!news.rice.edu!dougm
  3. From: dougm@titan.cs.rice.edu (Doug Moore)
  4. Subject: Re: New C++ type: boole
  5. Message-ID: <DOUGM.92Jul26151240@titan.cs.rice.edu>
  6. Sender: news@rice.edu (News)
  7. Organization: Rice University Computer Science, Houston, Texas
  8. Date: Sun, 26 Jul 1992 21:12:40 GMT
  9. Lines: 178
  10.  
  11. >>>>> On Sun, 26 Jul 1992 17:59:44 GMT, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) said:
  12.  
  13.     Dougm> P. S.  The latest draft of the proposal follows.
  14.     Dougm> Constructive feedback is still welcome.  Shall I
  15.     Dougm> officialize it and send it off to our beloved standards
  16.     Dougm> committee?
  17.  
  18.     Fergus> Um, well, no.  Without intending to insult anyone, I
  19.     Fergus> have to say that this proposal has so many flaws that
  20.     Fergus> I don't know where to start. I couldn't be bothered
  21.     Fergus> replying the first time, reasoning that someone was
  22.     Fergus> bound to shoot it down soon enough anyway :-). But
  23.     Fergus> before you send it off to the committee, at the very
  24.     Fergus> least it needs some substantial improvements. Oh well,
  25.     Fergus> here goes...
  26.  
  27. I won't take offense to your criticisms if you won't take offense when
  28. I find them largely groundless.  Generally I find that the "so many
  29. flaws" you refer to boil down to just one: C++ with any builtin
  30. boolean type is flawed.  So naturally, you wouldn't like this proposal
  31. either.
  32.  
  33.     Dougm>  programming idiom.  No proposed change to C++ can invalidate such
  34.     Dougm>  expressions.        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  35.     Fergus> ^^^^^^^^^^^^^
  36.     Fergus> To most of us, that point is enough to convince us
  37.     Fergus> that any attempt to add a boolean type to C++ is not
  38.     Fergus> going to buy us enough that it is worth the effort
  39.     Fergus> required to implement it.
  40.  
  41. So you don't want a boolean type.  Fine.  That is a matter of taste
  42. and programming style, not a technical criticism.  To make one of
  43. those, you have to argue that the proposed changes *will* "invalidate
  44. such expressions".
  45.  
  46.     Fergus> 0t ??
  47.     Fergus> This is woefully counter-intuitive. If you *have* to
  48.     Fergus> have syntactically special values for true and false,
  49.     Fergus> at least make it "1t".  (What's wrong with
  50.     Fergus> "boole::false" and "boole::true" or some such?)  C++
  51.     Fergus> is hard enough on beginners already, let's not add yet
  52.     Fergus> another complicated and counter-intuitive syntactic
  53.     Fergus> construct.
  54.  
  55. You claim 1t is more intuitive, but that is only because you think
  56. that 1==true and 0==false are the natural way of thinking about
  57. things.  They are not.  The beginners about whom you are concerned are
  58. the ones who write
  59.  
  60. #define TRUE (1==1)
  61. #define FALSE (0==1)
  62.  
  63. because they're not entirely sure that *their* C compiler produces 1
  64. and 0 for truth values.  Programmers in Fortran have no conceptual
  65. problem with .TRUE.  and programmers in Scheme have no trouble with
  66. #t.  C++ programmers are just as capable of understanding 0t.
  67.  
  68.     Fergus> So you are going to give me a warning if I write
  69.  
  70.     Fergus>     if (ptr) ...
  71.  
  72.     Fergus> but not if I write
  73.  
  74.     Fergus>     if (!ptr) ...   ?
  75.  
  76. Yes, I am.
  77.  
  78.     Fergus> Sounds very counter-intuitive to me.
  79.  
  80. Well, I am sorry for that.  To many people, the idea that a pointer to
  81. that character over there is also "true" and a pointer to no character
  82. at all is also "false" is counter-intuitive.  I don't claim to have
  83. data to support the assertion that one set of intuitions is more
  84. common than another.
  85.  
  86. I suggest that you disable boolean warnings.
  87.  
  88.     Fergus> Can you stick to proposing one extension at a time, please?
  89.  
  90. I can, but I view this as a single extension.  So I think I'll keep it
  91. as one.
  92.  
  93.     Fergus> The merit of &&=, ||= is very debateable, as is the
  94.     Fergus> idea of introducing a new idiom ++ for toggling
  95.     Fergus> logical values. (Why not just use "negate(t)" instead
  96.     Fergus> of "t++"? The former seems to convey the meaning much
  97.     Fergus> more clearly.)
  98.  
  99. To call a thing "debateable" is not quite as useful as actually
  100. debating it.  The idiom ++ for toggling logical values is not new.
  101. Here, for example, is an example taken from the Sun manual page for
  102. the getopt C library function:
  103.  
  104.                while ((c = getopt(argc, argv, "abo:")) != -1)
  105.                     switch (c) {
  106.                     case 'a':
  107.                          if (bflg)
  108.                               errflg++;
  109.                          else
  110.                               aflg++;
  111.                          break;
  112.                     case 'b':
  113.                          if (aflg)
  114.                               errflg++;
  115.                          else
  116.                               bproc ();
  117.                          break;
  118.                     case 'o':
  119.                          ofile = optarg;
  120.                          break;
  121.                     case '?':
  122.                          errflg++;
  123.                     }
  124.                if (errflg) {
  125.                     (void)fprintf(stderr, "usage: . . . ");
  126.                     exit (2);
  127.                }
  128.  
  129. Is negate(t) clearer?  I don't know.  Is rem(a,b) clearer than a%b?
  130. Is deref(p) clearer than *p?  I only know that plenty of people
  131. already use '++' for logical negation.
  132.  
  133.     Fergus> Also you are asking for a lot of work for the compiler-writers.
  134.  
  135. That's their job.  But if they are short of time, they can stop
  136. working on exception handling (try, etc.) because I don't have any use
  137. for it, I find it counterintuitive, and I find that it might cause all
  138. my programs that use "try" as a variable name to break. :-)
  139.  
  140. Besides, I do not believe that the work required would be exceptional.
  141.  
  142.     Fergus> One more comment: what about all the standard library
  143.     Fergus> routines?  Are you going to change isdigit() etc. to
  144.     Fergus> return booles?
  145.  
  146. Were I concerned with library standardization, which I am not, I would
  147. suggest that routines that return only true and false values, like
  148. isdigit, should return booles, and that routines that return integers
  149. that indicate ordering, like strcmp, would not change.
  150.  
  151.     Fergus> Can you imagine all the conflicts you are going to
  152.     Fergus> get, whichever way you decide to go?
  153.  
  154. I am confident that your imagination is more vivid than mine in that
  155. regard.
  156.  
  157.     Fergus> I strongly suspect that even if this proposal was
  158.     Fergus> accepted and implemented, programmers would just
  159.     Fergus> disable the warnings rather than bother fixing all
  160.     Fergus> their old code.
  161.  
  162. Some would.  You would.  And how would you suffer damage?  You would
  163. have to add -fdisable-boole-warnings to your makefile somewhere.
  164.  
  165. There are several reactions to my proposal that I can respect.  They
  166. are:
  167.  
  168. 1.  I don't like it, because I like to mix types as I now can in C.
  169. 2.  I don't like it, because it is fundamentally flawed.
  170. 3.  I don't like it, becuase <some aesthetic issue about 0t or somesuch>.
  171. 4.  It is flawed, but fixable; here's how.
  172. 5.  Such insight!  We'll get it in our compiler right away!
  173.  
  174. You claim to belong in category 2.  You belong in category 1.  I sense
  175. that the substantial improvements you would have me make would be in
  176. the nature of shortening the proposal.  Possibly to a single blank
  177. character.
  178.  
  179. I can accept that some people don't want change, or don't want a
  180. boolean type in particular.  If you hold that opinion, express it and
  181. I won't argue with you.  But don't state that a proposal is full of
  182. holes (i.e. ambiguities, self-contradictions, contradictions with the
  183. current standard, etc.) unless you are willing to present them.
  184.  
  185. *Constructive* feedback is still welcome.
  186.  
  187. Doug Moore
  188. (dougm@cs.rice.edu)
  189.