home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1576 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.1 KB

  1. Xref: sparky comp.edu:1576 comp.lang.misc:2971
  2. Path: sparky!uunet!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Newsgroups: comp.edu,comp.lang.misc
  5. Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <Bu9tzC.3Ls@mentor.cc.purdue.edu>
  7. Date: 8 Sep 92 17:59:35 GMT
  8. References: <Bu08uF.HBC@mentor.cc.purdue <KERS.92Sep4154056@cdollin.hpl.hp.com> <135691@lll-winken.LLNL.GOV>
  9. Sender: news@mentor.cc.purdue.edu (USENET News)
  10. Distribution: na
  11. Organization: Purdue University Statistics Department
  12. Lines: 49
  13.  
  14. In article <135691@lll-winken.LLNL.GOV> blair@lll-crg.llnl.gov (Gary Blair) writes:
  15. >In article <KERS.92Sep4154056@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
  16. >>In article ... fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  17.  
  18. >>   C++ allows you to overload existing operators, although to make compiler
  19. >>   writer's jobs easier, it does not allow you to introduce new operators.
  20.  
  21. >>Make that ``trivially easier''. So far as I am able to tell, the difficulty of
  22. >>allowing the user to add new operator definitions is rather close to zero, so
  23. >>long as this is taken into account *before* designing the language and
  24. >>compiler. (C++ has the problem of trying to incorporate the lexical structure
  25. >>of C.)
  26.  
  27.  
  28.  
  29. >Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
  30. >next to impossible to allow programmer-defined operators.  The parser must
  31. >know what an operator looks like, and what precedence it has  with respect
  32. >to all other operators.  This is usually predetermined, at
  33. >compiler-generation time.  
  34.  
  35. What you have just said is that if it is not taken into account before 
  36. designing the language and compiler, it is hard to take into account
  37. later.  This has not been disputed.
  38.  
  39. Far too much emphasis has been placed on the problem of precedence.  For
  40. combinations other than the usual arithmetic ones, and precedence for 
  41. unary operators over n-ary, programmers who do not know for sure should
  42. use parentheses, or even transient values rather than concatenating the
  43. operations.  Unless rewriting is allowed using algebraic (even in the
  44. extended sense) properties, the compiler has to do this anyhow.   And
  45. even if the rewriting is done, it will still have to do this.  So let
  46. the programmer in on the act.
  47.  
  48. Similar problems occur with operations which naturally return a list of
  49. values.  There is much anguish about calls having side effects; this is
  50. due to a function call producing results, or changing results, besides
  51. the explicit output value.  These are far from uncommon.
  52.  
  53. What is the purpose of a language/compiler combination?  To enable the
  54. USER to write better code faster.  It is not for the convenience of the
  55. compiler writer or language designer.  The same holds for language 
  56. design principles; it is not the beauty or the purity of the product
  57. which counts, but how well it does the job.
  58. -- 
  59. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  60. Phone: (317)494-6054
  61. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  62. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  63.