Re: Post-22.1 development?

[David Kastrup <dak@gnu.org>]

Chong Yidong <cyd@stupidchicken.com> writes:

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

Done by manipulating the front of the list.

> or (ii) ensure that a change you make in process-environment affects
> the global environment too.

Done by manipulating the tail.

> 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.)

The point is not moot since setenv is supposed to have only local
effects if it is called after let-binding process-environment to a
copy of itself.

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

You'd use global-process-environment, which incidentally starts with
an empty string.

As to someone inserting spurious markers: that is actually nothing to
worry about.  People tampering with internals deserve what they get.

> Worse, there is no way to know for certain.

Which is just as well, since the mechanism is supposed to be workable
for _both_ sharing most of the environment as well as having most of
it disparate.  It keeps open our options for now without sacrificing
backward compatibility.

At one point of time we can close down various options, and at another
point of time we can close down backward compatibility.  This
implementation allows us to tackle this one step at a time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum