Clifford Beshers writes:
>
> I just want to note that treating the environment as a constant is
> probably not a good idea. Because environments are passed to execve,
> inherited by sub-processes, it must be possible to change,
> or at least shadow, them.
>
> If I were re-writing emacs in Haskell, for example, I would want to be
> able to modify the environment of the current process before forking a
> sub-process. Emacs has this function (setenv), and it is very useful
> for adjusting PATH, etc.
>
Yes, I might be pushing my luck with making the environment appear as
constant, but the examples you give of side-effecting the environment
can be dealt with properly functionally, i.e., only provide execve in
Haskell for the exec* family:
execve :: String -- path
-> [String] -- argv
-> [String] -- env (abstract?)
-> IO ()
and in that way control what is passed.
For your Haskell Emacs, it could handle `setenv' by threading the
environment changes you want to apply in future sub-processes. IMHO,
this would be cleaner, in elisp, `setenv' does not cause previous
applications of `getenv' to be re-evaluated upon doing a `setenv', for
instance.
> I like the idea of making the environment constant, but I think the
> tools for manipulating them will still be needed.
>
Agreed, but functional ones :-)
Just a thought,
--sigbjorn
