Re: Precedence values for Reverse Polish

> anton@mips.complang.tuwien.ac.at
> (Anton Ertl)


> > ... deferred ... lambda ...
> > as the intermediate form
> > ... going to bite me ... ?


> procedures passed at run-time


Eh? I'm intrigued! Could you please elaborate? I've gone a little way in
that direction without perceiving trouble yet?


To use a pointer to code a la C as the test for or body of an "if", I
do have to introduce an operator to call it to make it operate as the
body of an "if".


To apply a code fragment to transform each element of an array a la
APL, I first have to construct the fragment as an object. If the
fragment began as text, I in effect have to compile the text to get a
fragment I can use.


Where's the trouble?


> 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.


And I'm also told the predefined cvx, cvlit, xcheck exist to set,
clear, test the _executable_ attribute bit of any object.


Agreed, yuck: every object carries state that completely redefines its
runtime behaviour.


I wonder what the point was?


The authors go out of their way to try and separate this issue from
their public/private privilege scheme e.g. the idea of "executeonly"
objects ... is that scheme somehow more relevant than they care to
admit?


> > ... lambda ...
> > ... non-portable "special forms" ...
> Lisp ... still need the "quote" special


I'm not sure I understand the question? Please help?


To represent a program textually, sure, we need all the usual literal
forms for number, string, and code in their infinite variations.


I'm not sure I understand why you emphasise this? In Common Lisp,
say, the need here is not only quote for lists but reader macros for
numbers and strings? I'm told quote is portable but reader macros are
not (except across Common Lisp)?


Did you mean there is a need for the predefined Lisp quote beyond
that?


In point of fact my compiler as it stands defines the quoted-list as
the root object for representing code. A valued-list is a quoted-list
that evaluates to mean some object other than itself. An
executable-list is an valued-list that evaluates by way of passing
itself thru to a pointer to code (java.lang.reflect.Method).


Is this how everyone does type-safe compilation?


I can conceive of commonly wanting to associate an executable-list
with some code that just returns its arg unchanged.


Is that what you meant by a need for the predefined Lisp quote?


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


I'm writing my Script Language Java .html interpreter on the side: I'm
focused on writing the least amount of code to get the job done. I
thought more elegant equalled smaller equalled simpler?


> if you want to make it efficient,
> you get even more complexity.


Efficient is goodness of course ... til now I've been running scared
of premature optimisation.


I'm having trouble ducking the cost of constructing a separate object
for each token parsed - minimum, for each node of the parsed tree. Do
any of the compilers that compete on the lines/second metric construct
that many small objects?? I figure for speed I'll have to allocate an
array of small objects and then manage the storage myself?


Compiling Java, I of course have lots of binary operators. I can
naturally enough reexpress the trinary ?: that way and I can supply a
dummy argument to reexpress the unary ~ ! + - that way.


But it feels painfully unnatural to contort, say, a list of subroutine
args into the binary form? I guess I'm supposed to create a separate
object to be the list?


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


Thanks again in advance.


Pat LaVarre p.lavarre@ieee.org http://members.aol.com/ppaatt/nqjava/

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