home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compiler / 2055 < prev    next >
Encoding:
Text File  |  1992-12-20  |  3.1 KB  |  72 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!world!iecc!compilers-sender
  3. From: macrakis@osf.org (Stavros Macrakis)
  4. Subject: Re: Extension Languages
  5. Reply-To: macrakis@osf.org (Stavros Macrakis)
  6. Organization: OSF Research Institute
  7. Date: Fri, 18 Dec 1992 01:22:57 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-12-087@comp.compilers>
  10. Keywords: design
  11. References: <92-12-056@comp.compilers> <92-12-064@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 57
  14.  
  15. Dave Gillespie <daveg@thymus.synaptics.com> writes:
  16.  
  17.    ...You can think of a spectrum of linguistic simplicity vs. ease of use by
  18.    human programmers:
  19.  
  20.      notation:       infix           prefix           postfix
  21.      example:      C, Pascal          Lisp       Forth, PostScript
  22.      syntax:  parens, opers, ...   parentheses        "none"
  23.      humans:         easy             okay             hard
  24.      machines:       hard             okay             easy
  25.  
  26.    Languages on the left end of this spectrum require a lot of parsing effort
  27.    (relatively speaking) and have a lot of redundancy in their grammars,
  28.  
  29. As Knuth, Morris, and Pratt said in their paper on fast pattern matching: 
  30.  
  31.     It is a curious fact that people often think the new algorithm will be
  32.     slower than the naive one, even though it does less work.  Since the
  33.     new algorithm is conceptually hard to understand at first, by
  34.     comparison with other algorithms of the same length, we feel somehow
  35.     that a computer will have conceptual difficulties too--we expect the
  36.     machine to run more slowly when it gets to such subtle instructions!
  37.  
  38. Any of these notations are "easy for the machine", although some of the
  39. tables will be larger for infix notation.
  40.  
  41.    ...There's nothing stopping you from doing a Lisp-like language that uses
  42.    postfix operators, but people generally don't because the interpreter has
  43.    an easier time of it if the operator comes first.
  44.  
  45. Two remarks:
  46.  
  47. 1) You seem to assume that postfix syntax translates into difficulty of
  48.    accessing the operator.  But the syntax doesn't tell you anything about
  49.    the internal representation.
  50.  
  51. 2) Many machine-oriented languages are postfix, precisely because they are
  52.    EASIER to interpret.  The problem comes only with non-strict operators
  53.    like "if", which such languages avoid by using explicit gotos.
  54.  
  55.    I've also seen languages which are Lisp-like in essence, but with C-like
  56.    parsers added on top to make them more palatable.  In other words, they
  57.    have a parser which reads "a+b" into the list "(+ a b)".
  58.  
  59. Yes, there are Lisp-like languages which provide an infix syntax, or even
  60. Lisps which happen to have an infix reader as well.  But they are not
  61. Lisp-like because they represent the program as a tree!  After all, many
  62. language processors represent the program as a tree at some point....
  63.  
  64. Recall also that S-expressions were originally designed as a "machine
  65. representation" for M-expressions, which were NOT parenthesized.  Lisp is
  66. truly protean, n'est-ce pas?
  67.  
  68.     -s
  69. -- 
  70. Send compilers articles to compilers@iecc.cambridge.ma.us or
  71. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  72.