Mark H Weaver writes:
> David Kastrup writes:
>
>> (define current-module
>> (let ((top-level (the-environment)))
>> (lambda () (eval '(the-environment) top-level
>
> Some more notes about the above code (changing `eval' ==> `local-eval'):
>
> * (local-eval '(the-environment) ) is a no
I wrote:
> * Also note that the real `current-module' simply accesses a fluid,
> which can also be set by `set-current-module'. (Fluids are a scheme
> analogue to "dynamically-scoped" variables in Lisp). Conceptually, it
> is variable that is explicitly set by the user. It has no relation
David Kastrup writes:
> (define current-module
> (let ((top-level (the-environment)))
> (lambda () (eval '(the-environment) top-level
Some more notes about the above code (changing `eval' ==> `local-eval'):
* (local-eval '(the-environment) ) is a no-op: it always
returns the same en
David Kastrup writes:
> It might come handy to have local-eval not balk upon getting a module,
> but without letting it set the current module.
Agreed, and my implementation of `local-eval' does exactly that.
Mark
Mark H Weaver writes:
>> What if the-environment had been taken at top-level (basically just
>> carrying the information of (current-module))? Should local-eval then
>> behave accordingly? If so, could we not just fold eval and local-eval
>> into one function?
>
> This is a good question. Unfo
David Kastrup writes:
> guile> (let ((x 2)) (eval '(begin (define x 4) x) (current-module)))
> 4
> guile> x
> 4
> guile>
>
> Right through to the top. And we couldn't do that in local-eval. But
> it also has no qualms just because previously evaluated forms would have
> used a previous definitio
David Kastrup writes:
> In the light of local-eval evaluating a _form_ rather than a _body_
> (stupid of me to forget), and seeing the weird semantics of begin, I
> agree that an implicit (let () ...) wrapper for a single form does not
> really appear to add significant gains. It would be margin
Mark H Weaver writes:
> David Kastrup writes:
>
>>> You are suggesting that we wrap the expression within a (let () ...),
>>> for the dubious benefit of allowing you to wrap the local forms in
>>> (begin ...) instead of (let () ...).
>>
>> Are there even situations where you could put definition
David Kastrup writes:
>> You are suggesting that we wrap the expression within a (let () ...),
>> for the dubious benefit of allowing you to wrap the local forms in
>> (begin ...) instead of (let () ...).
>
> Are there even situations where you could put definitions after begin?
> How are they di
Mark H Weaver writes:
> David Kastrup writes:
>
>> What is confusing here? "Obviously, definitions made in the scope of
>> local-eval can't retroactively affect the environment where
>> the-environment was called." And now instead of continuing with the
>> unfriendly "For this reason, they are
David Kastrup writes:
> Mark H Weaver writes:
>
>> David Kastrup writes:
>>
>>> Mark H Weaver writes:
>>>
David Kastrup writes:
> I am not sure that the reasons for not permitting definition context in
> local-eval are not of somewhat more theoretical than practical nature,
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> David Kastrup writes:
>>>
I am not sure that the reasons for not permitting definition context in
local-eval are not of somewhat more theoretical than practical nature,
>>>
>>> There's at least one practi
David Kastrup writes:
> Mark H Weaver writes:
>
>> David Kastrup writes:
>>
>>> I am not sure that the reasons for not permitting definition context in
>>> local-eval are not of somewhat more theoretical than practical nature,
>>
>> There's at least one practical reason not to allow it, namely
Mark H Weaver writes:
> David Kastrup writes:
>
>> I am not sure that the reasons for not permitting definition context in
>> local-eval are not of somewhat more theoretical than practical nature,
>
> There's at least one practical reason not to allow it, namely that it is
> _impossible_ to impl
David Kastrup writes:
> I am not altogether comfortable with pushing a "temporary fix" for the
> sake of LilyPond when we'll get another behavioral change with the next
> version.
But there would _not_ be a behavioral change in the next version.
It would only be a change in the internal implement
Mark H Weaver writes:
> Here's the third version of my simple `local-eval' patch.
> Notable changes from last time:
>
> * Pattern variables are now captured properly.
> * `the-environment' now works as advertised within macro definitions.
> * Added doc strings for `local-eval' and `local-compile'
Hello all,
Here's the third version of my simple `local-eval' patch.
Notable changes from last time:
* Pattern variables are now captured properly.
* `the-environment' now works as advertised within macro definitions.
* Added doc strings for `local-eval' and `local-compile'.
I am open to reimple
17 matches
Mail list logo
