home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10840 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.6 KB
  1. Xref: sparky comp.arch:10840 comp.lang.misc:3743
  2. From: kers@hplb.hpl.hp.com (Chris Dollin)
  3. Date: Tue, 17 Nov 1992 09:03:05 GMT
  4. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  5. Message-ID: <KERS.92Nov17090305@cdollin.hpl.hp.com>
  6. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  7. Path: sparky!uunet!utcsri!newsflash.concordia.ca!garrot.DMI.USherb.CA!uxa.ecn.bgu.edu!mp.cs.niu.edu!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!sdd.hp.com!apollo.hp.com!cupnews0.cup.hp.com!scd.hp.com!hpscdm!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  8. Newsgroups: comp.arch,comp.lang.misc
  9. References: <Bxr8vG.IpI@mentor.cc.purdue.edu> <1e775rINNslq@network.ucsd.edu> <TMB.92Nov16140138@arolla.idiap.ch> <BxtFoF.BGn@mentor.cc.pur
  10. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  11. Followup-to: comp.lang.misc
  12. Lines: 31
  13. In-Reply-To: tmb@arolla.idiap.ch's message of 16 Nov 92 20:36:10
  14. Nntp-Posting-Host: cdollin.hpl.hp.com
  15.  
  16. I've (tried to) direct followups away from comp.arch.
  17.  
  18. In article ... tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  19.  
  20.    The problem is that user-defined operators cause problems about which
  21.    the compiler cannot warn reliably. For the rationale and some examples
  22.    of what can go wrong, see the ARM, p331.
  23.  
  24. It says ``This extension, however, would imply a significant extension of
  25. complexity of syntax analysis and an uncertain gain in readability.'' It then
  26. remarks that precedence and associativity must either be fixed for all
  27. user-defined operators, or a mechanism must be present to define them; it is
  28. this latter that is the tricky point. (The ``complexity of syntax analysis''
  29. argument seems to be terribly weak, given that (a) Stroustrup is not stupid,
  30. and (b) the rest of C++.)
  31.  
  32. There are many other things compilers cannot warn about reliably, or indeed, at
  33. all; writing ``-'' when one meant ``+'', forgetting to increment a counter,
  34. calling the wrong function (or not calling the right one), writing ``0'' when
  35. style demands FALSE or NULL_String, and so on. Has anyone done some *research*
  36. on the issue, rather than making *-informed speculation?
  37.  
  38. [My own speculation is that it's all perfectly sensible provided you're
  39. prepared to forgo the ability to define your own precedence and associativity,
  40. and that operator tokens are recognisable by spelling just as identifiers are.
  41. What would be handy, I think, is a way of making *any* dyadic function into an
  42. infix with a simple syntactic mark, eg, ``E1 @F E2''.]
  43. --
  44.  
  45. Regards | "Always code as if the guy who ends up maintaining your code will be
  46. Kers.   | a violent psychopath who knows where you live." - John F. Woods
  47.