Re: Extension Languages (Stavros Macrakis)
Fri, 18 Dec 1992 01:22:57 GMT

          From comp.compilers

Related articles
Extension Languages (1992-12-14)
Re: Extension Languages xjam@cork.CS.Berkeley.EDU (1992-12-14)
Re: Extension Languages (1992-12-14)
Re: Extension Languages (Dave Gillespie) (1992-12-15)
Re: Extension Languages (1992-12-16)
Re: Extension Languages (1992-12-17)
Re: Extension Languages (Peter Ludemann) (1992-12-17)
Re: Extension Languages (1992-12-18)
Re: Extension Languages (Dave Gillespie) (1992-12-19)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Stavros Macrakis)
Organization: OSF Research Institute
Date: Fri, 18 Dec 1992 01:22:57 GMT
Keywords: design
References: 92-12-056 92-12-064

Dave Gillespie <> 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?


Post a followup to this message

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