[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator
From: |
Mark H Weaver |
Subject: |
Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator |
Date: |
Fri, 16 Dec 2011 10:27:36 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Peter TB Brett <address@hidden> writes:
> David Kastrup <address@hidden> writes:
>
>>> * I still wouldn't be surprised if `local-eval' does the wrong thing if
>>> (current-module) is different from what it was when the associated
>>> `primitive-eval' was called.
>>
>> Before anyone even _defines_ what the "right thing" would be, there is
>> little point in worrying about this. I don't think that `local-eval'
>> 1.8 documented any behavior for this case (well, it did not document any
>> behavior for a lot of cases).
>>
>> So it probably makes sense to look afterwards what will happen without
>> special precautions, and unless that is spectacularly useless or
>> inconsistent, call it the "right thing" by definition.
>
> Maybe it makes even more sense (at this stage) to state that the
> behaviour in this case is undefined?
To my mind, top-level (module) variables are conceptually part of every
lexical environment placed within that module. For example, code like
this:
(define (factorial x)
(if (zero? x) 1
(* x (factorial (- x 1)))))
should act as one would naturally expect (assuming that factorial is not
later set!), whether it is placed within a local block or placed at the
top-level of some module.
It would be crazy for any lexical environment "search path" starting
from within factorial's definition block to lead to a different module
than the one where `factorial' was defined.
In other words, in the following example, any variable lookup that would
lead to `foo2' should also lead to the `foo1' (assuming it's not
shadowed by a lexical binding).
(define foo1 #f)
(let ((foo2 #f))
<insert any code here>)
As an interesting case, suppose that you define the following macro in
module A:
(define foo 'module-a)
(define-syntax alt-environment
(syntax-rules ()
((_) (the-environment))))
and then evaluate the following within module B:
(define foo 'module-b)
(local-eval 'foo (alt-environment))
What should the result be?
My guess is that it should return 'module-a, because I think
conceptually it should act as though the local-expression passed to
`local-eval' were put in place of (the-environment), wherever that
might be.
Thoughts?
Mark
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, (continued)
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Noah Lavine, 2011/12/13
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Mark H Weaver, 2011/12/13
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Mark H Weaver, 2011/12/14
- [PATCH] Implement `capture-lexical-environment' in evaluator, Mark H Weaver, 2011/12/14
- Re: [PATCH] Implement `capture-lexical-environment' in evaluator, David Kastrup, 2011/12/14
- Re: [PATCH] Implement `capture-lexical-environment' in evaluator, Mark H Weaver, 2011/12/14
- [PATCH] Implement `the-environment' and `local-eval' in evaluator, Mark H Weaver, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, David Kastrup, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, Peter TB Brett, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, David Kastrup, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator,
Mark H Weaver <=
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, Andy Wingo, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, Mark H Weaver, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, Mark H Weaver, 2011/12/16
- Re: [PATCH] Implement `the-environment' and `local-eval' in evaluator, Hans Aberg, 2011/12/16
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Andy Wingo, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Andy Wingo, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Andy Wingo, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Mark H Weaver, 2011/12/14