My, what a firestorm! The Haskell mailing list springs to life.
Frank writes
| First, Simon, I think you're a little biased on this issue. I'm sure that
| making argv a global constant would be a practical benefit for programs like
| GHC.
You're probably right. I am certainly biased towards large programs.
But I really want Haskell to scale to large programs, rather than become
unreasonably inconvenient to use when the program becomes big.
| nooks and crannies of a program. Most applications are not nearly so
| configurable,
I disagree! Most "real" programs (i.e. products) are highly configurable.
| Suppose, for example, as Sverker suggested that instead of setting the
| arguments via the command-line, you set them by reading in a file of argument
| settings, one per module. Then you would be stuck with implementing the
| argument-passing plumbing anyway.
I think this is a really good point, and I don't have a good answer for it.
(see below)
| Third, I could say that choosing to use a functional language is in some
| sense also accepting the fact that you are "forced to accept some benefits"
| which you could do without.
I don't agree. In exchange for the costs of higher-order functions, or
laziness, or the lack of side effects, I get some benefits. In exchange for
making argv accessible only via an IO action I get nothing at all.
| Fourth, the advantage you claim to get from global flags could also be
| gotten from using a reader monad: not only does it hide the plumbing, but it
| also explicitly indicates that the value is constant. And last time I looked,
| GHC was overflowing with monads
The outer structure is heavily monadised but there are hundreds and hundreds
of non-monadic functions. It is *not* a routine matter to get the
arguments to a randomly chosen place.
Lennart writes, of Frank's idea
| > timeStarted :: performOnceBeforeMain (getCurrentTime)
| >
| > Just like that one would do with unsafePerformIO, but with
| > safer semantics (hopefully) and blessed by Standard Haskell.
|
| I agree. Even if this particular mechanism needs some extra
| restrictions to be safe I would prefer this to the hack of
| just making argv a global constant. This is a hack too, but
| at least it's generalized.
This would solve the "read options from a file" problem, which I like.
But, it's not clear what the "restrictions" would need to be. Any ideas
anyone?
| I've sinced changed my mind, maybe it is "a functional programmers
| deathwish", but I find the case where you are explicit about what a
| function depends on to be more honest and true to the FP spirit.
| I've also found it practically useful since you can then change the
| values of the given flags locally (which you couldn't do with a global
| argv).
When I need that benefit, then I'm willing to pay the cost. What bugs me is
paying the cost simply to be true to the spirit of FP without getting any
benefit. Maybe I'm just getting old an cynical. But I still believe in
lazy evaluation so you can't dispose of me altogether. :-)
Simon
