10 ms·

IO Monad Considered Harmful

90 points by ryantrinkle 12y ago

jitl 12y ago
I wish the author had explained what the difference between using the IO type and using the IO type via the monadic interface looked like. As a Haskell beginner, this article just makes me more confused. Can someone share an example or clarify?
- tel 12y ago
  The IO type can be constructed in all kinds of ways. For instance, using `putStrLn` is probably the most common putStrLn "hello world" :: IO () As IO is an instance of Functor we can use that interface, for instance fmap (const 1) (putStrLn "hello world") :: IO Int That would be using IO's functorial interface. As an extension to a functorial interface we also have a monadic interface. This affords us a "most boring" way of creating new IO values -- very different from putStrLn -- it doesn't actually represent *doing* anything at all return "hello world" :: IO String and also, finally, a way at getting at values "inside" of IO and therefore "compose" values of IO -- getLine :: IO String capitalizer :: IO () capitalizer = getLine >>= (\line -> putStrLn (map toUpper line)) So, the emphasis is that IO is "just" another type. One shouldn't refer to "the IO monad" as anything privileged unless you're actively referring to using (return, >>=) with IO. Generally "the IO monad" explains very little of IO's power as "being a monad" is a very small part of any type's interface. --- To be clear, here are some other interfaces we can use from IO (besides just other IO value constructors) * combining IO with exception handlers with catch :: IO a -> (e -> IO a) -> IO a * forking new threads with forkIO :: IO () -> IO ThreadId * embedding IO into another type with -- extremely common liftIO :: MonadIO m => IO a -> m a * converting an IO action into an asynchronous action with async :: IO a -> IO (Async a) * assigning a IO action pointed at by a finalizer to a memory pointer with newForeignPtr :: FunPtr (Ptr a -> IO ()) -> Ptr a -> IO (ForeignPtr a)
- wyager 12y ago
  Yes. Here's a function that has type `IO ()` but doesn't obviously use `IO`'s monadic interface. foo = print "hello" `print` may use `IO`'s monadic interface under the hood, I don't know. Here's some code that has type `IO ()` and does use `IO`'s monadic interface. foo = do str <- getLine print str which is de-sugared to foo = getLine >>= \str -> print str which you can, if you like concise code, feel free to shorten to foo = getLine >>= print The important part is `>>=` (pronounced "bind"), which is defined in the monad typeclass. (A typeclass is like a Java interface, by the way.)
  - JoshTriplett 12y ago
    Or: foo = print =<< getLine which often reads better when trying to build something that looks more like a nested function call and less like a pipeline.
- ajkjk 12y ago
  (Also a Haskell beginner) I think his point is that the IO type may be an example of a monad, but shut up about the monad part because it's not relevant to learning how to use it.
  - raek 12y ago
    Exactly. You only need to know about some primitive operations (like putStrLn and getLine), and ways to combine them (like >>, >>=, and return). This was my point when I wrote my "IO tutorial" (not a monad tutorial!): http://blog.raek.se/2012/10/19/haskell-io-in-five-minutes/ http://blog.raek.se/2012/10/19/haskell-io-in-five-minutes/
