undefined | Better HN

0 pointsGeminidog5y ago0 comments

Right, but the article says that Haskell pushes these side effects to the edge. I am not saying haskell claims this, I'm saying the article claims this. Haskell actually doesn't do this in practice as tons of people use do notation and state monads. The more people use do notation, the more they are embracing side effects. Literally I've seen haskell code where all function definitions had some form of do notation which is basically against the claim made by this article.

To push side effects to the edge you have to only use do notation and monads when you absolutely have no choice, which is not done in practice with haskell.

>The presence of monads does not necessarily mean side effects

The presence of a functor does not mean side effects. The presence of a monad implies composition and binding which does imply a side effect. Even maybe monads composed have side effects that can produce output that the function itself can never produce on it's own.

For example let's say I have a maybe monad that will never produce "Nothing."

   b :: int -> Maybe Int
   b x = Just x

but I can produce a side effect by binding it with Nothing.

  Nothing >>= b

The above yields "Nothing," even though it is not part of the definition of b. It is a contextual side effect passed on through monadic composition. Normal composition outside of monadic composition usually does not have this property.

0 comments

willtim5y ago

You seem to be lumping all side-effects together as equally bad? I don't think you can expect to push everything out to the edges, for example partiality. I take your point that a lot of imperative programming is done in Haskell (e.g. State monads). However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

GeminidogOP5y ago

>You seem to be lumping all side-effects together as equally bad?

Never implied anything was bad or good. Just saying that Haskell style programming does not push side effects to the edge.

>I don't think you can expect to push everything out to the edges, for example partiality.

Of course you can't push everything to the edge, but haskell style programming doesn't attempt to do this. It embraces the side effects and no one actually pushes anything to the edge. Partiality was just an example, the point is the bind operator will have a side effect on b so you can no longer treat the output of b as a pure black box. People who use haskell use the bind operator all the time indicating that their code is littered with side effects. Which again isn't necessarily bad, it just is what it is.

>However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation.

Again if you avoid using monads as much as possible in haskell you are pushing side effects to the edge. If you don't do this, which is basically what most haskell programmers end up doing, then you are not pushing side effects to the edge.

tome5y ago

> But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation.

Yeah, "functional core/imperative shell" or "pushing IO to the edges" is a weird myth. Really the strength of Haskell is "functional core/IO code carefully threaded through functional core".

What's a good descriptive slogan for that? "Functional pipework/imperative reactants", invoking chemical engineering?

To cycle back to your point, I don't think the failure of this slogan actually points to any weakness in Haskell.

1 more reply

j / k navigate · click thread line to collapse