David Kastrup d...@gnu.org 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) environment) is a no-op: it always
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 to
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org 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
Mark H Weaver m...@netris.org 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
David Kastrup d...@gnu.org 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
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org 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,
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
I am not sure that the reasons for not permitting definition context in
local-eval are not of somewhat
David Kastrup d...@gnu.org 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
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org 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
David Kastrup d...@gnu.org 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
Mark H Weaver m...@netris.org 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.
David Kastrup d...@gnu.org 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
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
13 matches
Mail list logo
