[plt-scheme] Question about eval and environments

Oh! (to reply to myself ...)

Its not just compilation in that first paragraph. Indeed, the more
important reason is that you, the programmer, know that certain things
just cannot happen so therefore you can make better predictions about
the behavior of your program and thus can more easily write programs
that Work(tm). There is a delicate balance, however, between the
ability to change more things (and thus give you more flexibility) and
to disallow changes (and thus to let you reason more easily) and one
that is important for designing a PL.

Robby

On 10/25/07, Robby Findler <robby at cs.uchicago.edu> wrote:
> The in-long answer has to do with compilation. If you can make
> assumptions about your program (eg, you can assume that no one refers
> to a variable by its name after compilation) then you can do a better
> job with the compilation of those variables (ie turn them into static
> offsets in a stack or similar). In Scheme you can even tell more. You
> know, at compile time, if a variable may be mutated -- just look for a
> set!. If you don't find one, you can do even fancier tricks. If, on
> the other hand, you could reify the lexical environment as an assoc
> list, then you lose that.
>
> Of course, there is always even more to the answer. For example, in
> PLT Scheme, we implement debugging support by instrumenting the
> program with extra code that will be invoked when the debugger kicks
> in. That's how the debugger can report information about the program.
> If you just want to be able to change values of variables while
> debugging, that's presumably a something that could be done by
> inserting assignment expressions into your program, ie the debugger
> could support that.
>
> Robby
>
> On 10/25/07, Mike J. Bell <ckimyt at gmail.com> wrote:
> > Ok, will do.
> >
> > How about "in long?"  Why can't eval bind to an environment that encompasses
> > the lexical closure I made?
> >
> > Mike
> >
> >
> > On 10/25/07, Chongkai Zhu <czhu at cs.utah.edu> wrote:
> > > Mike J. Bell wrote:
> > > > I don't think this is PLT specific, so I apologize if this should be
> > > > on a more general scheme list.
> > > >
> > > > I'm interested in adding a generic hook to evaluate a piece of code at
> > > > an arbitrary point in my program.  This would be useful for debugging
> > > > purposes.  For instance:
> > > >
> > > > (let ((x 5))
> > > >   ;(do a bunch of stuff with x)
> > > >   (write (eval (read))))
> > > >
> > > > Obviously this isn't very useful outside of a loop or other more
> > > > complicated idea, but this is just a toy to show the problem.  When
> > > > (read) runs, I would like to type in something like:
> > > >
> > > > (set! x 7)
> > > >
> > > > This doesn't work.  The error is that 'x' is unbound.  So I tried:
> > > > ...
> > > >   (write (eval (read) (interaction-environment))))
> > > >
> > > > and that didn't work either.  It seems like I can't get to the
> > > > environment that contains the lexical closure created by the initial
> > > > (let...).
> > > >
> > > > Is there any way around this?  I supposed I could write my own (mini)
> > > > version of eval, but that seems pretty extreme.  How can I get access
> > > > to the lexical environment at the point (eval) is executed so I can
> > > > inject arbitrary code?
> > >
> > > In short, you can't. So try some other way to do the debug, say using
> > > the debug tool.
> > >
> > > >
> > > > Thanks for any tips!!!
> > > >
> > > > Mike
> > > >
> > > > --
> > > > Mike J. Bell on gmail
> > > >
> > ------------------------------------------------------------------------
> > > >
> > > > _________________________________________________
> > > >   For list-related administrative tasks:
> > > >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > > >
> > >
> > >
> >
> >
> >
> > --
> > Mike J. Bell on gmail
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >
>