4 ms·

I'd ask, if you know that IO and monads are different, why your first statement was conflating the purpose of IO with the purpose of the monad interface? If I j

I'd ask, if you know that IO and monads are different, why your first statement was conflating the purpose of IO with the purpose of the monad interface? If I just totally missed a joke - ok, my mistake. But if you really don't see why it matters that the statement is false, I recommend really thinking about it for a bit. Now, on to the thing about Haskell that the endless proliferation of monad tutorials obscures.. You don't actually need to "understand" monads to use it. You can get by on type signatures and the most basic parts of do notation for a long time. In fact, that's what I did. I spent months working on haskell code, understanding the transformations I was making, but not understanding the abstractions beneath them. The first time I really grasped the purpose of the monad interface was when I decided to learn how to use the parsec library. I was a bit unsure how to combine smaller parsers into more complex ones, but just sort of tried do notation - and it worked. It worked exactly how I expected it to. And that's when I realized you could see the monad interface as "The thing you need to make do notation work like you'd expect." Even if I was still fuzzy on the details. But before that, I was making use of monad transformers. I did a poll in the #haskell IRC channel once. Almost everyone agreed monad transformers are easier to learn about than monads. There's just one simple type signature involved, and it's easy to just fit the pieces together, without a deep understanding of what they mean. They end up doing what you expect, anyway. You really can use haskell productively without understanding the underlying abstractions, so long as you are good at following the types. They're there to help you - they do the job pretty well, if you take a bit of time to learn how to apply them.

marshray 14y ago
> if you know that IO and monads are different, why your first statement was conflating the purpose of IO with the purpose of the monad interface? Just for brevity. Everyone knew what I was talking about. I'm sorry. I don't like that I was imprecise and confounded monads with the IO type any more than you do. Considering that monads in Haskell were discovered as a solution to the unweildy problem of performing I/O in a pure functional language, and that all of the early tutorials approach them from that direction, don't you think it's a teeny bit disingenuous to suddenly act like they are completely unrelated and orthogonal concepts? Maybe I should take another crack at Haskell. But I'd just started Erlang and Riak...
- jules 14y ago
  Monads were originally introduced by Wadler in his Monads for functional programming paper. In it he mentions state and I/O but also exception handling, parsing and non determinism.
  - marshray 14y ago
    Of course you're correct in the literal sense. But reading things like "The History of Haskell: Being Lazy with Class" Hudak, Hughes, Peyton-Jones, Wadler gave me a different perception. The first time the term monad is mentioned, it is in the description of the agenda of the paper: "monads and input/output (Section 7)". The second time is "May 1996. ... Monadic I/O made its ﬁrst appearance, including “do” syntax (Section 7), and the I/O semantics in the Appendix was dropped." A few more occurrences of the term and we get to section 3.2 "Haskell is pure" which says "Necessity being the mother of invention, this embarrassment ultimately led to the invention of monadic I/O, which we now regard as one of Haskell’s main contributions to the world, as we discuss in more detail in Section 7." "Section 3.8 Haskell and Miranda ... More fundamentally, Haskell did not adopt Miranda’s abstract data types, using the module system instead (Section 5.3); added monadic I/O (Section 7.2); and incorporated many innovations to the core Hindley-Milner type system, especially type classes (Section 6)." "Section 6.4 Higher-kinded polymorphism The ﬁrst major, unanticipated development in the type-class story came when Mark Jones, then at Yale, suggested parameterising a class over a type constructor instead of over a type, an idea he called constructor classes (Jones, 1993). The most immediate and persuasive application of this idea was to monads ... Jones’s paper appeared in 1993, the same year that monads became popular for I/O (Section 7). The fact that type classes so directly supported monads made monads far more accessible and popular; and dually, the usefulness of monadic I/O ensured the adoption of higher-kinded polymorphism" The entire Section 7 is called "Monads and input/output" Section 7.3 "Monadic I/O Although Wadler’s development of Moggi’s ideas was not directed towards the question of input/output, he and others at Glasgow soon realised that monads provided an ideal framework for I/O" As a Haskell novice I think I could be forgiven for having the perception that the evolution of monads in Haskell was driven by the unwieldyness of managing mutable state (such as I/O) in a pure lazy language. https://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf https://research.microsoft.com/en-us/um/people/simonpj/paper...

marshray 14y ago

> if you know that IO and monads are different, why your first statement was conflating the purpose of IO with the purpose of the monad interface? Just for brevity. Everyone knew what I was talking about. I'm sorry. I don't like that I was imprecise and confounded monads with the IO type any more than you do. Considering that monads in Haskell were discovered as a solution to the unweildy problem of performing I/O in a pure functional language, and that all of the early tutorials approach them from that direction, don't you think it's a teeny bit disingenuous to suddenly act like they are completely unrelated and orthogonal concepts? Maybe I should take another crack at Haskell. But I'd just started Erlang and Riak...

jules 14y ago
Monads were originally introduced by Wadler in his Monads for functional programming paper. In it he mentions state and I/O but also exception handling, parsing and non determinism.
- marshray 14y ago
  Of course you're correct in the literal sense. But reading things like "The History of Haskell: Being Lazy with Class" Hudak, Hughes, Peyton-Jones, Wadler gave me a different perception. The first time the term monad is mentioned, it is in the description of the agenda of the paper: "monads and input/output (Section 7)". The second time is "May 1996. ... Monadic I/O made its ﬁrst appearance, including “do” syntax (Section 7), and the I/O semantics in the Appendix was dropped." A few more occurrences of the term and we get to section 3.2 "Haskell is pure" which says "Necessity being the mother of invention, this embarrassment ultimately led to the invention of monadic I/O, which we now regard as one of Haskell’s main contributions to the world, as we discuss in more detail in Section 7." "Section 3.8 Haskell and Miranda ... More fundamentally, Haskell did not adopt Miranda’s abstract data types, using the module system instead (Section 5.3); added monadic I/O (Section 7.2); and incorporated many innovations to the core Hindley-Milner type system, especially type classes (Section 6)." "Section 6.4 Higher-kinded polymorphism The ﬁrst major, unanticipated development in the type-class story came when Mark Jones, then at Yale, suggested parameterising a class over a type constructor instead of over a type, an idea he called constructor classes (Jones, 1993). The most immediate and persuasive application of this idea was to monads ... Jones’s paper appeared in 1993, the same year that monads became popular for I/O (Section 7). The fact that type classes so directly supported monads made monads far more accessible and popular; and dually, the usefulness of monadic I/O ensured the adoption of higher-kinded polymorphism" The entire Section 7 is called "Monads and input/output" Section 7.3 "Monadic I/O Although Wadler’s development of Moggi’s ideas was not directed towards the question of input/output, he and others at Glasgow soon realised that monads provided an ideal framework for I/O" As a Haskell novice I think I could be forgiven for having the perception that the evolution of monads in Haskell was driven by the unwieldyness of managing mutable state (such as I/O) in a pure lazy language. https://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf https://research.microsoft.com/en-us/um/people/simonpj/paper...