Message from discussion Lexical environment access at runtime
Subject: Re: Lexical environment access at runtime
References: <firstname.lastname@example.org> <email@example.com>
From: Joel Ray Holveck <jo...@piquan.org>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix)
Content-Type: text/plain; charset=us-ascii
X-Trace: newssvr27.news.prodigy.com 1068199717 ST000 184.108.40.206 (Fri, 07 Nov 2003 05:08:37 EST)
NNTP-Posting-Date: Fri, 07 Nov 2003 05:08:37 EST
Organization: SBC http://yahoo.sbc.com
Date: Fri, 07 Nov 2003 10:08:37 GMT
>> Is there a way for running code to find out, based on a symbol (not
>> known at compile time), what the current lexical value for that symbol
> The easy proof of that is this:
> (defun foo ()
> (let ((x 3))
> #'(lambda () x)))
Thanks for the response. Let me clarify my question. When I said
"running code", I meant "code that I write, running within the lexical
environment I'm trying to probe". So it can have variable accesses to
X that prevent it from being folded away, or whatever else.
So while I agree with you for the general case, I don't think that
proof applies for the special case when I have the luxury of running a
code-walker over the code, instrumenting it before it's submitted to
I apologize; my initial paragraph (the one you quoted) was unclear, or
rather less specific than it should have been. I don't have the
symbol name at compile time, but I can make adjustments to the code at
compile time, so long as the function still does what it's supposed
to. In the example I listed later in the message, it instruments the
user-supplied function to call my own code.
The good news about that case is that I can put whatever additional
code I need in there, to add variable accesses that would prevent the
X in your example from being folded away. The bad news is that, in
the only general solution I've figured out so far, it would require a
list of current lexical bindings (at compile-time), which is what led
to my second question (about MAP-ENVIRONMENT).
I was hoping to avoid making the code-walker look for forms that
create new lexical bindings. (I'll have the complete top-level form,
so I can start from a null lexical environment.) Needing to do that
makes the code walker more complex, it couldn't handle
implementation-defined special forms that create new bindings, and
would require almost a complete implementation of complex
binding-creating forms like LOOP.
>> How about for a macro to find out what lexical bindings exist in
>> an &environment variable, like the proposed MAP-ENVIRONMENT?
> Not in the standard.
Nuts. At this point, that's really what's keeping me from writing The
Debugger I Always Wanted. ANSI CL is *so* close to what I want, but
just not quite there.
Thanks for your help,
Joel Ray Holveck - jo...@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped