Re: summary: lilypond, lambda, and local-eval

[Hans Aberg <haberg-1@telia.com>]

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