Please take this message in the fashion that is intended. My criticism
is light hearted, as I believe yours is.
Adrian Hey wrote:
[hack snipped]
BTW, this is the commonly the subject of flame wars on the Haskell
mailing lists because there appear to be many who passionately believe
and assert that so called "global variables" are (at best) unnecessary
and (at worst) are "evil". These people are quite simply wrong and
should be ignored :-)
Adrian Hey is not only wrong, but actually evil. He should be ignored. :-)
The above hack is not actually Haskell. It's a hack, and it depends on
the particular implementation characteristics of GHC. It is not
unreasonable to imagine that a future GHC might contain different
compilation techniques (I hesitate to use the word 'optimisations'
because that sounds like something easy to turn off) which invalidate
the technique in other ways or make it dangerous.
They are necessary because they are the only way to ensure important
safety properties of many IO APIs.
That's a bold claim. It's very hard to prove that things don't exist.
(That is, that other ways to ensure these safety properties don't
exist). In snipped text you comment that the problems are often in
low-level FFI library code: this makes me wonder if the real culprit
doesn't lie at the FFI-haskell boundary. Perhaps there are good ways to
specify this kind of invariant there.
If you want to see more examples of the use of the unsafePerformIO
hack you need only look at the source code of the current base
package (you'll find a dozen or so uses of this hack to create
top level mutable state).
All of these are, in a sense, failings. Because unsafePerformIO is not
haskell, and we'd like base to be a haskell library. Not a GHC library.
I'd be willing to take a sportsman's bet that the original poster
does not actually need to use this hack; I doubt his application falls
into the categories you have outlined. I would discourage people from
using this hack unless it is, in fact, the only feasible approach.
Jules
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
