From: Brian Candler <B.Candler@...>
Date: 2002-10-17T18:32:52+09:00
Subject: Re: Precompiling eval expressions

On Thu, Oct 17, 2002 at 06:54:27AM +0900, Nikodemus Siivola wrote:
> Procs are closures: they contain their enclosing environment (ie. as a
> pointer to a stack frame). This is cool because it enables you to create
> the kinds of functions you need, dynamically:

I kind-of got that bit already. It's clear that this cannot be a traditional
linear stack; that would destroy the existing data when the stack was
unwound and reused.

So I imagine that the stack must consist of a linked-list of frames, so that
unwinding to a previous point allows the tail end of the stack to remain in
existence; the "stack" would then fork to become a tree.

I was trying to work out whether defining a new variable ('t' in the
example from before) extends the current stack frame, or allocates and links
in a new frame:

           +-------+      +-------+      +-------+      +-------+
           | frame | <--- | frame | <--- | frame | <--- | frame |
           +-------+      +-------+      +-------+      +-------+
                                         "myproc"         "t"
                                         defined         defined
                                          here            here

But very annoyingly, I just tried the failed example from yesterday and it
now works!

myexpr = '"The time is #{t}"'
myproc = eval "Proc.new { #{myexpr} }"
t = 123
myproc.call
  => "The time is 123"

The only way I can get it to fail is:

myexpr = '"The time is #{t}"'
myproc = eval "Proc.new { #{myexpr} }"
myproc.call
  => NameError: undefined local variable or method `t'
t = 123
myproc.call
  => NameError: undefined local variable or method `t'

What's going on in the second case? Have I managed to split the stack frame,
or is there some deferred compilation going on??

Cheers,

Brian.