home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1586 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.2 KB
  1. From: kers@hplb.hpl.hp.com (Chris Dollin)
  2. Date: Wed, 9 Sep 1992 08:21:35 GMT
  3. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  4. Message-ID: <KERS.92Sep9092135@cdollin.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hpscdc!scd.hp.com!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  7. Newsgroups: comp.edu
  8. References: <1992Sep3.112944.20996@dbsun.uucp> <Bu08uF.HBC@mentor.cc.purdue <KERS.92Sep4154056@cdollin.hpl.hp.com> <135691@lll-winken.LLNL.
  9. Distribution: na
  10. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  11. Followup-to: comp.lang.misc
  12. Lines: 48
  13. In-Reply-To: blair@lll-crg.llnl.gov's message of 8 Sep 92 16:08:19 GMT
  14. Nntp-Posting-Host: cdollin.hpl.hp.com
  15.  
  16. In article ... blair@lll-crg.llnl.gov (Gary Blair) writes:
  17.  
  18.    In article ... kers@hplb.hpl.hp.com (Chris Dollin) writes:
  19.    >In article ... fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  20.    >
  21.    >   C++ allows you to overload existing operators, although to make compiler
  22.    >   writer's jobs easier, it does not allow you to introduce new operators.
  23.    >
  24.    >Make that ``trivially easier''. So far as I am able to tell, the 
  25.    >difficulty of allowing the user to add new operator definitions is rather 
  26.    >close to zero, so long as this is taken into account *before* designing 
  27.    >the language and compiler. (C++ has the problem of trying to incorporate 
  28.    >the lexical structure of C.)
  29.  
  30.    Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
  31.    next to impossible to allow programmer-defined operators.  The parser must
  32.    know what an operator looks like, and what precedence it has  with respect
  33.    to all other operators.  This is usually predetermined, at
  34.    compiler-generation time.  
  35.  
  36. Well, in that case there are several next-to-impossible compilers out there,
  37. all compiling Algol68. And, depending on what you mean by ``table-driven
  38. parsing'', ``next-to-impossible'' is a gross over-statement. All it takes is
  39. feedback from the semantic analysis to the lexical analyser, telling it what
  40. the current precedence of operator tokens is. You may have religious objections
  41. to this technique; I know I do.
  42.  
  43. But in any case, the difficulty lies with *precedence*, not *spelling* (the
  44. latter being ``knowing what an operator looks like''). If you're prepared to 
  45. give user-defined operators a fixed precedence level, then the problem goes
  46. away. I'd rather have user-defined operators with a fixed precedence level
  47. (assuming the designer is sane enough to choose a sensible value) than not have
  48. them at all.
  49.  
  50. As for the parser knowing what an operator looks like, it has the same problem
  51. as knowing what an indentifier looks like, or a string, or a keyword; to wit,
  52. none. Assuming, that is, that you construct operator symbols from an alphabet
  53. of operator characters in a uniform way -- just as identifier symbols are
  54. constructed from identifier characters (usually letters, digits, and the odd
  55. special character).
  56.  
  57. Now I've exposed my hidden assumptions, you mat accuse me of cheating.
  58.  
  59. [I've adjusted followups to comp.lang.misc. I hope.]
  60. --
  61.  
  62. Regards,    | "You're better off  not dreaming of  the things to come;
  63. Kers.       | Dreams  are always ending  far too soon." - Caravan.
  64.