Hacker News Reader

Comment by ekiru | Hacker News Reader

I'm a little disappointed that the article suggests that the IO monad makes Haskell impure. While it is certainly true that unsafePerformIO violates purity(and type safety, as well), without it, IO is perfectly pure. It's just that if an IO a value happens to end up in main or something referenced from main, input and output happen. From the language's perspective, the IO monad functions could all be perfectly pure and have no relation to input or output(putStrLn could be a no-op, input functions could always return the same thing). It would be utterly useless for its intended purpose, but there would be no difference in terms of its purity.

View on HN

" I'm a little disappointed that the article suggests that the IO monad makes Haskell impure. While it is certainly true that unsafePerformIO violates purity..."

I think that above sentence could be translated to "I don't like that article X makes point Y. While the article is right and point Y is in fact true....".

I'm not a Haskell expert, by the way, but reading the article I felt it didn't demean the language in any way. Pure functional languages are really boring. They can't even print anything to the console!

Point Y is in fact, not true. unsafePerformIO is not part of Haskell, the language. It is an additional feature provided by GHC. (Similarly, the typeof keyword and statement-exprs are not part of C, but extensions provided by GCC.) Interesting Haskell programs can and usually are written entirely without use of unsafePerformIO.

This is, however, a fairly minor technical point. More importantly, I feel that the division the article's author makes between two definitions of functional programming is misleading. "Functional programming", just like "object orientation" and "imperative programming" and "logic programming" and "structured programming" and every other "paradigm", is not a term with one or even two well-understood clearly separated definitions; it is a term for a grab-bag of features, tendencies, and patterns of programming languages. The world of FP isn't divided into people who think that only absolutely pure languages should be used and people who think that any language with first-class functions is okay; it's a continuum. The author just happens to be further towards the "anything goes" end of the spectrum than the authors of the articles he is replying to.

unsafePerformIO is part of the the Haskell 98 Foreign Function Interface, which is "An Addendum to the Haskell 98 Report". (See chapter 5 Marshalling <http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html...) All haskell compilers support the foreign function interface, and it will be a required part of the next haskell standard.

Use of unsafePerformIO (or any other unsafe function) should rarely be needed in real world programs though.

Perhaps re-wording it will help?

1. In Haskell, the IO monad is a pure way to represent IO. It does not violate purity.

2. "unsafePerformIO" violates purity, type safety, and half a dozen other semantics as well. It is not part of the language standard, and requires special compiler flags and pragmas to use. Its use (except in FFI) is heavily discouraged, and often involves a proof of correctness to prevent its "unsafe-ness" from leaking.

Reply on news.ycombinator.com