Evaluating/compiling forms in the current lexical environment.
in [Lisp]
|
From: Pascal J. Bourguignon on 30 Jan 2010 08:11 refun <refun(a)nospam.gmx.com> writes: > I think there's a third method which would involve collecting(flatten?) all > symbols in the form to be eval/compile'd and then checking if it exists in the > current lexical environment using that "Environment Access"(or CLTL2's > environments) library which is supposed by some implementations. The problem with these environment access libraries is that they're implementation dependant. > I'm a bit unsure about how one would go about "shadowing all lexically binding > operators" as you'd still need to know what they are, or did I misunderstand > your idea? Yes. Fortunately, they're all documented in CLHS, and macroexpand can be used to process those that a specific implementation may want to provide. >> However, once you want to allow things like (READ) to get the form, >> you may also want to prevent free access to the whole lexical scope! > > There may be other use scenarios besides READ, such as dynamically generated > code by some ??? to CL compiler. Of course. Here (READ) denotes a prototypal run-time generation of the form. -- __Pascal Bourguignon__
From: Duane Rettig on 30 Jan 2010 14:34 On Jan 30, 5:11 am, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > refun <re...(a)nospam.gmx.com> writes: > > I think there's a third method which would involve collecting(flatten?) all > > symbols in the form to be eval/compile'd and then checking if it exists in the > > current lexical environment using that "Environment Access"(or CLTL2's > > environments) library which is supposed by some implementations. > > The problem with these environment access libraries is that they're > implementation dependant. They don't have to be. The Environments Access module is explicitly designed to be portable, and follows closely what CLtL2 started with (with semantic bugs fixed). All of the major CL implementations I could get my hands on at the time were tested for "Level 1" porting (see the documentation and the powerpoint in the module), and it should not be hard for CL vendors to add what Level 1 porting is necessary. The only hard part is getting CL vendors to step up to Levels 2, 3, and finally 4. Only you as users can make that demand of your CL vendors. If you do so, the module will eventually become portable. Duane
From: budden on 31 Jan 2010 14:16
> In C and its ilk, would you expect this to fetch 3 into z? > > { > int x = 1, y = 2; > int z = some_expr_eval_lib_function("x + y"); > } > Do you know that there are several C implementations which have some form of "eval"? Cint is an interpreter, while tcc compiles to native code. As usual, instead of appreciating a help from a person who have made a very useful donation to CL (or at least tried to do), you begin senceless discussion. I guess your profession (or confession) is to help bury CL alive (which is still sometimes very useful). |