Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IO Monad Considered Harmful

blog.jle.im

Post reply on HN
Print view View original

71–75 of 75 posts

Re: IO Monad Considered Harmful

#71

Post by elektronjunge »

barosl wrote: post #27

I've also experienced similar failures. I've tried to learn Haskell several times, and every time I meet the Monad section in the tutorial I lost my concentration. One of my friends who is proficient in Haskell told me to just start coding without trying to understand the advanced concepts, but I wasn't inclined to do that as Monads were hanging over my head, and I really wanted to understand what they are before wri…

You can actually implement IO using unsafePerformIO fairly easily. There's a little bit of compiler magic for speed, but its not strictly necessary.

Re: IO Monad Considered Harmful

#72

Post by dllthomas »

pestaa wrote: post #57
exDM69 wrote: post #46

Earlier quoted context omitted.

That's a very contrived example you obviously didn't spend any time trying to understand. No-one in their right mind would write code like that, except to demonstrate something. And if you did write code like that, Haskell's hlint tool would make suggestions to turn it neat and readable using fmap.

Why wouldn't I want to write that? Clearly you need a little practice before instantly recognizing a partially applied function where the next parameter will be appended to your other string, but that one-liner has actually a very nice computing flow.

I don't like it because the flow of data keeps changing direction. I would prefer one of

    getLine >>= ( ("Hello, " ++) >>> putStrLn )

    putStrLn . ("Hello, " ++) =

Re: IO Monad Considered Harmful

#73

Post by kazagistar »

tjradcliffe wrote: post #51
wyager wrote: post #9

Here's how I like to explain Monads to people. I've been told it's a decent explanation. (It ignores the monad laws and such, but it's a decent conceptual overview.) OK, so you know Java interfaces? Haskell has something just like that. They're called "type classes", though. But it works pretty much the same way. When you write out a class definition, you write A) the name of the class B) all the functions the class…

Every explanation of every Haskell feature I encounter reads the same way as this. You define "return" as " return :: a -> m a " and say this means it takes "an a" (by which I assume you mean an object of type a?) and returns a " Foo " (an object of type Foo ?). The problem I have is: what on earth does this have to do with 'm'? Is 'm' equivalent to 'Foo'? If so, why don't you mention that? It isn't obvious to a newb…

The fundamental problem is higher order types. When you define an interface in Java or C#, it has no way of referring to itself. Something like "compareTo" cannot say "the other type must be exactly equal to this". So lets invent such a syntax (using a keyword "as") and write the Monad interface:

    interface Monad as m {
        const m bind(m, Function>);
        const m return(a);
    }
If you fill in the implementing class for m (like IO or List or Maybe), you get the actual type signatures that would maybe be valid in C# or something.

Re: IO Monad Considered Harmful

#74

Post by codygman »

tjradcliffe wrote: post #56
tel wrote: post #39

Earlier quoted context omitted.

To go ahead and be that Haskell purist... in normal Haskell code there are no functions which execute side effects in the process of computing their results. Even a function like putStrLn :: String -> IO () merely produces an IO value. It is only when such a value is sequenced into something presented to the RTS as `main` that the effects are realized. This seems like pedantry, but it allows you to construct and comp…

Thanks for this answer. I think it points clearly to the source of confusion. To be pedantic back at you, I'm pretty sure your explanation translates to: "So long as you never run a program, Haskell is a pure language." Pedantically speaking, you can't have it both ways. Either the "Haskell" of the claim "Haskell is pure" includes the RTS or it does not. If it does, it is not pure but can run programs. If it does not…

I think we can agree the construction of the actions as pure.

I'm not sure about after those actions are realized in main.

Re: IO Monad Considered Harmful

#75

Post by tel »

tjradcliffe wrote: post #56
tel wrote: post #39

Earlier quoted context omitted.

To go ahead and be that Haskell purist... in normal Haskell code there are no functions which execute side effects in the process of computing their results. Even a function like putStrLn :: String -> IO () merely produces an IO value. It is only when such a value is sequenced into something presented to the RTS as `main` that the effects are realized. This seems like pedantry, but it allows you to construct and comp…

Thanks for this answer. I think it points clearly to the source of confusion. To be pedantic back at you, I'm pretty sure your explanation translates to: "So long as you never run a program, Haskell is a pure language." Pedantically speaking, you can't have it both ways. Either the "Haskell" of the claim "Haskell is pure" includes the RTS or it does not. If it does, it is not pure but can run programs. If it does not…

Eh, I don't care much about names. Purity-up-until-RTS being taken seriously makes it easy to think of computations both pure and impure. I get to choose whether to interpret IO as an imperative, impure language subset of Haskell or as a pure type. Both have their advantages.

If your language is impure then you usually can only choose the former.

Post reply on HN