Re: Precedence values for Reverse Polish

  ppaatt@aol.com (PPAATT) writes:
>> anton@mips.complang.tuwien.ac.at
>> (Anton Ertl)
>> Postscript ...
>
>Thank you. In Postscript, I'm told:
>
>Every object is either _literal_ or _executable_. This distinction
>comes into play when the interpreter attempts to execute the object.
>If the object is _literal_, the interpreter will treat it strictly as
>data and will push it on the operand stack for use as an operand of
>some subsequent operator. But if the object is _executable_, the
>interpreter will execute it.
...
>I wonder what the point was?


In some cases the interpreter will push an executable array on the
stack instead of executing it and in others it will execute it.


The point was that in this area Postscript does not appear simpler to
me than Forth.


>> Lisp ... still need the "quote" special
>
>I'm not sure I understand the question? Please help?


It's not a question; you claimed that we would no longer need special
forms; I pointed out that we would need at least the quote special
form.


>> The straightforward implementation is more complex and less
>> efficient than the less elegant solutions;
>
>I don't understand. Could you/anyone please also volunteer an example?


Compare the appropriate parts of a Postscript and a Forth
implementation.


The straightforward implementation is more complex, because you have
to produce procedures for the code fragments; these procedures are
nested in the normal code, and may access local variables of outer
scopes (if the language has local variables); if your language already
supports all of this, the incremental cost is small, if it does not,
it is larger.


The straightforward implementation is less efficient, because an
indirect procedure call (especially if implemented straightforwardly)
is more expensive than a conditional jump.


> I
>thought more elegant equalled smaller equalled simpler?


When judging languages (and their features), I equal elegance with
expressive power; implementation cost does not play a role in this
consideration. Programs and algorithms are another issue.


>> if you want to make it efficient, you get even more complexity.
>
>Perhaps I only understand this remark in part?
>
>If I have a simple, slow, elegant solution then I can make it fast
>only by adding support for special cases - only by adding complexity.
>
>But maybe here you're trying to say something more?


No, that's about what I meant. In some cases there are also general,
faster solutions, but they are necessarily more complex, or they would
be straightforward.


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

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