On 16 Dec 2011, at 13:43, David Kastrup wrote: >>> Here's what I currently see: >>> >>> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42)) >>> (or #f (the-environment))))) >>> ERROR: In procedure memoize-variable-access!: >>> ERROR: Unbound variable: t >>> >>> This is the correct behavior, no? >> >> This is what I get when I play around with the following variation of >> David's code in Guile 2.0.3: >> (define (xxx) >> (let* ((x 2)) >> (set! x (+ x 3)) >> (interaction-environment))) >> >> (eval '(begin (set! x (+ x 5)) x) (xxx)) >> >> My guess (correct?) is that one wants some variation of >> (interaction-environment) that can cause x in the eval expression to >> bind to the environment returned by (xxx). >> >> Might eval be changed to accommodate for that (without introducing the >> name local-eval)? > > It would likely help with unasking the question of what to do when > (current-module) is different at the time of local-eval. I don't know, > however, what the _lexical_ effects of switching the current module are > supposed to be. If it is supposed to be a noop, then lexical > environments and modules are presumably orthogonal, and eval should > likely be allowed to take both (currently, local-eval is like taking a > lexical environment and using primitive-eval in it).
Would you not it work as though you inserted code in the place where then environment? - Then the syntactical rules should be captured as well. In addition, there should be a way to communicate with the surrounding environment, wherefrom the code is inserted. The only truly safe way would be to make that explicit somehow, if not merely returning a value suffices. Hans
