As I said earlier, global variables may be necessary when interfacing
with legacy things (software or hardware).
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML, or Java.
The Haskell philosophy has always been to stick it out until someone
comes up with the right solution to a problem rather than picking some
easy way out. So I'd rather keep global variables being eye sores (as
they are now) to remind us to keep looking for a nice way.
For people who don't like this philosophy there are plenty of other languages.
And this concludes my contributions on this matter. :)
-- Lennart
On Thu, Aug 28, 2008 at 11:06 PM, Yitzchak Gale
The "right" way to do these kinds of things is to provide some sort of context around the calling function. Something like withAcquiredResource $ \handle -> do ... You (and others) are right that this is better than trying to keep global state in the context of the called function.
The problem is that it is not always possible. There are situations in which you simply cannot make demands on a prior context. One important example is when refactoring a single component within an existing mature system. Another is when writing a library for general use if such demands on the calling context seem onerous for the service that the library provides (this latter is the situation for Data.Unique, according to many opinions).