home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3768 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  2.6 KB
  1. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  5. Followup-To: comp.lang.misc
  6. Date: 18 Nov 92 18:45:15
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 37
  10. Message-ID: <TMB.92Nov18184515@arolla.idiap.ch>
  11. References: <Bxr8vG.IpI@mentor.cc.purdue.edu> <1e775rINNslq@network.ucsd.edu>
  12.     <TMB.92Nov16140138@arolla.idiap.ch> <BxtFoF.BGn@mentor.cc.pur
  13.     <KERS.92Nov17090305@cdollin.hpl.hp.com>
  14. Reply-To: tmb@idiap.ch
  15. NNTP-Posting-Host: arolla.idiap.ch
  16. In-reply-to: kers@hplb.hpl.hp.com's message of 17 Nov 92 09:03:05 GMT
  17.  
  18. In article <KERS.92Nov17090305@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
  19.  
  20.    In article ... tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  21.  
  22.       The problem is that user-defined operators cause problems about which
  23.       the compiler cannot warn reliably. For the rationale and some examples
  24.       of what can go wrong, see the ARM, p331.
  25.  
  26.    It says ``This extension, however, would imply a significant extension of
  27.    complexity of syntax analysis and an uncertain gain in readability.'' It then
  28.    remarks that precedence and associativity must either be fixed for all
  29.    user-defined operators, or a mechanism must be present to define them; it is
  30.    this latter that is the tricky point. (The ``complexity of syntax analysis''
  31.    argument seems to be terribly weak, given that (a) Stroustrup is not stupid,
  32.    and (b) the rest of C++.)
  33.  
  34. It goes on to give several examples that behave rather unexpectedly.
  35. Also, I think by "complexity" he means "difficulty of bringing the
  36. user's expectations in line with what the language actually does",
  37. rather than speed.
  38.  
  39.    There are many other things compilers cannot warn about reliably, or indeed, at all;
  40.  
  41. So, let's not increase the number of cases in which this can happen.
  42.  
  43.    writing ``-'' when one meant ``+'', forgetting to increment a counter,
  44.    calling the wrong function (or not calling the right one), writing ``0'' when
  45.    style demands FALSE or NULL_String, and so on. Has anyone done some *research*
  46.    on the issue, rather than making *-informed speculation?
  47.  
  48. That's a question of psychology and taste. I don't think I have
  49. speculated (informedly or uninformedly) about your tastes in
  50. particular. But I think it is fair to point out that the fact that
  51. modern programming languages severely limit user-defined syntactic
  52. extensions is probably a reflection of common needs and tastes.
  53.  
  54.                     Thomas.
  55.