Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention)

Explain? What would the alternative be?

> Using functions with worse time or space complexity, to maintain purity.

This seems like the opposite of your previous complaint.

> For a lot of code you end up using monads plus 'do' notation, making your programs look practically imperative, but an oddball variation of it.

This seems to be a "psychological problem" with Haskell: the idea that because Haskell supports declarative, it's not OK to be imperative. It makes beginners tear their hair out looking for 'do'-free solutions when they could just use 'do'. C.f., "Lambda: the Ultimate Imperative" (and the rest of that series of LtU papers) http://dspace.mit.edu/handle/1721.1/5790



Explain? What would the alternative be?

Box the value that is the result of evaluation an expression that calls impure code in IO?

This is what I'd expect for calling impure code in third-party libraries.


If the library developer can prove that a C operation is pure, why shouldn't he tell Haskell about that?


And if you don't trust the developer, it's easy to fix his mistake:

    unUnsafePerformIO :: a -> IO a
    unUnsafePerformIO = return


Sorry, that doesn't actually work.

    ezyang@ezyang:~$ cat Test.hs
    import System.IO.Unsafe
    unUnsafePerformIO = return
    main = do
      let a = unUnsafePerformIO (unsafePerformIO (putStrLn "boom"))
      a
      a
    ezyang@ezyang:~$ runghc Test.hs
    ezyang@ezyang:~$


Yes, true. Patch the library if the annotation is wrong :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: