Go look at accursedUnutterablePerformIO (aka inlinePerformIO) sometime.
IO's just a barrier for impurity, and if you make the barrier leaky then
you can expect weird behavior at best.
On Sat, Nov 3, 2018 at 5:00 AM Joachim Durchholz
Am 03.11.18 um 09:31 schrieb Brandon Allbery:
Conceptualization of IO is difficult. One way to think about it is the result of (main :: IO a) is a program sent to an impure runtime to execute, with IO actions being compositions of instructions for the runtime… but this breaks down as soon as you discover unsafePerformIO.
I have been thinking that that's just a conceptual accident: pure functions are enough to get all the useful effects (and most of the downsides) of global variables and mutable state, but pure functions cannot do IO. So unsafePerformIO is the one unsafe thing that was kept, other unsafe operations were either dropped or never made it into Haskell (remember that Haskell was designed by people who had been doing pure nonstrict languages for a decade or more).
The closest that you'll get to the reality for GHC is that it pretty much is a haven for impurity: that it forces all impure functions to declare that in their types. If Haskell is truly pure, then IO must be pure as well. That's why I think that IO functions are just describing impure activity, not doing it. I have not been able to verify whether this is actually true. Maybe IO is really a wart on Haskell's purity. I'd hate it if it were, and I think the Haskell design group would have hated that as well. OTOH IO is one of three approaches, and it happened to be the one that became usable first, so it's not part of the initial design process. Then again I like to think that SPJ wouldn't even contemplate something impure - but I don't really know.
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh allbery.b@gmail.com