home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1587 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.5 KB
  1. Path: sparky!uunet!olivea!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!math.zko.dec.com!edp
  2. From: edp@math.zko.dec.com (Eric Postpischil)
  3. Newsgroups: comp.edu
  4. Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
  5. Message-ID: <1992Sep9.132117.25608@nntpd.lkg.dec.com>
  6. Date: 9 Sep 92 13:21:17 GMT
  7. References: <1992Sep3.112944.20996@dbsun.uucp> <Bu08uF.HBC@mentor.cc.purdue <KERS.92Sep4154056@cdollin.hpl.hp.com> <135691@lll-winken.LLNL.GOV>
  8. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  9. Reply-To: edp@math.zko.dec.com (Eric Postpischil)
  10. Distribution: na
  11. Organization: Digital Equipment Corporation
  12. Lines: 36
  13.  
  14. In article <135691@lll-winken.LLNL.GOV>, blair@lll-crg.llnl.gov (Gary
  15. Blair) writes:
  16.  
  17. >Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
  18. >next to impossible to allow programmer-defined operators.  The parser must
  19. >know what an operator looks like, and what precedence it has  with respect
  20. >to all other operators.  This is usually predetermined, at
  21. >compiler-generation time.
  22.  
  23. Nah, it is trivial.  The lexical analyzer just recognizes the operator
  24. and returns a token to the parser.  Handling precedence is a bit
  25. trickier, but if you are willing to accept a fixed number of precedence
  26. levels determined at compiler-generation time, it is trivial too. 
  27. Simply, when an operator is declared, the parser stores the name of the
  28. operator (the string of symbols that denote it) into a data structure,
  29. along with information about its precedence and meaning.  When the
  30. lexical analyzer sees that string in the future, it returns a token
  31. appropriate to the precedence of the operator.  That token is used in
  32. the parsing; it is part of the parse tables.  When the parser sees that
  33. token, it takes a value from the token that points to the information
  34. about the operator and calls appropriate routines to implement the
  35. meaning.
  36.  
  37. The principal requirement here be that legal strings for operators and
  38. other symbols be defined properly, so that whatever selection of
  39. declarations the user makes is unambiguous and can be recognized by the
  40. lexical analyzer.  E.g., variables and types and similar things might be
  41. all alphanumeric, and operators might be all contiguous strings of
  42. symbols such as <, !, et cetera.  But you could easily have named
  43. operators using the scheme I have described above, such as "a modulo_add
  44. b" to mean (a+b)%m.
  45.  
  46.  
  47.                                 -- edp (Eric Postpischil)
  48.                                 "Always mount a scratch monkey."
  49.                                 edp@alien.enet.dec.com
  50.