home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10794 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.8 KB
  1. Xref: sparky comp.arch:10794 comp.lang.misc:3718
  2. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Date: 16 Nov 92 20:36:10
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 20
  10. Message-ID: <TMB.92Nov16203610@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.purdue.edu>
  13. Reply-To: tmb@idiap.ch
  14. NNTP-Posting-Host: arolla.idiap.ch
  15. In-reply-to: hrubin@pop.stat.purdue.edu's message of Mon, 16 Nov 1992 15:43:26 GMT
  16.  
  17. In article <BxtFoF.BGn@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  18.  
  19.    > * Programming languages themselves nowadays only let you specify very
  20.    >   limited syntactic extensions, because such extensions are difficult
  21.    >   to scope properly (mind you, the computer and the parser have no
  22.    >   problem with this, it is the humans that can't deal with it).  This
  23.    >   isn't the result of some kind of "language fascism", but of market
  24.    >   forces: languages that have allowed more general syntactic
  25.    >   extensions simply never caught on, presumably because such
  26.    >   extensions were causing more hassle than they were worth.
  27.  
  28.    I am not at all convinced that this is the case.  I doubt that they were
  29.    left out of C++ because humans could have problems with them; if that is
  30.    the case, a warning should be sufficient.
  31.  
  32. The problem is that user-defined operators cause problems about which
  33. the compiler cannot warn reliably. For the rationale and some examples
  34. of what can go wrong, see the ARM, p331.
  35.  
  36.                     Thomas.
  37.