> Note that setenv() is not guaranteed to work.

Do you mean that the process might run out of memory for storing new
envars, or something more sophisticated?

> Generally speaking, I'd rather expose a constant value as a variable
> (which can't change outside the library it's defined in) than as a
> procedure.

The problem is that the Unix/C world's idea of PATH can change
independently of this variable. There is currently no mechanism in any
Unix to lock down any envars for the remainder of the process lifetime.
They are just a char** array in memory. You can even point 'environ' to
a completely different array and it works fine.

Also this SRFI's spawn procedures use the Unix/C world's idea of PATH,
i.e. the current value of environ (which I think is the right thing).

>     - In what situations would a programmer want to consult exec-path-list
>     instead of (getenv "PATH") or an (exec-path-list) procedure?
>
> It's more convenient than (getenv "PATH").  See above for my reasons for
> making it a variable.

But for what purpose - which applications find it convenient to get a
pre-parsed PATH that might be out of date and isn't used for anything by
the rest of the library?

> But if people think it should go, I have no problem with removing it.

I respect that. The main problem I have is that nobody has so far been
able to give it a rationale or any applications that I can understand :)
IMHO it also fits several patterns questionable design, as listed in the
last email.