home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compiler / 2054 < prev    next >
Encoding:
Text File  |  1992-12-20  |  2.8 KB  |  65 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  3. From: Peter Ludemann <ludemann@quintus.com>
  4. Subject: Re: Extension Languages 
  5. Reply-To: Peter Ludemann <ludemann@quintus.com>
  6. Organization: Compilers Central
  7. Date: Thu, 17 Dec 1992 22:34:22 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-12-086@comp.compilers>
  10. Keywords: design, interpreter
  11. References: <92-12-064@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 50
  14.  
  15. Dave Gillespie <daveg@thymus.synaptics.com> writes:
  16. > 
  17. >    notation:    infix        prefix        postfix
  18. >    example:    C, Pascal    Lisp        Forth, PostScript
  19. >    syntax:    parens, opers, ...    parentheses    "none"
  20. >    humans:        easy        okay        hard
  21. >    machines:    hard        okay        easy
  22. > 
  23. >Languages on the left end of this spectrum require a lot of parsing effort
  24. >    (relatively speaking) ...
  25.  
  26. I once read an article describing REXX's interpreter (REXX is used as both
  27. a "shell" language and an editor extension language), which states that
  28. 20-30% of the CPU time is spent in scanning for the next non-blank ---
  29. something a parser for any language needs to do (this scanner loop is in
  30. tightly coded assembler, by the way).  As the standard method of handling
  31. infix languages is to push things onto a stack, the cost of interpreting
  32. an infix language should be the same as for prefix and postfix languages.
  33. [Sorry, I don't have a reference to the article handy; I think it was by
  34. Auslander, describing a port of REXX from 370 to RT.]
  35.  
  36. [Side note: from my work on a Prolog parser, I can attest that also
  37. allowing user-defined prefix, infix, and postfix operators does not unduly
  38. complicate or slow down the parser.]
  39.  
  40. Let's not push this efficiency argument too far or else we'll see BASIC's
  41. original 1- and 2-letter identifiers resurfacing ... we wouldn't want to
  42. spend too much time in hashing identifiers, would we? :-) Similarly,
  43. there's no reason for the Bourne shell's requirement that functions be
  44. defined before use; REXX easily handles that by recording each function's
  45. location and scanning forward if necessary.  And I strongly suspect that a
  46. properly built interpreter for an infix language would have performance
  47. within a few percent of that for a prefix/postfix language --- and no
  48. question about which is easier to program in.
  49.  
  50. If you want to see REXX's implementation, find somebody who has IBM's CMS
  51. operating system; the interpreter source is included.  [The source for the
  52. compiler and for the OS/2 implementation aren't.]
  53.  
  54. Incidentally, REXX is also evidence that powerful languages don't need to
  55. be cryptic and that they can be used well by both beginners and experts
  56. (REXX has roughly the expressivity of ksh+awk or perl, but with a syntax
  57. like "BASIC done right").
  58.  
  59. -----
  60.  
  61. Peter Ludemann
  62. -- 
  63. Send compilers articles to compilers@iecc.cambridge.ma.us or
  64. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  65.