|Extension Languages email@example.com (1992-12-14)|
|Re: Extension Languages xjam@cork.CS.Berkeley.EDU (1992-12-14)|
|Re: Extension Languages firstname.lastname@example.org (1992-12-14)|
|Re: Extension Languages email@example.com (Dave Gillespie) (1992-12-15)|
|Re: Extension Languages firstname.lastname@example.org (1992-12-16)|
|Re: Extension Languages email@example.com (1992-12-17)|
|Re: Extension Languages firstname.lastname@example.org (Peter Ludemann) (1992-12-17)|
|Re: Extension Languages email@example.com (1992-12-18)|
|Re: Extension Languages firstname.lastname@example.org (Dave Gillespie) (1992-12-19)|
|From:||email@example.com (Stavros Macrakis)|
|Organization:||OSF Research Institute|
|Date:||Fri, 18 Dec 1992 01:22:57 GMT|
Dave Gillespie <firstname.lastname@example.org> writes:
...You can think of a spectrum of linguistic simplicity vs. ease of use by
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.
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?
Return to the
Search the comp.compilers archives again.