|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:||Peter Ludemann <email@example.com>|
|Date:||Thu, 17 Dec 1992 22:34:22 GMT|
Dave Gillespie <firstname.lastname@example.org> writes:
> 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) ...
I once read an article describing REXX's interpreter (REXX is used as both
a "shell" language and an editor extension language), which states that
20-30% of the CPU time is spent in scanning for the next non-blank ---
something a parser for any language needs to do (this scanner loop is in
tightly coded assembler, by the way). As the standard method of handling
infix languages is to push things onto a stack, the cost of interpreting
an infix language should be the same as for prefix and postfix languages.
[Sorry, I don't have a reference to the article handy; I think it was by
Auslander, describing a port of REXX from 370 to RT.]
[Side note: from my work on a Prolog parser, I can attest that also
allowing user-defined prefix, infix, and postfix operators does not unduly
complicate or slow down the parser.]
Let's not push this efficiency argument too far or else we'll see BASIC's
original 1- and 2-letter identifiers resurfacing ... we wouldn't want to
spend too much time in hashing identifiers, would we? :-) Similarly,
there's no reason for the Bourne shell's requirement that functions be
defined before use; REXX easily handles that by recording each function's
location and scanning forward if necessary. And I strongly suspect that a
properly built interpreter for an infix language would have performance
within a few percent of that for a prefix/postfix language --- and no
question about which is easier to program in.
If you want to see REXX's implementation, find somebody who has IBM's CMS
operating system; the interpreter source is included. [The source for the
compiler and for the OS/2 implementation aren't.]
Incidentally, REXX is also evidence that powerful languages don't need to
be cryptic and that they can be used well by both beginners and experts
(REXX has roughly the expressivity of ksh+awk or perl, but with a syntax
like "BASIC done right").
Return to the
Search the comp.compilers archives again.