home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11606 < prev    next >
Encoding:
Text File  |  1992-07-27  |  8.6 KB  |  211 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
  3. From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
  4. Subject: Re: New C++ type: boole
  5. Message-ID: <1992Jul27.144523.2372@mksol.dseg.ti.com>
  6. Organization: Texas Instruments Inc
  7. References: <DOUGM.92Jul26151240@titan.cs.rice.edu>
  8. Date: Mon, 27 Jul 1992 14:45:23 GMT
  9. Lines: 200
  10.  
  11. In <DOUGM.92Jul26151240@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:
  12.  
  13. >    Fergus> 0t ??
  14. >    Fergus> This is woefully counter-intuitive. If you *have* to
  15. >    Fergus> have syntactically special values for true and false,
  16. >    Fergus> at least make it "1t".  (What's wrong with
  17. >    Fergus> "boole::false" and "boole::true" or some such?)  C++
  18. >    Fergus> is hard enough on beginners already, let's not add yet
  19. >    Fergus> another complicated and counter-intuitive syntactic
  20. >    Fergus> construct.
  21.  
  22. >You claim 1t is more intuitive, but that is only because you think
  23. >that 1==true and 0==false are the natural way of thinking about
  24. >things.  They are not.  The beginners about whom you are concerned are
  25. >the ones who write
  26.  
  27. >#define TRUE (1==1)
  28. >#define FALSE (0==1)
  29.  
  30. >because they're not entirely sure that *their* C compiler produces 1
  31. >and 0 for truth values.  Programmers in Fortran have no conceptual
  32. >problem with .TRUE.  and programmers in Scheme have no trouble with
  33. >#t.  C++ programmers are just as capable of understanding 0t.
  34.  
  35. This is an incredibly poor choice of symbology.  If it is to be a
  36. discrete boolean type, it would be better to not include either '0' or
  37. '1'.  Just use 'f,t', 'n,y', or 'off, on' in a boolean context and say
  38. that that's a boolean.
  39.  
  40. >    Fergus> So you are going to give me a warning if I write
  41.  
  42. >    Fergus>     if (ptr) ...
  43.  
  44. >    Fergus> but not if I write
  45.  
  46. >    Fergus>     if (!ptr) ...   ?
  47.  
  48. >Yes, I am.
  49.  
  50. Sounds like you just broke a big part of the world to me.  This is
  51. also highly non-orthoganal, in that you have a quantity ('ptr') which
  52. you say you are going to issue a warning on in a logical context, but
  53. you can do a simple negation and it becomes acceptable.  It should
  54. work the same way for 'ptr' and '!ptr'; either both should be legal or
  55. both should give warnings.  If you make both give warnings, you have
  56. once again broken a big part of the world.  Hence, neither should give
  57. warnings. 
  58.  
  59. >    Fergus> Sounds very counter-intuitive to me.
  60.  
  61. >Well, I am sorry for that.  To many people, the idea that a pointer to
  62. >that character over there is also "true" and a pointer to no character
  63. >at all is also "false" is counter-intuitive.  I don't claim to have
  64. >data to support the assertion that one set of intuitions is more
  65. >common than another.
  66.  
  67. >I suggest that you disable boolean warnings.
  68.  
  69. >    Fergus> Can you stick to proposing one extension at a time, please?
  70.  
  71. >I can, but I view this as a single extension.  So I think I'll keep it
  72. >as one.
  73.  
  74. >    Fergus> The merit of &&=, ||= is very debateable, as is the
  75. >    Fergus> idea of introducing a new idiom ++ for toggling
  76. >    Fergus> logical values. (Why not just use "negate(t)" instead
  77. >    Fergus> of "t++"? The former seems to convey the meaning much
  78. >    Fergus> more clearly.)
  79.  
  80. >To call a thing "debateable" is not quite as useful as actually
  81. >debating it.  The idiom ++ for toggling logical values is not new.
  82. >Here, for example, is an example taken from the Sun manual page for
  83. >the getopt C library function:
  84.  
  85. >               while ((c = getopt(argc, argv, "abo:")) != -1)
  86. >                    switch (c) {
  87. >                    case 'a':
  88. >                         if (bflg)
  89. >                              errflg++;
  90. >                         else
  91. >                              aflg++;
  92. >                         break;
  93. >                    case 'b':
  94. >                         if (aflg)
  95. >                              errflg++;
  96. >                         else
  97. >                              bproc ();
  98. >                         break;
  99. >                    case 'o':
  100. >                         ofile = optarg;
  101. >                         break;
  102. >                    case '?':
  103. >                         errflg++;
  104. >                    }
  105. >               if (errflg) {
  106. >                    (void)fprintf(stderr, "usage: . . . ");
  107. >                    exit (2);
  108. >               }
  109.  
  110. >Is negate(t) clearer?  I don't know.  Is rem(a,b) clearer than a%b?
  111. >Is deref(p) clearer than *p?  I only know that plenty of people
  112. >already use '++' for logical negation.
  113.  
  114. Not really.  You appear not to understand that what people are doing
  115. is using a 'non-boolean' method of altering a 'boolean'.  If I have a
  116. flag that is false and I increment it twice, I expect it to be true.
  117. If you examine that Sun code more closely, I suspect that you will
  118. find that it follows some other code that also checks for errors (and
  119. increments the error flag if it finds one) or it was written by
  120. someone working on a machine with a compiler for which post-increment
  121. was faster than assignment.
  122.  
  123. If you want to have this, use either the logical negation operator '!'
  124. or the complement operator '~' to do it.
  125.  
  126. >    Fergus> Also you are asking for a lot of work for the compiler-writers.
  127.  
  128. >That's their job.  But if they are short of time, they can stop
  129. >working on exception handling (try, etc.) because I don't have any use
  130. >for it, I find it counterintuitive, and I find that it might cause all
  131. >my programs that use "try" as a variable name to break. :-)
  132.  
  133. >Besides, I do not believe that the work required would be exceptional.
  134.  
  135. Belief isn't good enough.  Have you LOOKED at the amount of work
  136. required to make this work with the rest of the language?
  137.  
  138. >    Fergus> One more comment: what about all the standard library
  139. >    Fergus> routines?  Are you going to change isdigit() etc. to
  140. >    Fergus> return booles?
  141.  
  142. >Were I concerned with library standardization, which I am not, I would
  143. >suggest that routines that return only true and false values, like
  144. >isdigit, should return booles, and that routines that return integers
  145. >that indicate ordering, like strcmp, would not change.
  146.  
  147. Congratulations, you have once again apparently broken a large part of
  148. teh world, since there is a lot of code out there that assumes all
  149. these libraries are going to return 'int'.  In addition, if you want
  150. to hack on the language, you need to GET concerned with library
  151. standardization.  When you want to change a language (as opposed to
  152. designing your own), you have to take into account the impact of your
  153. proposed changes to ALL PARTS OF THE LANGUAGE.
  154.  
  155. >    Fergus> Can you imagine all the conflicts you are going to
  156. >    Fergus> get, whichever way you decide to go?
  157.  
  158. >I am confident that your imagination is more vivid than mine in that
  159. >regard.
  160.  
  161. It would seem that most peoples' are.
  162.  
  163. >    Fergus> I strongly suspect that even if this proposal was
  164. >    Fergus> accepted and implemented, programmers would just
  165. >    Fergus> disable the warnings rather than bother fixing all
  166. >    Fergus> their old code.
  167.  
  168. >Some would.  You would.  And how would you suffer damage?  You would
  169. >have to add -fdisable-boole-warnings to your makefile somewhere.
  170.  
  171. Pretty much EVERYONE would have to do this.  So what's the point?
  172.  
  173. >There are several reactions to my proposal that I can respect.  They
  174. >are:
  175.  
  176. >1.  I don't like it, because I like to mix types as I now can in C.
  177. >2.  I don't like it, because it is fundamentally flawed.
  178. >3.  I don't like it, becuase <some aesthetic issue about 0t or somesuch>.
  179. >4.  It is flawed, but fixable; here's how.
  180. >5.  Such insight!  We'll get it in our compiler right away!
  181.  
  182. >You claim to belong in category 2.  You belong in category 1.  I sense
  183. >that the substantial improvements you would have me make would be in
  184. >the nature of shortening the proposal.  Possibly to a single blank
  185. >character.
  186.  
  187. >I can accept that some people don't want change, or don't want a
  188. >boolean type in particular.  If you hold that opinion, express it and
  189. >I won't argue with you.  But don't state that a proposal is full of
  190. >holes (i.e. ambiguities, self-contradictions, contradictions with the
  191. >current standard, etc.) unless you are willing to present them.
  192.  
  193. >*Constructive* feedback is still welcome.
  194.  
  195. It would appear not.  You seem more interested in protecting your ego
  196. and flaming critics than you do in listening to constructive
  197. criticism. 
  198.  
  199. You appear to want to define a new language that looks something like
  200. C/C++ but doesn't act much like it unless this 'extension' is
  201. disabled.  Which it would have to be for most code that exists.
  202.  
  203. [I didn't read the original proposal, I'm afraid, but what I see of it
  204. here looks bad.]
  205.  
  206. -- 
  207. "Insisting on perfect safety is for people who don't have the balls to live
  208.  in the real world."   -- Mary Shafer, NASA Ames Dryden
  209. ------------------------------------------------------------------------------
  210. Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
  211.