Re: Post-22.1 development?

[Chong Yidong <cyd@stupidchicken.com>]

Richard Stallman <rms@gnu.org> writes:

>     There are two clean ways to do this is: (i) extend process-environment
>     so that if a symbol occurs in the list, as opposed to a string, that
>     symbol names a list whose elements are to be used (as though they had
>     been inserted in process-environment).  Then the final element for all
>     default values of process-environment would include the symbol
>     `global-process-environment'; or (ii) extend process-environment so
>     that an element of `t' means "the global value of this variable"
>     (similar to hook variables).
>
> These are more elegant, but I am not sure it matters in practice.
>
>     Either of these approaches would be backward compatible for
>     third-party than the shared-tail idea, but IMHO the gain in
>     cleanliness more than makes up for it.
>
> I don't think so, and the reason is that this won't clean
> up the code in Lisp programs at all.  On the contrary, it would
> complicate them.
>
> In other words, elegance of the mechanism is not the same thing
> as simplicity of the user code.
>
> We use method ii for hooks, but the complexity is hidden inside
> two standard functions.

In this case, there are setenv and getenv.

As for whether elegance of the mechanism matters in practice, consider
the case where you want to (i) change a variable in the local
environment and leave the global one unchanged, or (ii) ensure that a
change you make in process-environment affects the global environment
too.  Assume you don't want to use setenv and getenv (if you do use
setenv and getenv, the point is moot, since the more elegant mechanism
wins anyway.)  With the shared-tail mechanism, you would need to grep
for the empty string "", and hope that that's really the correct
marker separating the local and global lists, not a spurious marker
inserted by someone else.  Worse, there is no way to know for certain.