What I Wish I Knew When Learning Haskell

Re:What I Wish I Knew When Learning Haskell by iskander on Saturday December 07, 2013 @08:15PM (#6868529)

They're a very simple abstract interface that happens to capture a surprisingly large class of data structures and computations. You need to implement two operations to make a monad: (1) take a normal value and put it in the monad (2) add a function to the pipeline of stuff being performed on the monad. If your language gives special syntax for these two functions, then you get to write generic code that does lots of different but related things depending on which monad that code gets called with. So, monads are just a handy and often-occurring interface. There's not a ton to understand here conceptually, you just use them and get used to the abstraction.

edit: pg likes dynamic languages, monads don't pop up there as much. They're more useful when you (1) you have special syntax for them and (2) the type system helps you keep track of what code is not in a monad, generically using any monad, or using one particular monad. So, you'll typically only see monads in expressive/high-level static languages

[ Parent | on HN ]

Re:What I Wish I Knew When Learning Haskell by sillysaurus2 on Saturday December 07, 2013 @08:22PM (#6868553)

Ok. So if I understand correctly, I could give a monad an open file descriptor to "numbers.txt" as its value, along with a "read line" function and a "convert string to int" function, and I'd get back a list of numbers?

[ Parent | on HN ]

Re:What I Wish I Knew When Learning Haskell by chongli on Saturday December 07, 2013 @10:38PM (#6868859)

Here's a weird idea for you. Imagine you could overload the semicolon in C-like languages; you could make it any function you want! This is a little bit of the idea behind monads. You can build a pipeline of chained functions and the monad you choose can make decisions in between stages. One simple example of such a decision is an early return/exit; this use case is covered by the Maybe monad.

Another cool one is the continuation monad. This lets you stop a pipeline and return a partial result, along with a function that lets you resume where you left off. This approach is commonly used in parsing, where you want to stop and restart depending on the availability of input. Another use for the continuation monad is to transform a chain of nested callbacks into linear code, eliminating callback hell.

[ Parent | on HN ]

Re:What I Wish I Knew When Learning Haskell by chowells on Saturday December 07, 2013 @08:46PM (#6868622)

You could do all that with IO, sure. But the fact that IO happens to be a monad is completely irrelevant to doing that stuff.

Monads are important because of the abstraction, not specific use cases. If you're thinking in terms of specific use cases, you're already wrong. The monad abstraction lets you abstract out all kinds of control flow operations that apply to types of the right shape. It turns out to be a very general abstraction - it appears in a lot of places. And it turns out to be a sufficiently-powerful abstraction to lift any Turing-complete control flow from functions on simple types to functions on the monadic types.

So, the abstraction is general and powerful. Why isn't it used in all languages? Because most languages don't have anything like the bookkeeping mechanisms necessary to make it syntactically lightweight. Haskell, on the other hand, is sufficiently not-terrible to provide enough facility for abstraction to actually take advantage of monads. (All programming languages are terrible. Haskell is just less terrible than most.)

[ Parent | on HN ]