[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hans Aberg
Subject: Re: summary: lilypond, lambda, and local-eval
Date: Fri, 16 Dec 2011 15:57:26 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]