On Apr 21, 2006, at 10:34 AM, Brian Hulley wrote:
Robert Dockins wrote:
On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote:
Hi -
I've run into the global mutable state problem described in http://
www.haskell.org/hawiki/GlobalMutableState
Since the page was last edited in March last year, I'm wondering if
there have been any developments or further thoughts on how to
safely create top level IORefs since they are absolutely essential
for the library I'm writing.
For my library, which implements a GUI, I have a Manager module
which keeps track of which control currently has the keyboard focus
etc, and I don't want to have to pass round the state of the
manager to every control since this would be monstrously
inconvenient and a total waste of space/time, so at the moment I'm
reduced to:
module Manager where
keyboard :: IORef (Maybe Control)
{-# NOINLINE keyboard #-}
keyboard = unsafePerformIO $ newIORef Nothing
The problem is that I don't know if this is guaranteed to be
completely safe for all Haskell compilers or even for all future
versions of ghc (?)
RE: the technique itself, you should also compile the module with -
fno-cse.
Thanks
RE: the design, Isn't that bit of state local to a dialog/window/
control group or something? I understand that top level state is a
problem in general that needs some sort of solution, but I'm not sure
it's the right hammer here....
There is only one GUI for the application and only one control in
it can have the keyboard focus so it seems natural to use global
state here
I'd suggest you consider not making those assumptions... they are the
kinds of assumptions that can make later code reuse and maintenance
more difficult than it should be. (Obviously, if code reuse/
maintenance is a low priority then it doesn't matter).
, but I suppose I could also look into using a state monad. The
advantage (perhaps also disadvantage ;-) ) of global state is that
it allows me to easily convert all my old C++ singleton classes to
Haskell modules...
<ramble type="somewhat coherent">
Ahhh... the singleton pattern. There is a debate among OO theorists
about whether the singleton pattern is actually a good idea. I tend
to side with those who say that it is Just Wrong. The reality is
that "singletons" are only unique within some scope (OS process, VM,
sandbox, whatever). "Global" state is similar; it is always bounded
by _something_. I think its always better to make the boundaries
explicit and aligned with the problem domain rather than implicit,
because the implicit boundaries sometimes/often don't do what you
want. As soon as you have an even slightly unusual execution
environment, your assumptions can be violated (eg, within Java
application containers *shudder*). I have to imagine using, eg, HS
plugins with modules containing top-level state could cause all sorts
of havoc.
</ramble>
As far as I know, the only recent developments in this area are a
rumor from the Simons that they are working on some sort of thread-
local state which (under some sets of design decisions) can fill the
needs of top level state. If you press them, they might be willing
to give some details about this.
I was kind of hoping that there would just be a safe, simple way to
create a top level monomorphic IORef without having to use a pragma
etc.
I don't think that exists currently.
Thanks, Brian.
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
