4 ms·
> 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 bre
by 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 agoMonads 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 agoOf 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 first 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 first 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...
- jules 14y agoYea, I'm not blaming anybody. Just pointing out that it was recognized that monads were useful beyond I/O in the early days. It's definitely true that I/O was a major impetus for them.
- chowells 14y agoIt's true that the abstraction got attention when they realized it solved the IO problem. (Before the IO type, IO in Haskell was painful.) It's quite possible it wouldn't have become a significant part of the ecosystem without the fact that it solved the IO problem neatly. But solving the IO problem neatly is a consequence of the value of the abstraction. It solves it so well because of its useful properties. I'd say you should take another crack at haskell sometime. But if you're learning Erlang now, stick with that for the time being. It's also got plenty to teach.