Talk:Haskell/Understanding monads/IO

Control.Monad
Note to self, and to anyone interested: this is potentially a great place to introduce the "control structure" functions like  (cf. SPJ's Awkward Squad paper). --Duplode (discuss • contribs) 05:40, 1 May 2012 (UTC)
 * Now done. It is a really brief introduction, but at least it will ensure readers are aware of  and friends sooner rather than later. Duplode (discuss • contribs) 04:15, 14 October 2013 (UTC)

Stop it with the impurity / side-effects talk
I stripped out all that junk in my recent rewrite. Monads are not impure and IO is not about side-effects. It's silly to say that running a program causes side-effects. Nothing in Haskell is impure or causes side-effects. Monads don't help us do side-effects. Monads allow pure mathematical manipulations of bits of Haskell that create actions in what the program actually does. Nobody ever claims that the entire program itself is a pure function. The program itself is a program that is compiled into machine code. It's the internal Haskell stuff (including the Monads) that is purely functional. I'm not an expert, and I'd be happy to see others improve on my writing (please!), but don't put in confusing and erroneous junk about impurity. Thanks. Backfromquadrangle (discuss • contribs) 02:49, 10 May 2014 (UTC)


 * I think we have to be careful not to go overboard. Monads are clearly not impure, and framing  in terms of the impure/pure dichotomy is probably not wise pedagogically. However, proscribing talk of side-effects is a step too far, as   is definitely about side-effects. After such a strong claim I need to argue my case properly, so please forgive my usual long-windedness.


 * Talking about "effects" in Haskell is unproblematic if by that we refer to the effects of applying a function in an applicative and/or monadic context which do not show up in the underlying ("contained", "wrapped", etc.) values of the functor. Now, a side-effect is something quite different; namely, something that can't be observed in Haskell at all. As far as the Haskell code is concerned, it doesn't matter what  displays; the effect is not detectable. Similarly, that   affects the state of the terminal is not observable; also, the further consequence of a   being delivered, seemingly out of thin air, is entirely opaque.


 * Effects and side-effects, as defined here, are quite different concepts; however, there is a parallel in that both involve things that are not directly observable.  is a fruit of that parallel. Notionally,   actions involve functorial effects, in a way that is captured by the state-of-the-world interpretation (even though, as you point out in the text, that interpretation should not be taken too seriously). Beyond that, however, an   action brings forth actual side-effects. We will find them if we look not only above the purely functional implementation (we compose actions so that things happen in the real world) but also below it (when the actions are evaluated by the running program, things will happen in the real world); the Haskell implementation itself, however, has no access to them.   allows the sleight of hand of using functorial, purely functional effects to model and specify side-effects.


 * Once again, we are faced with many overlapping levels of implementation and interpretation, leading to the ambivalence that allows us to talk of side-effects in a purely functional language. The same happens we try to contrast "pure" and "impure". is certainly a referentially transparent value; however, when we use it we aim at a   which is not referentially transparent at all, and that matters in practice. From a very useful point of view,   is just another abstract, closed functor; and yet, it also makes sense to say that   is a means to taint impurity. A curious, in-the-wild example of that ambivalence can be found at the official Pipes tutorial. It begins "Conventional Haskell stream programming forces you to choose only two of the following three features: (*) Effects (*) Streaming (*) Composability". By "effects", Gabriel Gonzalez means purely functional monadic effects, as Pipes is meant to provide a robust alternative to  -like functions. However, given that I/O streaming is one of the main use cases of the library, he also means side-effects, as can be seen a few sentences later: "If you sacrifice Composability you write a tightly coupled read, transform, and write loop in IO, which is streaming and effectful, but is not modular or separable." The ambiguity is not bothersome because both meanings are reasonable, and also because they meet in.


 * The notion of side-effects is part of everyday talk about Haskell, and not just due to hand-waving of the sort you removed from the chapter. The  documentation talks about them (: "For this to be safe, the IO computation should be free of side effects and independent of its environment."); so do Eugenio Moggi (Notions of computation as monads: "We give few notions of computation in the category of sets: [...] side effects $$T A = (A \times S)^{S}$$, where [...]") and Simon Peyton Jones (Awkward Squad: "The action   is an action that does no I/O, and immediately returns   without having any side effects."). While I agree with a move towards emphasising the similarities between monads and   and the rest of Haskell rather than the differences, I do not think eliminating all mention of side-effects and impurity is a good thing, as those terms point clearly to a real aspect of programming in Haskell.


 * P.S.: The wall of text just above is not meant as criticism of your rewrite; overall I think the chapter is a lot better now. I just found that the point about terminology was important enough to be discussed at length.


 * Duplode (discuss • contribs) 10:51, 10 May 2014 (UTC)


 * Thanks, I think your explanation is great. I really never meant that the idea of "side-effects" (or the term, for that matter) was inherently a problem. So I retract my hard view. I'm not opposed to talking about side-effects. I oppose talking about them as though they challenge Haskell's claims of pure functions or anything. In other words, they are mundane. The framing that associates "side-effects" with weird hand-waving interpretations about the magic of Monads or something is the problem. It's certainly fine to talk about side-effects in the sense that obviously the IO actions doing stuff out in the world are obviously side-effects. But besides stating that, so what? I.e. I don't like the phrasing that was like "oh! But this is a side-effect! Golly wow!". But sure, fine to actually just talk about them plainly for what they are. Thanks for your help clarifying! Backfromquadrangle (discuss • contribs) 04:52, 11 May 2014 (UTC)


 * You are welcome. I must say that writing down the argument turned out to be quite useful as well; you gave me occasion to place a few things in a different light.--Duplode (discuss • contribs) 06:24, 11 May 2014 (UTC)