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, >>> >>> 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
