Old-Received: from eli.CS.YALE.EDU by vanuata with SMTP (MMTA) with ESMTP;
Tue, 14 Jan 1997 22:51:49 +0000
Old-Received: from curry.cse.ogi.edu by eli.CS.YALE.EDU
(8.7.1/res.host.cf-4.0) with SMTP id RAA06555; Tue,
14
Jan 1997 17:51:45 -0500 (EST) sender [EMAIL PROTECTED]
for <[EMAIL PROTECTED]>
Old-Received: by curry.cse.ogi.edu (Smail3.1.29.1 #8) id m0vkHhm-0004u9C;
Tue, 14 Jan 97 14:51 PST
Date: Tue, 14 Jan 97 14:51 PST
From: Sigbjorn Finne <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
....
However, passing around option values to the different parts of your
program is a major bore, so what about instead treating argv for what
it really is, a constant, and make it available as such
(System.argv :: [String]), say. Having it as constant has the nice
property that your program's option values can now be turned into
CAFs, and you'll avoid all the pains of plumbing, i.e.,
....
I know you could go wild with monads, c. classes etc. and try to
squirrel away these things, but argv is a constant (in a sane world),
so why not treat it as such (ditto for the environment)? Thoughts?
--sigbjorn
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.
I like the idea of making the environment constant, but I think the
tools for manipulating them will still be needed.
--
Clifford Beshers Computer Graphics and User Interfaces Lab
[EMAIL PROTECTED] Department of Computer Science
http://www.cs.columbia.edu/~beshers Columbia University
