Related articles |
---|
Compiler project needed pel@realtime.dk (Per Olesen) (2000-02-22) |
Intermediate Language in Interpreter lojedaortiz@interlink.com.ar (Nicolás) (2000-03-23) |
Re: Intermediate Language in Interpreter cbrtjr@ix.netcom.com (Charles E. Bortle, Jr.) (2000-03-23) |
Re: Intermediate Language in Interpreter mihai@cs.wisc.edu (Mihai Christodorescu) (2000-03-23) |
From: | Mihai Christodorescu <mihai@cs.wisc.edu> |
Newsgroups: | comp.compilers |
Date: | 23 Mar 2000 23:18:59 -0500 |
Organization: | UWisc - CS - http://www.cs.wisc.edu/~mihai |
References: | 00-02-112 00-03-096 |
Keywords: | interpreter |
> So, my question is what kind, or the characteristics, of languge is
> convenient to be interpreted.
>
> [It's certainly feasible, but some kind of reverse polish is usually
> faster to interpret. -John]
Notwithstanding the difference between "more convenient to
interpret" and "faster to interpret" in the above snippet, I am
curious about the assertion about RPN. I do not have enough experience
with writing interpreters to back this up, but my guess is that prefix
(PN) and postfix notations (RPN) would be equally hard or easy to
interpret. Furthermore, it seems that prefix notation would generate
better error messages (once you see the operator, you know what type
of operands you expect).
Why is RPN easier to interpret? Somebody show me the light, please.
Mihai
--
Mihai Christodorescu -=- mihai@cs.wisc.edu - http://www.cs.wisc.edu/~mihai
[You can interpret RPN with a single stack for data. Each operator pops
its operands from the stack and pushes its result back on the stack, and
you just chug through the RPN ops in sequence. To interpret prefix code,
you need a recursive interpreter to walk the tree and match up operators
and operands, and it has to stack both intermediate values and positions
in the tree. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.