Re: Recursive environments (closures-related)

George Neuner <>
18 Jan 2007 11:30:46 -0500

          From comp.compilers

Related articles
Recursive environments (closures-related) (Pupeno) (2007-01-17)
Re: Recursive environments (closures-related) (Russ Cox) (2007-01-17)
Re: Recursive environments (closures-related) (Max Hailperin) (2007-01-18)
Re: Recursive environments (closures-related) (George Neuner) (2007-01-18)
Re: Recursive environments (closures-related) (George Neuner) (2007-01-18)
Re: Recursive environments (closures-related) (Max Hailperin) (2007-01-20)
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers
Date: 18 Jan 2007 11:30:46 -0500
Organization: Compilers Central
References: 07-01-050 07-01-057
Keywords: Lisp
Posted-Date: 18 Jan 2007 11:30:46 EST

On 17 Jan 2007 17:51:39 -0500, "Russ Cox" <> wrote:

>On 17 Jan 2007 17:31:39 -0500, Pupeno <> wrote:
>> I've done it differently and I'd like to know if my solution is
>> wrong. I first interpret the value of the binding and bind it to its
>> name creating a new environment. If the new value is a procedure then
>> I change its environment for the new one (the one that contains a
>> reference to itself) effectively creating the recursive
>> environment.
>Whether this is correct depends on whether there can
>be objects inside the closure with their own copies
>of the environment that was used during the "interpret the value" step.
>I would imagine that there can be, and therefore that
>this is not correct.
>For example, if we tweak your example so you are compiling
>(let* ((r (lambda (x)
> (let ((x' x))
> (if (zero? x')
> x'
> (r (- x' 1))))))
> (r 10))
>then I would imagine that the inner let creates an environment
>containing the x' binding, and that when you patch up the
>environment for the lambda closure, you do not also patch up
>the environment for the inner let.

The OP claims to be writing a meta-circular interpreter - not a

The posted code is equivalent to LET - it evaluates the lambda form
before extending the enclosing environment with the procedure's name.
However, the OP asserts that it correctly handles recursive
procedures, so the only questionable thing I can see would be a
reference to the procedure's name made within its nested LET.

Given the OP claim that recursive calls work properly, one of two
things must be true. Either the unseen lambda evaluation is a pseudo
compilation which takes place in an environment that includes the
procedure name and which would then enclose the nested LET, or all
names are resolved by runtime lookup in which case the extended
environment containing the procedure name would already be in place.


Post a followup to this message

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