[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] local-eval, local-compile, and the-environment (v3)
From: |
Mark H Weaver |
Subject: |
Re: [PATCH] local-eval, local-compile, and the-environment (v3) |
Date: |
Mon, 16 Jan 2012 00:46:47 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
David Kastrup <address@hidden> 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 definition of x. But that's because of top-level. Eval
> is always top-level, and define acts like set! there.
Yes, top-level is a very different animal than an internal body, despite
the superficial syntactic similarities.
> 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. Unfortunately, there is a non-trivial
difference in the semantics of `eval' vs `local-eval'.
`eval' temporarily sets the (current-module) to its second argument
during evaluation of the expression.
`local-eval' does not do this, and as I recall that was something you
felt strongly about (and I agree).
> And one could then define
> (define current-module
> (let ((top-level (the-environment)))
> (lambda () (eval '(the-environment) top-level))))
> if the-environment just returns the current module when at top level?
I see what you're getting at, but this would be a bad idea, because it
still makes sense to have `module' be an independent type.
Also, in the code above, `top-level' would not actually be a top-level
environment, because (the-environment) is not a top-level form. If you
put (define x 5) in place of (the-environment), it would not set a
top-level variable; it would produce an error.
Mark
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), (continued)
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/15
- Re: [PATCH] local-eval, local-compile, and the-environment (v3),
Mark H Weaver <=
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/16
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/16
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/16
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), Mark H Weaver, 2012/01/16
- Re: [PATCH] local-eval, local-compile, and the-environment (v3), David Kastrup, 2012/01/16