Related articles |
---|
Precedence values for Reverse Polish nerd@freeuk.com (Nerd) (1999-10-27) |
Re: Precedence values for Reverse Polish cbrtjr@ix.netcom.com (Charles E. Bortle, Jr.) (1999-10-29) |
Re: Precedence values for Reverse Polish lex@cc.gatech.edu (1999-10-31) |
Re: Precedence values for Reverse Polish ppaatt@aol.com (1999-10-31) |
Re: Precedence values for Reverse Polish nerd@freeuk.com (Nerd) (1999-10-31) |
Re: Precedence values for Reverse Polish anton@mips.complang.tuwien.ac.at (1999-11-02) |
Re: Precedence values for Reverse Polish ppaatt@aol.com (1999-11-02) |
Re: Precedence values for Reverse Polish anton@mips.complang.tuwien.ac.at (1999-11-03) |
Re: Precedence values for Reverse Polish ppaatt@aol.com (1999-11-05) |
[2 later articles] |
From: | lex@cc.gatech.edu |
Newsgroups: | comp.compilers |
Date: | 31 Oct 1999 01:26:33 -0400 |
Organization: | Georgia Institute of Technology, Atlanta GA, USA |
References: | 99-10-124 |
Keywords: | parse, code |
One thing to think about is the influence on your evaluator.
Specifically, if you have a stream like this:
n 0 >
'ans' ans ans 1 - * :=
while
Then a straightforward evaluator would evaluate the (n 0 >) part long
before the while was seen. When the while came up, the stack would
look something like this:
true
11
What you might want to add is the notion of a deferred routine. HP48
calculators write this using << and >> characters. The above example
would be vaguely like this:
<< n 0 > >>
<< 'ans' ans ans 1 - * := >>
while
If you have this "deferred routine" thingie (I dunno what HP's call
them; I think of them as "lambdas" :)), then your RPN evaluator can
remain extremely simple.
Lex
"Nerd" <nerd@freeuk.com> writes:
> Also, I'd like to extend it to convert:
>
> if a = b then c := 1 else c := 2 to a b = c 1 := c 2 := if
>
> So "if" is a trinary operator. Or, since my language allows it:
>
> c := if a = b then 1 else 2 to c a b = 1 2 if :=
Return to the
comp.compilers page.
Search the
comp.compilers archives again.