home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compiler / 2032 < prev    next >
Encoding:
Text File  |  1992-12-14  |  4.2 KB  |  85 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!world!iecc!compilers-sender
  3. From: Dave Gillespie <daveg@thymus.synaptics.com>
  4. Subject: Re: Extension Languages
  5. Reply-To: Dave Gillespie <daveg@thymus.synaptics.com>
  6. Organization: Compilers Central
  7. Date: Tue, 15 Dec 1992 03:14:20 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-12-064@comp.compilers>
  10. Keywords: design
  11. References: <92-12-056@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 70
  14.  
  15. > IS there any specific reason why one would choose to utilise an prefix
  16. > notation language for extensions to an editor as opposed to infix orr
  17. > post-fix?
  18.  
  19. I think Emacs uses Lisp as its base language because Lisp is so well
  20. adapted to running interpretively and in a constantly changing
  21. environment.  Also, because of its simpler syntax, I'd argue that you get
  22. more "bang for your buck," i.e., the size of the interpreter is fairly
  23. small compared to the amount of functionality you get.
  24.  
  25. In Lisp this comes mainly from its uniform treatment of code and data
  26. structures; since it's interpreted out of data structures that have had
  27. very little preprocessing, it would need to do substantial parsing on the
  28. fly in order to support C-like infix notation.
  29.  
  30. You can think of a spectrum of linguistic simplicity vs. ease of use by
  31. human programmers:
  32.  
  33.  notation:       infix         prefix          postfix
  34.  example:      C, Pascal      Lisp         Forth, PostScript
  35.  syntax:  parens, opers, ...   parentheses        "none"
  36.  humans:         easy          okay           hard
  37.  machines:     hard          okay           easy
  38.  
  39. Languages on the left end of this spectrum require a lot of parsing effort
  40. (relatively speaking) and have a lot of redundancy in their grammars,
  41. which translates to being fairly easy for humans to read and work with.
  42. Languages on the right end have absolutely minimal syntax (generally just
  43. a linear sequence of words, without even parentheses to make the grouping
  44. clear), which makes them trivial to implement but hard to use.  Lisp comes
  45. in the middle, being reasonably easy and cheap to implement, and
  46. reasonably easy for human programmers to use.
  47.  
  48. There's nothing stopping you from doing a Lisp-like language that uses
  49. postfix operators, but people generally don't because the interpreter has
  50. an easier time of it if the operator comes first.  I've also seen
  51. languages which are Lisp-like in essence, but with C-like parsers added on
  52. top to make them more palatable.  In other words, they have a parser which
  53. reads "a+b" into the list "(+ a b)".  This can be a big help for novices,
  54. but Lisp purists prefer to work directly with the list representation so
  55. that they know what they're dealing with.
  56.  
  57. With a good indenting editor like Emacs, Lisp can be quite easy to read
  58. despite the sparse syntax.  With some experience it becomes just as
  59. readable as a C-like language for anything except heavy arithmetic (where
  60. infix is still the Right Answer).  My own experience with PostScript is
  61. that it doesn't scale as well; I've never seen an automatic indenter for
  62. it, and it's not clear that tricks like indentation could ever be as
  63. illuminating for it as they are for Lisp.
  64.  
  65. Despite its being "just" an editor extension language, I've written a
  66. successful 50,000 line application in Emacs Lisp (Emacs Calc).  I've seen
  67. other Emacs applications and editing packages which were, if not that
  68. large, at least large enough to be feasible only in a fairly "real"
  69. language.  I don't think I could ever do something as ambitious as Calc in
  70. PostScript; even though the language is, technically speaking, strong
  71. enough for such a task, I'd go nuts trying to keep track of it all.
  72.  
  73. Interestingly, Emacs includes an Emacs Lisp compiler that translates to a
  74. byte-coded stack machine which is probably similar to the stack language
  75. that John Davis described here recently.  Emacs's byte-code interpreter is
  76. probably less bulletproof than John's, and therefore more streamlined,
  77. since it knows the byte codes will only come from a (presumably correct)
  78. byte-compiler.  So even Emacs finds a tight postfix system to be most
  79. efficient, though too crufty to expect humans to use directly.
  80.  
  81.                                 -- Dave
  82. -- 
  83. Send compilers articles to compilers@iecc.cambridge.ma.us or
  84. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  85.