[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: |
David Kastrup |
Subject: |
Re: [PATCH] local-eval, local-compile, and the-environment (v3) |
Date: |
Sun, 15 Jan 2012 19:26:48 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Mark H Weaver <address@hidden> writes:
> David Kastrup <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> David Kastrup <address@hidden> 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 implement. Consider this:
>>>
>>> (let ((x 1))
>>> (define (get-x) x)
>>> (the-environment))
>>>
>>> If we allow (the-environment) to add definitions to the implicit
>>> `letrec',
>>
>> Then just let's not allow it. Consider the body of local-eval to be
>> wrapped inside of an implicit (begin ...).
>
> I think you mean an implicit (let () ...). If that's what you want,
> then you can do it yourself, and the result will be less likely to
> confuse.
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 prohibited." we continue with "You
may consider the local-eval body as being wrapped inside of an implicit
(let () ...)."
I repeat: is there any valid construct under the currently proposed
local-eval code that would change its behavior?
>> Is there any currently valid construct that would change its
>> behavior? If not, you _gain_ functionality, and the resulting
>> semantics are still straightforward to explain as far as I can see.
>
> I don't understand this at all. Change what behavior?
The behavior of local-eval given arbitrary expressions. Are there any
expressions currently valid that would change their behavior if the body
of local-eval were wrapped in an implicit (let () ...)?
> What functionality do you gain?
The ability to make definitions valid in the local-eval without having
to write (let () ...). Again: any drawback that is more substantial
than "I just don't want you to do that"?
--
David Kastrup
- [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 <=
- 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, 2012/01/16
- 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