home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1639 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  3.1 KB
  1. Xref: sparky comp.edu:1639 comp.lang.fortran:3536 comp.lang.misc:3047 comp.arch:9385 sci.math:11336
  2. Path: sparky!uunet!usc!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!ogicse!orstcs!orstcs!usenetusenet
  3. From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
  4. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  5. Subject: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
  6. Message-ID: <1992Sep13.022830.2046@CS.ORST.EDU>
  7. Date: 13 Sep 92 02:28:30 GMT
  8. Article-I.D.: CS.1992Sep13.022830.2046
  9. References: <Bu08uF.HBC@mentor.cc.purdue <KERS.92Sep4154056@cdollin.hpl.hp.com> <135691@lll-winken.LLNL.GOV>
  10. Sender: usenet@CS.ORST.EDU
  11. Distribution: na
  12. Organization: Oregon State University, Corvallis Oregon
  13. Lines: 45
  14. Nntp-Posting-Host: jade.cs.orst.edu
  15.  
  16. In article <135691@lll-winken.LLNL.GOV>
  17. blair@lll-crg.llnl.gov (Gary Blair) writes:
  18. >In article <KERS.92Sep4154056@cdollin.hpl.hp.com>
  19. kers@hplb.hpl.hp.com (Chris Dollin) writes:
  20. >>In article ... fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  21. >>
  22. >>   C++ allows you to overload existing operators, although to make compiler
  23. >>   writer's jobs easier, it does not allow you to introduce new operators.
  24. >>
  25. >>Make that ``trivially easier''. So far as I am able to tell, the difficulty of
  26. >>allowing the user to add new operator definitions is rather close to zero, so
  27. >>long as this is taken into account *before* designing the language and
  28. >>compiler. (C++ has the problem of trying to incorporate the lexical structure
  29. >>of C.)
  30. >
  31. >Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
  32. >next to impossible to allow programmer-defined operators.  The parser must
  33. >know what an operator looks like, and what precedence it has  with respect
  34. >to all other operators.  This is usually predetermined, at
  35. >compiler-generation time.  
  36.  
  37. That last statement is _wrong_.  It is _easy_ to add user-defined operators to
  38. a language.  The attributes sufficient to make it easy are:
  39.  
  40.    operators must be lexically distinct
  41.       just like identifiers are not predefined, but are lexically distinct,
  42.       so too can operators be lexically distinct
  43.    the operator precedence relationships must be static
  44.       this is true in languages like C where all the operators are fixed,
  45.       and therefore all the precedences are fixed
  46.    the operator precedence must be lexically determined
  47.       this is easy if you incorporate symbol table information into the
  48.       lexer so that on finding an operator, it looks up the precedence
  49.  
  50. I designed and implemented a simple language that permits user-defined
  51. infix and postfix operators and built the parser with lex and yacc.  My job
  52. was a little simpler than the above in that all operators had equal
  53. precedence, which meant that my symbol table only had to identify the operator
  54. as defined (like an identifier) and did not have to provide a precedence.
  55. Adding a precedence is simple.
  56.  
  57. -- 
  58.   Lawrence Crowl        503-737-2554    Computer Science Department
  59.                crowl@cs.orst.edu    Oregon State University
  60.           ...!hplabs!hp-pcd!orstcs!crowl    Corvallis, Oregon,  97331-3202
  61.