Re: Extension Languages

Dave Gillespie <daveg@thymus.synaptics.com> writes:


      ...You can think of a spectrum of linguistic simplicity vs. ease of use by
      human programmers:


          notation: infix prefix postfix
          example: C, Pascal Lisp Forth, PostScript
          syntax: parens, opers, ... parentheses "none"
          humans: easy okay hard
          machines: hard okay easy


      Languages on the left end of this spectrum require a lot of parsing effort
      (relatively speaking) and have a lot of redundancy in their grammars,


As Knuth, Morris, and Pratt said in their paper on fast pattern matching:


        It is a curious fact that people often think the new algorithm will be
        slower than the naive one, even though it does less work. Since the
        new algorithm is conceptually hard to understand at first, by
        comparison with other algorithms of the same length, we feel somehow
        that a computer will have conceptual difficulties too--we expect the
        machine to run more slowly when it gets to such subtle instructions!


Any of these notations are "easy for the machine", although some of the
tables will be larger for infix notation.


      ...There's nothing stopping you from doing a Lisp-like language that uses
      postfix operators, but people generally don't because the interpreter has
      an easier time of it if the operator comes first.


Two remarks:


1) You seem to assume that postfix syntax translates into difficulty of
      accessing the operator. But the syntax doesn't tell you anything about
      the internal representation.


2) Many machine-oriented languages are postfix, precisely because they are
      EASIER to interpret. The problem comes only with non-strict operators
      like "if", which such languages avoid by using explicit gotos.


      I've also seen languages which are Lisp-like in essence, but with C-like
      parsers added on top to make them more palatable. In other words, they
      have a parser which reads "a+b" into the list "(+ a b)".


Yes, there are Lisp-like languages which provide an infix syntax, or even
Lisps which happen to have an infix reader as well. But they are not
Lisp-like because they represent the program as a tree! After all, many
language processors represent the program as a tree at some point....


Recall also that S-expressions were originally designed as a "machine
representation" for M-expressions, which were NOT parenthesized. Lisp is
truly protean, n'est-ce pas?


-s
--

Return to the comp.compilers page.
Search the comp.compilers archives again.