- platz 12y ago
  non-monadic: import Data.Char main = (fmap.fmap) toUpper getLine monadic (but still doesn't utilize extra power granted by monadic interface, since it produces the same result as above): import Data.Char main = do x <- getLine return $ map toUpper x
- kazagistar 12y ago
  If you are starting Haskell, there is a wonderful little function you can use called `interact`, which has a type `(String -> String) -> IO ()`. This takes a String to String function, and turns it into an IO type that reads from STDIN, runs the function, and writes to STDOUT, lazily. Thus, you can just write `main = interact myFunction` and get everything you need to build complex Unix pipeline utilities without needing to worry about any impurity or composition. I suggest you stick to this until you are comfortable with the basic syntax, types, lazyness, and typeclasses of Haskell. The problem with learning about the monad typeclass first is that it is a very very high level abstraction, and abstractions are near impossible to understand without a working understanding of examples that they might abstract.
  - jitl 12y ago
    This sounds amazing. I was one of those beginners who thought I had to learn monads right away to get anything done, became frustrated, and never progressed.
- nostrademons 12y ago
  Think of a value with type (IO String) as "a computation that interacts with the outside world and then returns a value of type String", and similarly (IO ()) is "a computation that interacts with the outside world and then does not return a value. putStrLn has type IO (). getLine has type IO String. Now, imagine that you want to build up a whole program that interacts with the outside world. One easy way to do this is to sequence together a number of these primitive operations. The monadic bind operator is Haskell's way of sequencing together computations that support the monad interface (which IO does). A simple console echo program could be written as "main = getLine >>= putStrLn", using the >>= operator to feed the result of getLine into putStrLn. The two computations, sequenced together, form the definition of the whole program. The monadic bind operator gets awkward if you're trying to combine lots of these statements or if you need to assign their results to variables, and so do-notation was added to the language: main = do youTyped <- readLine putStrLn youTyped This is because a monad functions just like an overridable semicolon: it's a way for you to define how two computations, specified in sequence, will execute. For the IO type, this is specified by the language runtime to be "execute the first, then execute the second", but it doesn't have to be this. For the Maybe type, for example, it's "Execute the first, but only execute the second if the result of the first is not Nothing", and for the Error type, it's "Execute the first, but propagate the error if it returns one." A key point the article is making but fails to mention is that these values of the IO type are just ordinary values. The "normal" thing to do is execute them in sequence, but you don't have to do that. You can, for example, map putStrLn over a list and then sequence that with mapM: main = mapM putStrLn [1,2,3,4] Or you could just map putStrLn over a list, and then pass the resulting list of IO values around to some other filter for further processing before sequencing. A somewhat roundabout way of defining FizzBuzz, for example, would be: subst (i, a) | i `mod` 15 == 0 = putStrLn "FizzBuzz" | i `mod` 5 == 0 = putStrLn "Buzz" | i `mod` 3 == 0 = putStrLn "Fizz" | otherwise = a makePrint i = (i, putStrLn $ show i) main = sequence_ $ map (subst . makePrint) [1..100] See what I did there? The numbers 1 through 100 are each first passed through makePrint, which pairs them with an IO action to print their string equivalent. The result of that is passed to subst, which filters out multiples of 3, 5, and 15 to instead become actions that print "Fizz", "Buzz", and "FizzBuzz". The original putStrLn calls are dropped on the floor, or more accurately, never executed because Haskell is lazy. Finally, all of the resulting actions are sequenced together with sequence_, which is a standard library function to execute a bunch of monads and throw away the result. The result of putStrLn is just a value, and can be manipulated like any other value. This is how many of the cooler monadic libraries (eg. stateful CGI programming with WASH, parser combinators in Parsec, or bytecode JIT generation with LLVM) are implemented.
- raek 12y ago
  You don't use another interface when thinking "IO type" instead of "IO monad". It's all about what words you use to explain the types of the interface. For example, when you write 1 + 2 you are probably thinking of (+) being addition on integers. But a mathematician could also think of (+) as the operator from the group (Z, +, 0). Groups (a concept in abstract algebra) generalize integers, but you do not need to know group theory to do arithmetic. But it's the same operator nevertheless! Just two ways of talking about it. Similarly, when you write putStrln "Hello " >> putStrLn "world!", the "IO type" way of thinking says: (>>) is an operator that glues two IO actions together. The resulting combined action performs the argument actions sequentially from left to right. The operator has the type IO a -> IO b -> IO b. But you can think of (>>) in more general terms. It is not meaningful only for the IO type. It is meaningful for any type that happens to be a monad! That insight may be useful eventually, but probably not for a beginner Haskell programmer just wanting to do some IO!
hobs 12y ago
I can definitely say that my short sidequest to Haskell began and ended with trying to figure out what a monad was, and concluding that this was a silly first topic as well. I am glad I wasn't the only one.
wyager 12y ago
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 has to support and C) the types of those functions. (Like a Java interface definition.) Haskell has a type class called "Monad". To "implement the monad interface", in Java parlance, you have to implement two functions. The first is called "bind", but it's written ">>=". Here's its definition: >>= :: m a -> (a -> m b) -> m b Let's say our Monad was called `Foo`. In Java-land, this means the function takes a `Foo<a>`, a function that takes an `a` and returns a `Foo<b>`, and it uses those two things to return a `Foo<b>`. The other function is "return", which is defined as return :: a -> m a Which, in Java terminology, means it takes an `a` and returns a `Foo<a>`. If you implement those two functions, you now have a Monad. If you've been told that Monads do anything in particular, you've been told wrong. Monads don't necessarily have anything to do with IO, or sequencing, or state, or anything like that. It just so happens that those two functions (">>=" and "return") are super useful for representing a whole lot of common things, which happen to include things like IO and stateful algorithms. Monads don't have to do either of those things, but they certainly can.
- oconnor663 12y ago
  Can you add some examples of how bind and return get defined for commonly used monads, like IO? I'd love to have a more intuitive grasp of what they're for.
  - JoshTriplett 12y ago
    IO is a bad example; its instance of Monad normally exists in native non-Haskell code (or in Haskell-runtime-specific code) rather than in Haskell. Another good reason that talking about the "IO monad" early on doesn't work out well. So, I'll start with a couple of non-IO examples and then provide a suggestion for how IO works. Let's start with Maybe. The Maybe type looks like this: data Maybe a = Just a | Nothing You often use Maybe to represent functions that only handle some inputs: safeHead :: [a] -> Maybe a safeHead (x:_) = Just x safeHead _ = Nothing > safeHead [1,2,3] Just 1 > safeHead [] Nothing The Maybe monad lets you assemble a series of operations of type Maybe into a single compound function of type Maybe. If any of the individual operations produce Nothing, the whole function produces Nothing. safeAddHeads :: Num a => [a] -> [a] -> Maybe a safeAddHeads l1 l2 = do v1 <- safeHead l1 v2 <- safeHead l2 return v1 + v2 > safeAddHeads [1,2,3] [2,4,6] Just 3 > safeAddHeads [1,2,3] [] Nothing That do notation get translated to the following uses of bind and return: safeAddHeads l1 l2 = safeHead l1 >>= \v1 -> safeHead l2 >>= \v2 -> return v1 + v2 Bind (>>=) implements this behavior, of obtaining a value and feeding it into the next combination, or returning Nothing: (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b Just a >>= f = f a Nothing >>= _ = Nothing Return takes a plain value and makes it a monadic value, so it's just the "Just" constructor: return :: a -> Maybe a return = Just (You could also write that as "return a = Just a", but you'll often see Haskell functions written in "point-free style", which means omitting explicit parameter names when not needed.) So, that's bind and return for Maybe. For a more unusual example, lists are a monad. The list monad acts like a cross-product: for every value in the list, do the remaining operations. For instance: pairs :: [a] -> [b] -> [(a,b)] pairs l1 l2 = do v1 <- l1 v2 <- l2 return (v1, v2) > pairs [1,2,3] [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] If that looks a lot like a list comprehension, that's not a coincidence. Return, again, is easy: return :: a -> [a] return a = [a] Bind implements the behavior of running the right-hand side for each item on the left and combining the results into a list: (>>=) :: [a] -> (a -> [b]) -> [b] (x:xs) >>= f = f x ++ (xs >>= f) [] >>= _ = [] Note that the list bind operation calls itself recursively here: first call f on the first item, then call it on the rest. This could also be written with a fold or map; for instance: xs >>= f = concatMap f xs concatMap just runs concat on the result of map. The map applies f (of type a -> [b]) to each item in the list (type [a]); since f returns a list, that results in a list of lists ([[b]]), which concat combines into a single list ([b]). You might want to take a look at the Writer, Reader, and State monads for further examples. Note in particular that those three maintain some internal state information inside the monad, and in addition to the bind and return operations, they offer operations that work with that internal state. Having given those examples, here's a sketch of how IO could work. IO operations act as though they change some state (the outside world), and if you chain them together, the second operation acts on the state resulting from the first (for instance, if you call getLine twice, the first modifies the state of stdin by reading a line from it, and the second starts where the first left off by reading another line). That state isn't actually representable in Haskell, but let's imagine that it is. So, the IO type (to focus on the terminology suggested by this article) contains a value along with an operation changing the state of the world: data IO a = IOPrivate (StateOfTheWorld -> StateOfTheWorld) a Notice that a value of IO type contains an operation changing the state of the world, rather than an actual state of the world. It helps to think of an IO type as representing an operation to be run, and main is the top-level operation that actually gets run when you invoke the program. Continuing that analogy, something outside your program, provided by the Haskell runtime, does this: run :: IO () -> StateOfTheWorld run (IOPrivate f ()) = f initialStateOfTheWorld (Compare this to functions like runState, for instance.) Return takes a non-IO value and makes it into an IO value that doesn't actually change the state of the world: return :: a -> IO a return a = IOPrivate id a Bind sequences the changes to the state of the world: (>>=) :: IO a -> (a -> IO b) -> IO b (IOPrivate sf1 v1) >>= f = let IOPrivate sf2 v2 = f v1 in IOPrivate (sf2 . sf1) v2 ("sf" here stands for "state function".)
JoshTriplett 12y ago
I've been writing Haskell code for years, and this is one of the most singularly useful articles I've read on it. I've certainly found the proliferation of "monad tutorials" and "learn this so you can print something" guides obnoxious, but it never occurred to me that IO really could be taught completely separately from monads. Here's the outline of what the middle of a tutorial could look like, following this advice: Here's how to print a string (putStr, putStrLn). Here's how to print something other than a string (show, print). Here's how to print two somethings in a row (>>). Here's how to read something and print that (>>=). Here's how to print something in a function other than main (:: IO ()). Here's how to read something in a function other than main (:: IO a, >>= again, return). Oh by the way, it turns out that pattern (return, >>=) is so common that Haskell gives it a special syntax (do notation). For instance, it works with the previously introduced Maybe. And with List. Remember typeclasses? You can write functions that work with IO, Maybe, and List (Monad m => ...). Even when actually talking about monads, the explanation should come first, and the term should come later. "It turns out these operations are a common enough pattern that Haskell gives them special syntax..." comes across much more sanely than "now we're going to introduce something [complicated] called a monad".
- millstone 12y ago
  I think your suggestion is a relative improvement over most tutorials. But it's still unmanageably hard. "Here's how to read something and then print that: >>=". Sure, like `getLine >>= putStrLn`. Technically speaking, that's correct. But this doesn't generalize at all. Maybe I want to greet the user by name. How do I read the name, prepend "Hello, " to it, and then print that? This is a totally natural thing to want to do, and is very straightforward in Java. But our Haskell newbie hits a wall - none of your cases cover it! Here's how I might write that today, without using do notation: `getLine >>= (return . (++) "Hello, ") >>= putStrLn`. Look at that - it's totally nuts, and I would not attempt to explain that to a Haskell neophyte. Using do-notation, you can make things nicer: do name <- getLine putStrLn $ "Hello, " ++ name but this introduces a bunch of new syntax to learn: the difference between let-in and let and <-, how do-notation works, etc. I don't have a better approach than what you suggest. I suspect that this stuff simply can't be made easy.
platz 12y ago
The thing that makes an 'IO t' data structure different from some arbitrary java bytecode, is that bytecode is an opaque black box, and represents commands that will be executed immediately, whereas an 'IO t' just "describes" the intended action, remains composable and is a first-class value (i.e. data structure) in your program. It's necessary to draw a distinction between the "runtime" and "evaluation" in Haskell; it's not necessary afaik to draw this distinction in other languages, which I think is where the confusion comes from. In Haskell evaluation is pure, the runtime is not, but evaluation is what allows you to reason about your program.
- millstone 12y ago
  IO t is a black box too. If it's a data structure, it's a crappy one: you can't pick it apart like a list, inspect it, or do anything except sequence it. I didn't follow what you meant about "runtime vs evaluation." To me they seem hopelessly intertwined: if you evaluate head [], you get a runtime error.
  - platz 12y ago
    well, maybe gray then; it's not completely opaque. You know it's type, you can apply functions to the value inside. You can pass it around like a variable and if desired, completely throw it away. the point was to show that this is different than some bytecode. I'm not sure about the head [] example, it might actually be represented by a pure value such as _|_ (bottom) which bubbles up and stops your program when running.
  - pestaa 12y ago
    It's not a black box in the sense you can move it around, evaluate later, not evaluate at all, etc. There is fundamentally nothing you can inspect about a general IO operation: it's a handle to a computation dealing with the external world.
    - millstone 12y ago
      I'm pretty sure you can move black boxes around in the real world too :) There are definitely sensible things to do with "general IO operations." For example, consider `withArgs`, which replaces argv for the duration of an action. A natural approach is to pick through the received action, and replace all calls to `getArgs` with `return tempArgs`. But `withArgs` doesn't work this way because Haskell can't pick apart IO actions. Instead it uses a nasty FFI to modify a global. (It doesn't even look thread-safe: I'll bet withArgs "leaks" into other threads.) It's also overbroad: IO encapsulates "real world" computations like deleting files, but also basic operations like getting argv! I'd argue it's a failure of Haskell that the type system does not distinguish between a function that erases your hard drive and a function that gets your command line arguments.
millstone 12y ago
I read the article, and it annoyed me, because the rebuttal is obvious and wasn't addressed. The rebuttal is do-notation. The second program you write after Hello World is going to use two IO actions instead of one, and so you need a way to sequence them, and every tutorial is going to do that with do-notation. And suddenly all of the other syntax you learned, like how to declare a variable with let-in, or how arrows go -> that way, or how to call a function, is tossed out the window. And you'll spend ten minutes before you realize your indentation is wrong and then ten more fighting with how you declare a variable and then apply a function to it before it dawns on you, this is monads. You don't have to use do-notation, sure. You can use >>= as an infix operator. It's still totally confusing. The reality is that monads hit you hard and fast as soon as you want to do any IO. Not the monad laws or functors or whatever the tutorials focus on, but the nitty-gritty syntax. This is where I got stuck and gave up (twice), before I finally got it.
- platz 12y ago
  Yes, you'll need them to build up bigger programs. The point is they aren't fundamental to IO itself.
  - rjberry 12y ago
    They pretty much are as without sequencing you can only do the most trivial thing (a single IO action). Most interesting programmes are going to need at least two IO actions.
- olavk 12y ago
  Yeah, no way around learning do-notation even for the simplest of programs. And do-notation is kind of a DSL with a totally different feel than the rest of the language. So getting started writing even simple toy programs in Haskell requires you to learn two languages. No denying that Haskell is a language with a very steep learning curve. (Or is it a very shallow learning curve? Never understood that metaphor. But you have to learn a lot to get started.) However it might make sense in a tutorial or course to teach do-notation first as a DSL for IO in order to get started. And only later, when the student have a good understanding of the core language and type system, introduce monads and show how IO is a monad and how do-notation can be used with other monads. The problem with the much maligned monad tutorials is that the audience typically is beginners who get stuck on on the IO monad and do-notation immediately after writing "hello world". But the tutorials try to explain monads as a general concept, which requires a pretty through understanding of things like higher kinded types and so on. An understanding the newbie getting stuck at "hello world" obviously doesn't have yet. Then the tutorials try to be accessible by using metaphors like a "monad is a specesuit", a "monad is burrito" etc. But knowing that a monad is a buritto doesn't help the newbie who gets inscrutable compile errors after adding a second putStrLn to "hello world".
barosl 12y ago
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 writing some piece of code. Funnily enough, things were changed after I learned Rust. (I know I'm saying like a Rust zealot, but it's true!) After using Rust's `Option` type, and realizing its `.map()` and `.and_then()` are similar to `fmap` and `>>=` in Haskell, I finally began to grasp what functors and monads are. And that led me to understand the "implementation details" of Haskell. Before that, I thought `seq` was purely written in Haskell. But it wasn't. It is basically a compiler magic, and GHC specializes `seq` to allow eager evaluation. The same thing goes with the IO type; the monad itself has nothing to do with making I/O be done. I/O is possible solely thanks to the implementation details of the IO type, which resides in GHC. Plus, I can also guess that that part of GHC is probably not written in Haskell, because it is not possible to make side effects in "real" Haskell. So, Rust was my admirable Haskell teacher. (Thanks, Mozilla!) It's like a stepping stone between the imperative world and the functional world. The funny thing again is, after having fun with Rust for months, now I have less reasons to go back to learn Haskell... Rust is already too powerful, performant, and easy to understand, so Haskell feels less appealing to me. Haskell had been enviable to me in the past, but now it isn't anymore, (un)fortunately.
- DanWaterworth 12y ago
  There are lots of things in Haskell that I miss when I use rust, so I'd still encourage you to learn it. For example, concurrency in rust is OK, certainly nicer than other imperative languages, but Haskell has easily an order of magnitude more awesome to offer. I recently wrote a library for testing concurrent code. It's basically fuzz testing of scheduler behaviour to root out race conditions. In most languages, you'd need a special compiler or runtime to do this, in Haskell it's a library.
- elektronjunge 12y ago
  You can actually implement IO using unsafePerformIO fairly easily. There's a little bit of compiler magic for speed, but its not strictly necessary.
lclarkmichalek 12y ago
Ok, so we can't use the word monad because that's bad apparently. How do we answer "How does Haskell, a FP language where composition is a very important concept, compose IO actions?". Because that's almost always done using monadic actions. Aside, I agree on the List monad thing. I never ever use the list monad, why would I. But if I'm managing state (i.e. IO, Reader/Writer, Conduit etc), then why wouldn't I use the name of the language construct that Haskell provides to manage state?
- tome 12y ago
  > How do we answer "How does Haskell, a FP language where composition is a very important concept, compose IO actions?". You can answer "By using the combinators provided for composing IO actions". The fact that the structure encoded (some of) these operations happens to correspond to a monad is something that can be left unmentioned until later.
- Chattered 12y ago
  > Aside, I agree on the List monad thing. I never ever use the list monad, why would I. I use monad library functions on lists happily, and use the do-notation, particularly when I'm thinking in terms of non-deterministic computation and search.
jkot 12y ago
"Avoid success at all costs" comes to mind.
- tel 12y ago
  As per usual, it was meant to be read as "Avoid: (Success at all costs)" not "(avoid success) (at all costs)".
  - dllthomas 12y ago
    My understanding is more that it was meant to be read both ways, but with the former understood to be serious and the latter a joke.
tjradcliffe 12y ago
This is a fair reflection on one of the biggest barriers to newbs learning Haskell (which I've tried to do a couple of times and failed, in part because the syntax is weird and poorly explained, in part because the tutorials suck, and mostly because I'm not very smart, or so I'm told.) The Haskell newb gets told two things very early on: 1) Haskell is pure pure pure! 2) Haskell can do IO via monads! These statements are contradictory. Haskell is either pure, or can do IO (via monads or anything else.) No pure language can do IO. Period. End of story. Any claim to the contrary is simply, utterly, completely false. I don't care how much you wish it was true, or think it's possible to finesse the issue. You can't. And the worst thing you can possibly do is introduce a newb to the new language via a contradiction. It's like idiots who introduce "negative resistance" with the up-front claim that a device has "negative resistance" without first introducing the generalized concept of resistance that the notion of "negative generalized resistance" depends on. Ordinary, unqualified "resistance" means V/I, not dV/dI, and if you use the unqualified term "resistance" in any other way you are deliberately and with malice aforethought creating confusion. Same goes for "negative temperature", doubled. Want to teach Haskell? Start like this: "Haskell is an effectively pure language that hides side-effects behind opaque interfaces that return new objects that represent the modified state of the world, rather than old objects that have been modified. This trickery lets us reason about Haskell code in most cases as if it was pure even though it is not." Claiming purity where there is none is terrible pedagogy. The newb will be confused and have a much harder time getting their head around the language. They will realize that the insiders are working in a different conceptual universe than they are, but won't see any way into that universe and will rightly assume that the insiders are being deliberately obtuse for the sole purpose of excluding newbs. I am, as stated above, extremely stupid. As such, I am pretty ordinary in this regard. If you want people to learn the damned language, you have to cater to stupid people like me. So discard, play-down, reject and ignore the myth of purity, because that's what it is. A myth. Haskell is not pure. In a pure language the return value of a function depends only on its arguments, but any function that does IO can return any value whatsoever, regardless of what its arguments might be. I'm sure Haskell purists will respond to this insisting that no, Haskell is really, truly, purely pure... for a certain definition of "purity". It isn't. Monads are a hack to cover necessary impurities. They are a good hack, but to redefine "pure" in such a way that accommodates monads--and this is what you have to do--is just like redefining "resistance" to accommodate "negative resistance". It's perfectly reasonable to generalize the definition of common terms, and perfectly confusing to use the generalization to imply that you mean "just perfectly ordinary resistance" when talking about "negative resistance," or "just perfectly ordinary purity" when talking about "purity with side effects hidden behind monads." There is no particular value, use or virtue in claiming Haskell is "a truly pure functional language". Claiming the language is "effectively pure for most practical purposes, so you get the provability of pure functional programming by hiding side effects behind monads" seems far more useful. Why the Haskell community is so wedded to the myth of purity--and therefore so insistent about putting monads front and center, as the article rightly decries--is not clear. But the language and the community would be better for putting the myth and the monads behind them.
chris_wot 12y ago
"Only a Sith deals in absolutes" - I see what you did there, you Sith Lord you!

90 points by ryantrinkle 12y ago

jitl 12y ago

I wish the author had explained what the difference between using the IO type and using the IO type via the monadic interface looked like. As a Haskell beginner, this article just makes me more confused. Can someone share an example or clarify?

tel 12y ago
The IO type can be constructed in all kinds of ways. For instance, using `putStrLn` is probably the most common putStrLn "hello world" :: IO () As IO is an instance of Functor we can use that interface, for instance fmap (const 1) (putStrLn "hello world") :: IO Int That would be using IO's functorial interface. As an extension to a functorial interface we also have a monadic interface. This affords us a "most boring" way of creating new IO values -- very different from putStrLn -- it doesn't actually represent *doing* anything at all return "hello world" :: IO String and also, finally, a way at getting at values "inside" of IO and therefore "compose" values of IO -- getLine :: IO String capitalizer :: IO () capitalizer = getLine >>= (\line -> putStrLn (map toUpper line)) So, the emphasis is that IO is "just" another type. One shouldn't refer to "the IO monad" as anything privileged unless you're actively referring to using (return, >>=) with IO. Generally "the IO monad" explains very little of IO's power as "being a monad" is a very small part of any type's interface. --- To be clear, here are some other interfaces we can use from IO (besides just other IO value constructors) * combining IO with exception handlers with catch :: IO a -> (e -> IO a) -> IO a * forking new threads with forkIO :: IO () -> IO ThreadId * embedding IO into another type with -- extremely common liftIO :: MonadIO m => IO a -> m a * converting an IO action into an asynchronous action with async :: IO a -> IO (Async a) * assigning a IO action pointed at by a finalizer to a memory pointer with newForeignPtr :: FunPtr (Ptr a -> IO ()) -> Ptr a -> IO (ForeignPtr a)
wyager 12y ago
Yes. Here's a function that has type `IO ()` but doesn't obviously use `IO`'s monadic interface. foo = print "hello" `print` may use `IO`'s monadic interface under the hood, I don't know. Here's some code that has type `IO ()` and does use `IO`'s monadic interface. foo = do str <- getLine print str which is de-sugared to foo = getLine >>= \str -> print str which you can, if you like concise code, feel free to shorten to foo = getLine >>= print The important part is `>>=` (pronounced "bind"), which is defined in the monad typeclass. (A typeclass is like a Java interface, by the way.)
- JoshTriplett 12y ago
  Or: foo = print =<< getLine which often reads better when trying to build something that looks more like a nested function call and less like a pipeline.
ajkjk 12y ago
(Also a Haskell beginner) I think his point is that the IO type may be an example of a monad, but shut up about the monad part because it's not relevant to learning how to use it.
- raek 12y ago
  Exactly. You only need to know about some primitive operations (like putStrLn and getLine), and ways to combine them (like >>, >>=, and return). This was my point when I wrote my "IO tutorial" (not a monad tutorial!): http://blog.raek.se/2012/10/19/haskell-io-in-five-minutes/ http://blog.raek.se/2012/10/19/haskell-io-in-five-minutes/
platz 12y ago
non-monadic: import Data.Char main = (fmap.fmap) toUpper getLine monadic (but still doesn't utilize extra power granted by monadic interface, since it produces the same result as above): import Data.Char main = do x <- getLine return $ map toUpper x
kazagistar 12y ago
If you are starting Haskell, there is a wonderful little function you can use called `interact`, which has a type `(String -> String) -> IO ()`. This takes a String to String function, and turns it into an IO type that reads from STDIN, runs the function, and writes to STDOUT, lazily. Thus, you can just write `main = interact myFunction` and get everything you need to build complex Unix pipeline utilities without needing to worry about any impurity or composition. I suggest you stick to this until you are comfortable with the basic syntax, types, lazyness, and typeclasses of Haskell. The problem with learning about the monad typeclass first is that it is a very very high level abstraction, and abstractions are near impossible to understand without a working understanding of examples that they might abstract.
- jitl 12y ago
  This sounds amazing. I was one of those beginners who thought I had to learn monads right away to get anything done, became frustrated, and never progressed.
nostrademons 12y ago
Think of a value with type (IO String) as "a computation that interacts with the outside world and then returns a value of type String", and similarly (IO ()) is "a computation that interacts with the outside world and then does not return a value. putStrLn has type IO (). getLine has type IO String. Now, imagine that you want to build up a whole program that interacts with the outside world. One easy way to do this is to sequence together a number of these primitive operations. The monadic bind operator is Haskell's way of sequencing together computations that support the monad interface (which IO does). A simple console echo program could be written as "main = getLine >>= putStrLn", using the >>= operator to feed the result of getLine into putStrLn. The two computations, sequenced together, form the definition of the whole program. The monadic bind operator gets awkward if you're trying to combine lots of these statements or if you need to assign their results to variables, and so do-notation was added to the language: main = do youTyped <- readLine putStrLn youTyped This is because a monad functions just like an overridable semicolon: it's a way for you to define how two computations, specified in sequence, will execute. For the IO type, this is specified by the language runtime to be "execute the first, then execute the second", but it doesn't have to be this. For the Maybe type, for example, it's "Execute the first, but only execute the second if the result of the first is not Nothing", and for the Error type, it's "Execute the first, but propagate the error if it returns one." A key point the article is making but fails to mention is that these values of the IO type are just ordinary values. The "normal" thing to do is execute them in sequence, but you don't have to do that. You can, for example, map putStrLn over a list and then sequence that with mapM: main = mapM putStrLn [1,2,3,4] Or you could just map putStrLn over a list, and then pass the resulting list of IO values around to some other filter for further processing before sequencing. A somewhat roundabout way of defining FizzBuzz, for example, would be: subst (i, a) | i `mod` 15 == 0 = putStrLn "FizzBuzz" | i `mod` 5 == 0 = putStrLn "Buzz" | i `mod` 3 == 0 = putStrLn "Fizz" | otherwise = a makePrint i = (i, putStrLn $ show i) main = sequence_ $ map (subst . makePrint) [1..100] See what I did there? The numbers 1 through 100 are each first passed through makePrint, which pairs them with an IO action to print their string equivalent. The result of that is passed to subst, which filters out multiples of 3, 5, and 15 to instead become actions that print "Fizz", "Buzz", and "FizzBuzz". The original putStrLn calls are dropped on the floor, or more accurately, never executed because Haskell is lazy. Finally, all of the resulting actions are sequenced together with sequence_, which is a standard library function to execute a bunch of monads and throw away the result. The result of putStrLn is just a value, and can be manipulated like any other value. This is how many of the cooler monadic libraries (eg. stateful CGI programming with WASH, parser combinators in Parsec, or bytecode JIT generation with LLVM) are implemented.
raek 12y ago
You don't use another interface when thinking "IO type" instead of "IO monad". It's all about what words you use to explain the types of the interface. For example, when you write 1 + 2 you are probably thinking of (+) being addition on integers. But a mathematician could also think of (+) as the operator from the group (Z, +, 0). Groups (a concept in abstract algebra) generalize integers, but you do not need to know group theory to do arithmetic. But it's the same operator nevertheless! Just two ways of talking about it. Similarly, when you write putStrln "Hello " >> putStrLn "world!", the "IO type" way of thinking says: (>>) is an operator that glues two IO actions together. The resulting combined action performs the argument actions sequentially from left to right. The operator has the type IO a -> IO b -> IO b. But you can think of (>>) in more general terms. It is not meaningful only for the IO type. It is meaningful for any type that happens to be a monad! That insight may be useful eventually, but probably not for a beginner Haskell programmer just wanting to do some IO!

hobs 12y ago

I can definitely say that my short sidequest to Haskell began and ended with trying to figure out what a monad was, and concluding that this was a silly first topic as well. I am glad I wasn't the only one.

wyager 12y ago

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 has to support and C) the types of those functions. (Like a Java interface definition.) Haskell has a type class called "Monad". To "implement the monad interface", in Java parlance, you have to implement two functions. The first is called "bind", but it's written ">>=". Here's its definition: >>= :: m a -> (a -> m b) -> m b Let's say our Monad was called `Foo`. In Java-land, this means the function takes a `Foo<a>`, a function that takes an `a` and returns a `Foo<b>`, and it uses those two things to return a `Foo<b>`. The other function is "return", which is defined as return :: a -> m a Which, in Java terminology, means it takes an `a` and returns a `Foo<a>`. If you implement those two functions, you now have a Monad. If you've been told that Monads do anything in particular, you've been told wrong. Monads don't necessarily have anything to do with IO, or sequencing, or state, or anything like that. It just so happens that those two functions (">>=" and "return") are super useful for representing a whole lot of common things, which happen to include things like IO and stateful algorithms. Monads don't have to do either of those things, but they certainly can.

oconnor663 12y ago
Can you add some examples of how bind and return get defined for commonly used monads, like IO? I'd love to have a more intuitive grasp of what they're for.
- JoshTriplett 12y ago
  IO is a bad example; its instance of Monad normally exists in native non-Haskell code (or in Haskell-runtime-specific code) rather than in Haskell. Another good reason that talking about the "IO monad" early on doesn't work out well. So, I'll start with a couple of non-IO examples and then provide a suggestion for how IO works. Let's start with Maybe. The Maybe type looks like this: data Maybe a = Just a | Nothing You often use Maybe to represent functions that only handle some inputs: safeHead :: [a] -> Maybe a safeHead (x:_) = Just x safeHead _ = Nothing > safeHead [1,2,3] Just 1 > safeHead [] Nothing The Maybe monad lets you assemble a series of operations of type Maybe into a single compound function of type Maybe. If any of the individual operations produce Nothing, the whole function produces Nothing. safeAddHeads :: Num a => [a] -> [a] -> Maybe a safeAddHeads l1 l2 = do v1 <- safeHead l1 v2 <- safeHead l2 return v1 + v2 > safeAddHeads [1,2,3] [2,4,6] Just 3 > safeAddHeads [1,2,3] [] Nothing That do notation get translated to the following uses of bind and return: safeAddHeads l1 l2 = safeHead l1 >>= \v1 -> safeHead l2 >>= \v2 -> return v1 + v2 Bind (>>=) implements this behavior, of obtaining a value and feeding it into the next combination, or returning Nothing: (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b Just a >>= f = f a Nothing >>= _ = Nothing Return takes a plain value and makes it a monadic value, so it's just the "Just" constructor: return :: a -> Maybe a return = Just (You could also write that as "return a = Just a", but you'll often see Haskell functions written in "point-free style", which means omitting explicit parameter names when not needed.) So, that's bind and return for Maybe. For a more unusual example, lists are a monad. The list monad acts like a cross-product: for every value in the list, do the remaining operations. For instance: pairs :: [a] -> [b] -> [(a,b)] pairs l1 l2 = do v1 <- l1 v2 <- l2 return (v1, v2) > pairs [1,2,3] [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] If that looks a lot like a list comprehension, that's not a coincidence. Return, again, is easy: return :: a -> [a] return a = [a] Bind implements the behavior of running the right-hand side for each item on the left and combining the results into a list: (>>=) :: [a] -> (a -> [b]) -> [b] (x:xs) >>= f = f x ++ (xs >>= f) [] >>= _ = [] Note that the list bind operation calls itself recursively here: first call f on the first item, then call it on the rest. This could also be written with a fold or map; for instance: xs >>= f = concatMap f xs concatMap just runs concat on the result of map. The map applies f (of type a -> [b]) to each item in the list (type [a]); since f returns a list, that results in a list of lists ([[b]]), which concat combines into a single list ([b]). You might want to take a look at the Writer, Reader, and State monads for further examples. Note in particular that those three maintain some internal state information inside the monad, and in addition to the bind and return operations, they offer operations that work with that internal state. Having given those examples, here's a sketch of how IO could work. IO operations act as though they change some state (the outside world), and if you chain them together, the second operation acts on the state resulting from the first (for instance, if you call getLine twice, the first modifies the state of stdin by reading a line from it, and the second starts where the first left off by reading another line). That state isn't actually representable in Haskell, but let's imagine that it is. So, the IO type (to focus on the terminology suggested by this article) contains a value along with an operation changing the state of the world: data IO a = IOPrivate (StateOfTheWorld -> StateOfTheWorld) a Notice that a value of IO type contains an operation changing the state of the world, rather than an actual state of the world. It helps to think of an IO type as representing an operation to be run, and main is the top-level operation that actually gets run when you invoke the program. Continuing that analogy, something outside your program, provided by the Haskell runtime, does this: run :: IO () -> StateOfTheWorld run (IOPrivate f ()) = f initialStateOfTheWorld (Compare this to functions like runState, for instance.) Return takes a non-IO value and makes it into an IO value that doesn't actually change the state of the world: return :: a -> IO a return a = IOPrivate id a Bind sequences the changes to the state of the world: (>>=) :: IO a -> (a -> IO b) -> IO b (IOPrivate sf1 v1) >>= f = let IOPrivate sf2 v2 = f v1 in IOPrivate (sf2 . sf1) v2 ("sf" here stands for "state function".)

JoshTriplett 12y ago

I've been writing Haskell code for years, and this is one of the most singularly useful articles I've read on it. I've certainly found the proliferation of "monad tutorials" and "learn this so you can print something" guides obnoxious, but it never occurred to me that IO really could be taught completely separately from monads. Here's the outline of what the middle of a tutorial could look like, following this advice: Here's how to print a string (putStr, putStrLn). Here's how to print something other than a string (show, print). Here's how to print two somethings in a row (>>). Here's how to read something and print that (>>=). Here's how to print something in a function other than main (:: IO ()). Here's how to read something in a function other than main (:: IO a, >>= again, return). Oh by the way, it turns out that pattern (return, >>=) is so common that Haskell gives it a special syntax (do notation). For instance, it works with the previously introduced Maybe. And with List. Remember typeclasses? You can write functions that work with IO, Maybe, and List (Monad m => ...). Even when actually talking about monads, the explanation should come first, and the term should come later. "It turns out these operations are a common enough pattern that Haskell gives them special syntax..." comes across much more sanely than "now we're going to introduce something [complicated] called a monad".

millstone 12y ago
I think your suggestion is a relative improvement over most tutorials. But it's still unmanageably hard. "Here's how to read something and then print that: >>=". Sure, like `getLine >>= putStrLn`. Technically speaking, that's correct. But this doesn't generalize at all. Maybe I want to greet the user by name. How do I read the name, prepend "Hello, " to it, and then print that? This is a totally natural thing to want to do, and is very straightforward in Java. But our Haskell newbie hits a wall - none of your cases cover it! Here's how I might write that today, without using do notation: `getLine >>= (return . (++) "Hello, ") >>= putStrLn`. Look at that - it's totally nuts, and I would not attempt to explain that to a Haskell neophyte. Using do-notation, you can make things nicer: do name <- getLine putStrLn $ "Hello, " ++ name but this introduces a bunch of new syntax to learn: the difference between let-in and let and <-, how do-notation works, etc. I don't have a better approach than what you suggest. I suspect that this stuff simply can't be made easy.

platz 12y ago

The thing that makes an 'IO t' data structure different from some arbitrary java bytecode, is that bytecode is an opaque black box, and represents commands that will be executed immediately, whereas an 'IO t' just "describes" the intended action, remains composable and is a first-class value (i.e. data structure) in your program. It's necessary to draw a distinction between the "runtime" and "evaluation" in Haskell; it's not necessary afaik to draw this distinction in other languages, which I think is where the confusion comes from. In Haskell evaluation is pure, the runtime is not, but evaluation is what allows you to reason about your program.

millstone 12y ago
IO t is a black box too. If it's a data structure, it's a crappy one: you can't pick it apart like a list, inspect it, or do anything except sequence it. I didn't follow what you meant about "runtime vs evaluation." To me they seem hopelessly intertwined: if you evaluate head [], you get a runtime error.
- platz 12y ago
  well, maybe gray then; it's not completely opaque. You know it's type, you can apply functions to the value inside. You can pass it around like a variable and if desired, completely throw it away. the point was to show that this is different than some bytecode. I'm not sure about the head [] example, it might actually be represented by a pure value such as _|_ (bottom) which bubbles up and stops your program when running.
- pestaa 12y ago
  It's not a black box in the sense you can move it around, evaluate later, not evaluate at all, etc. There is fundamentally nothing you can inspect about a general IO operation: it's a handle to a computation dealing with the external world.
  - millstone 12y ago
    I'm pretty sure you can move black boxes around in the real world too :) There are definitely sensible things to do with "general IO operations." For example, consider `withArgs`, which replaces argv for the duration of an action. A natural approach is to pick through the received action, and replace all calls to `getArgs` with `return tempArgs`. But `withArgs` doesn't work this way because Haskell can't pick apart IO actions. Instead it uses a nasty FFI to modify a global. (It doesn't even look thread-safe: I'll bet withArgs "leaks" into other threads.) It's also overbroad: IO encapsulates "real world" computations like deleting files, but also basic operations like getting argv! I'd argue it's a failure of Haskell that the type system does not distinguish between a function that erases your hard drive and a function that gets your command line arguments.

millstone 12y ago

I read the article, and it annoyed me, because the rebuttal is obvious and wasn't addressed. The rebuttal is do-notation. The second program you write after Hello World is going to use two IO actions instead of one, and so you need a way to sequence them, and every tutorial is going to do that with do-notation. And suddenly all of the other syntax you learned, like how to declare a variable with let-in, or how arrows go -> that way, or how to call a function, is tossed out the window. And you'll spend ten minutes before you realize your indentation is wrong and then ten more fighting with how you declare a variable and then apply a function to it before it dawns on you, this is monads. You don't have to use do-notation, sure. You can use >>= as an infix operator. It's still totally confusing. The reality is that monads hit you hard and fast as soon as you want to do any IO. Not the monad laws or functors or whatever the tutorials focus on, but the nitty-gritty syntax. This is where I got stuck and gave up (twice), before I finally got it.

platz 12y ago
Yes, you'll need them to build up bigger programs. The point is they aren't fundamental to IO itself.
- rjberry 12y ago
  They pretty much are as without sequencing you can only do the most trivial thing (a single IO action). Most interesting programmes are going to need at least two IO actions.
olavk 12y ago
Yeah, no way around learning do-notation even for the simplest of programs. And do-notation is kind of a DSL with a totally different feel than the rest of the language. So getting started writing even simple toy programs in Haskell requires you to learn two languages. No denying that Haskell is a language with a very steep learning curve. (Or is it a very shallow learning curve? Never understood that metaphor. But you have to learn a lot to get started.) However it might make sense in a tutorial or course to teach do-notation first as a DSL for IO in order to get started. And only later, when the student have a good understanding of the core language and type system, introduce monads and show how IO is a monad and how do-notation can be used with other monads. The problem with the much maligned monad tutorials is that the audience typically is beginners who get stuck on on the IO monad and do-notation immediately after writing "hello world". But the tutorials try to explain monads as a general concept, which requires a pretty through understanding of things like higher kinded types and so on. An understanding the newbie getting stuck at "hello world" obviously doesn't have yet. Then the tutorials try to be accessible by using metaphors like a "monad is a specesuit", a "monad is burrito" etc. But knowing that a monad is a buritto doesn't help the newbie who gets inscrutable compile errors after adding a second putStrLn to "hello world".

barosl 12y ago

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 writing some piece of code. Funnily enough, things were changed after I learned Rust. (I know I'm saying like a Rust zealot, but it's true!) After using Rust's `Option` type, and realizing its `.map()` and `.and_then()` are similar to `fmap` and `>>=` in Haskell, I finally began to grasp what functors and monads are. And that led me to understand the "implementation details" of Haskell. Before that, I thought `seq` was purely written in Haskell. But it wasn't. It is basically a compiler magic, and GHC specializes `seq` to allow eager evaluation. The same thing goes with the IO type; the monad itself has nothing to do with making I/O be done. I/O is possible solely thanks to the implementation details of the IO type, which resides in GHC. Plus, I can also guess that that part of GHC is probably not written in Haskell, because it is not possible to make side effects in "real" Haskell. So, Rust was my admirable Haskell teacher. (Thanks, Mozilla!) It's like a stepping stone between the imperative world and the functional world. The funny thing again is, after having fun with Rust for months, now I have less reasons to go back to learn Haskell... Rust is already too powerful, performant, and easy to understand, so Haskell feels less appealing to me. Haskell had been enviable to me in the past, but now it isn't anymore, (un)fortunately.

DanWaterworth 12y ago
There are lots of things in Haskell that I miss when I use rust, so I'd still encourage you to learn it. For example, concurrency in rust is OK, certainly nicer than other imperative languages, but Haskell has easily an order of magnitude more awesome to offer. I recently wrote a library for testing concurrent code. It's basically fuzz testing of scheduler behaviour to root out race conditions. In most languages, you'd need a special compiler or runtime to do this, in Haskell it's a library.
elektronjunge 12y ago
You can actually implement IO using unsafePerformIO fairly easily. There's a little bit of compiler magic for speed, but its not strictly necessary.

lclarkmichalek 12y ago

Ok, so we can't use the word monad because that's bad apparently. How do we answer "How does Haskell, a FP language where composition is a very important concept, compose IO actions?". Because that's almost always done using monadic actions. Aside, I agree on the List monad thing. I never ever use the list monad, why would I. But if I'm managing state (i.e. IO, Reader/Writer, Conduit etc), then why wouldn't I use the name of the language construct that Haskell provides to manage state?

tome 12y ago
> How do we answer "How does Haskell, a FP language where composition is a very important concept, compose IO actions?". You can answer "By using the combinators provided for composing IO actions". The fact that the structure encoded (some of) these operations happens to correspond to a monad is something that can be left unmentioned until later.
Chattered 12y ago
> Aside, I agree on the List monad thing. I never ever use the list monad, why would I. I use monad library functions on lists happily, and use the do-notation, particularly when I'm thinking in terms of non-deterministic computation and search.

jkot 12y ago

"Avoid success at all costs" comes to mind.

tel 12y ago
As per usual, it was meant to be read as "Avoid: (Success at all costs)" not "(avoid success) (at all costs)".
- dllthomas 12y ago
  My understanding is more that it was meant to be read both ways, but with the former understood to be serious and the latter a joke.

tjradcliffe 12y ago

This is a fair reflection on one of the biggest barriers to newbs learning Haskell (which I've tried to do a couple of times and failed, in part because the syntax is weird and poorly explained, in part because the tutorials suck, and mostly because I'm not very smart, or so I'm told.) The Haskell newb gets told two things very early on: 1) Haskell is pure pure pure! 2) Haskell can do IO via monads! These statements are contradictory. Haskell is either pure, or can do IO (via monads or anything else.) No pure language can do IO. Period. End of story. Any claim to the contrary is simply, utterly, completely false. I don't care how much you wish it was true, or think it's possible to finesse the issue. You can't. And the worst thing you can possibly do is introduce a newb to the new language via a contradiction. It's like idiots who introduce "negative resistance" with the up-front claim that a device has "negative resistance" without first introducing the generalized concept of resistance that the notion of "negative generalized resistance" depends on. Ordinary, unqualified "resistance" means V/I, not dV/dI, and if you use the unqualified term "resistance" in any other way you are deliberately and with malice aforethought creating confusion. Same goes for "negative temperature", doubled. Want to teach Haskell? Start like this: "Haskell is an effectively pure language that hides side-effects behind opaque interfaces that return new objects that represent the modified state of the world, rather than old objects that have been modified. This trickery lets us reason about Haskell code in most cases as if it was pure even though it is not." Claiming purity where there is none is terrible pedagogy. The newb will be confused and have a much harder time getting their head around the language. They will realize that the insiders are working in a different conceptual universe than they are, but won't see any way into that universe and will rightly assume that the insiders are being deliberately obtuse for the sole purpose of excluding newbs. I am, as stated above, extremely stupid. As such, I am pretty ordinary in this regard. If you want people to learn the damned language, you have to cater to stupid people like me. So discard, play-down, reject and ignore the myth of purity, because that's what it is. A myth. Haskell is not pure. In a pure language the return value of a function depends only on its arguments, but any function that does IO can return any value whatsoever, regardless of what its arguments might be. I'm sure Haskell purists will respond to this insisting that no, Haskell is really, truly, purely pure... for a certain definition of "purity". It isn't. Monads are a hack to cover necessary impurities. They are a good hack, but to redefine "pure" in such a way that accommodates monads--and this is what you have to do--is just like redefining "resistance" to accommodate "negative resistance". It's perfectly reasonable to generalize the definition of common terms, and perfectly confusing to use the generalization to imply that you mean "just perfectly ordinary resistance" when talking about "negative resistance," or "just perfectly ordinary purity" when talking about "purity with side effects hidden behind monads." There is no particular value, use or virtue in claiming Haskell is "a truly pure functional language". Claiming the language is "effectively pure for most practical purposes, so you get the provability of pure functional programming by hiding side effects behind monads" seems far more useful. Why the Haskell community is so wedded to the myth of purity--and therefore so insistent about putting monads front and center, as the article rightly decries--is not clear. But the language and the community would be better for putting the myth and the monads behind them.

chris_wot 12y ago

"Only a Sith deals in absolutes" - I see what you did there, you Sith Lord you!