[Haskell-cafe] Current situation regarding global IORefs
robdockins at fastmail.fm
Mon Apr 24 15:31:46 EDT 2006
On Apr 24, 2006, at 2:42 AM, Adrian Hey wrote:
> Lennart Augustsson wrote:
>> I think global mutable variables should be regarded with utmost
>> suspicion. There are very few situations where they are the
>> right solution.
> Well IMO even the use of the term "global mutable variable" causes
> muddled thinking on this and I wish people would stop it. There's no
> reason to regard top level "things with identity" (call them "TWI"s
> or "objects" or whatever) with any more suspicion than top level IO
> actions themselves.
Sure there is. TWI's are just the object-oriented singleton pattern
warmed over, and the singleton pattern is much maligned in some
circles (for good reason, IMO).
> One thing I never could fathom about the position of the nay-sayers
> in this debate is what exactly is it that they object to?
> Is it existence of top level "TWI"s and of IO operations that
> reference them *in principle*?
> Or are they content with their existence but just don't want to
> allow people to use Haskell to define them?
The former, in my case. As I stated in an earlier message, the
problem is primarily one of defining the dynamic scope of the thing.
If you look back in the archives, you'll notice I proposed a thread-
local state mechanism because I felt it placed the scope boundary in
an appropriate place, where it could be manipulated and reasoned
about by programmers, and where it has a reasonable semantic
interpretation. Presumably, runtime models will have to deal somehow
with the notion of a thread of execution (even if just to say there
is only ever one) and will thus fix the dynamic scope of thread local
I additionally think that thread-local state (and similar mechanisms)
can be abused to create difficult-to-maintain and buggy code, but
that's a somewhat separate issue.
> If it's the former then we should be purging the IO libraries of
> all such horrors, though I can't see much remaining of them (well
> anything actually). But I guess an IO incapable language might
> still have some niche uses.
Argument by straw-man: there are important differences between
regular IO actions and TWI's, AKA singletons. The former is
referentially transparent, while the latter is referentially opaque,
for starters. There's also the scoping issue: the properties of the
IO monad bound the dynamic scope of regular IO actions, but not so
> If it's the latter then we are advocating a language which cannot
> be used to implement many demonstrably useful IO modules and
> *by design*. If so, the claim that Haskell is a general purpose
> programming language seems quite bogus and should be removed from
> the haskell.org home page IMO.
You presuppose that a language which "cannot be used to implement
many demonstrably useful IO modules and libraries" is not general
purpose. I claim that is silly. If we take that argument to its
logical conclusion, then we should throw out static typing,
referential transparency and most of the things that make Haskell
what it is. I think that what a programming language keeps you from
doing is as least as important as what it lets you do. If you don't
believe that at least to some extent, then your first exposure to
Haskell probably made your head explode.
That said, I also disagree with the premise. I don't know of any
stateful library designs that can't be pretty straightforwardly
refactored using explicit initialization and ReaderT-over-IO monads.
Furthermore, I believe that a library so structured is actually
_more_ useful than the library with implicit state.
> Adrian Hey
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
More information about the Haskell-Cafe