home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3773 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.0 KB  |  69 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!apple!mumbo.apple.com!gallant.apple.com!badenov.apple.com!user
  3. From: nevin@apple.com (Nevin ":-]" Liber)
  4. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  5. Sender: news@gallant.apple.com
  6. Message-ID: <nevin-181192145941@badenov.apple.com>
  7. Date: Thu, 19 Nov 1992 00:10:31 GMT
  8. References: <TMB.92Nov16140138@arolla.idiap.ch> <BxtFoF.BGn@mentor.cc.pur <KERS.92Nov17090305@cdollin.hpl.hp.com> <Bxvs9I.L22@mentor.cc.purdue.edu>
  9. Organization: Apple Computer, Inc.
  10. Followup-To: comp.lang.misc
  11. Lines: 56
  12.  
  13. In article <Bxvs9I.L22@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu
  14. (Herman Rubin) wrote:
  15. > What is the correct association in a << b + c?
  16.  
  17. It associates as  a << (b+c).
  18.  
  19. > Everyone I showed 
  20. > this to came up with the same answer; but that answer is wrong in C!
  21.  
  22. Well, considering I NEVER saw the << operator symbol before using C, how
  23. could it be wrong??  I could see people getting it wrong if they think of
  24. the shift left operator as a power operator.  A while ago I played around
  25. with changing the precedence of the C operators, but never found a
  26. different order that I was more comfortable with.  If you really don't like
  27. the precedence rules, and since no one but you will ever, ever try to read
  28. your code, it is fairly trivial to write a preprocessor that inserts the
  29. appropriate parentheses the enforce any precedence rules you wish.  How
  30. would YOU, Herman Rubin, define the precedence rules??  BE EXPLICIT!
  31.  
  32. > One
  33. > cannot even get the compiler to consider spacing in resolving this.
  34.  
  35. I'll leave the rebuttal for this to people with more free time on their
  36. hands. :-)
  37.  
  38. > I 
  39. > would just as soon go the the APL idea, which only distinguishers unary
  40. > and binary.
  41.  
  42. So, why aren't you using APL??
  43.  
  44. > It would help if we could get a more complicated set of 
  45. > parentheses,
  46.  
  47. Adding lots of complexity for negligible, if an, gain is a bad, bad idea.
  48.  
  49. > or allow explicit temporaries to be used to break up the
  50. > operation stream;
  51.  
  52. What stops you from doing this now??
  53.  
  54. > Put one
  55. > precedence for unary operators and another for binary operators, or even
  56. > equate the infix notation x FOO y with !FOO(x,y); those of us who want 
  57. > to use user-defined operators would find this a lot preferable to not
  58. > allowing them at all, even if we had to use parentheses all the time.
  59.  
  60. Funny, I just don't see you getting along with 2 + 3 * 5 evaluating as 25
  61. instead of 17.  Besides, don't you always complain that LISP has too many
  62. parentheses??  If you really want this stuff, it's fairly simple to write
  63. an infix -> postfix converter for LISP.
  64. ___
  65. NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
  66.  email:     nevin@apple.com        paper:  Apple Computer, Inc.
  67.  voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
  68.  AppleLink: BADENOV                        Cupertino, CA 95014
  69.