Related articles |
---|
Internal code representation. markg@athens.emi.net (1995-10-14) |
Re: Internal code representation. sgt20@cam.ac.uk (1995-10-23) |
Re: Internal code representation. ganswijk@xs4all.nl (Jaap van Ganswijk) (1995-10-23) |
Newsgroups: | comp.compilers,comp.programming,comp.lang.misc |
From: | markg@athens.emi.net (Mark Grosberg) |
Keywords: | interpreter, question |
Organization: | EmiNet Domain Internet Services (407)731-0222 |
Date: | Sat, 14 Oct 1995 06:27:42 GMT |
Hello there.
I am currently coding yet another (experimental) language interpreter.
In all of my previous intepreters I used a RPN-based stack representation
once code was absorbed and a stack to do evaluation.
Lately, I have not been happy with that solution because:
(1) I have to allocate a chunk of memory for a stack.
(2) Can't modify the code at runtime as easily because the
internal representation doesn't look much like the actual
code
(3) Haven't figured out a good way for lazy evaluation yet.
One method of internal code representation that I did think of was
(similar to Lisp) each function call consisted of an array of the
parameters to that function, and at execute time, that pointer was passed
to the evaluator.
The problem with this is if you have a function, f(a)=(a+a) and you call
it with f(sin(1))
sin(1) gets evaluated twice. While sometimes this is desierable
behaviour, sometimes it isn't.
I am trying to find a compromise between these two cases as in this new
language I am exploring continuations (and some forms stuff) and would
like the ability to pass code around and have it executed as many times
as necessary (think of a "for-each" function here).
One way of doing this is dynamic binding, but I don't have much
experience with this.
Any help or hints towards a good internal code representation would be
appriciated, preferrably one that is both efficient and supports lazy and
iterated parameter evaluation.
Thanks guys,
Mark G.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.