3 ms·

Are there any nice, one-step-at-a-time introductions to Haskell that stick to lowly, commonplace English rather than insisting that "just a monoid in the catego

Are there any nice, one-step-at-a-time introductions to Haskell that stick to lowly, commonplace English rather than insisting that "just a monoid in the category of endofunctors" is universally preferable because technically it technically is technically more technically correct?

chongli 11y ago
I haven't read it but you might want to check out coolsunglasses'[0] book, Haskell Programming from first principles[1]. He wrote it specifically for people who have no background in this stuff. [0] https://news.ycombinator.com/user?id=coolsunglasses https://news.ycombinator.com/user?id=coolsunglasses [1] http://haskellbook.com/ http://haskellbook.com/
ucarion 11y ago
To add to chongli's suggestion, I learned Haskell (and had a great time doing it) from "Learn You a Haskell": http://learnyouahaskell.com/ http://learnyouahaskell.com/
wetmore 11y ago
Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke. What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g) For monads in Haskell, this is the technically correct definition. That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.
- dllthomas 11y ago
  Cleaning up the parent's formatting as I think it's too late for them to edit. Content is unchanged: That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)
merijnv 11y ago
To be fair, I don't know a single person that explains things using > "just a monoid in the category of endofunctors" In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell. As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

chongli 11y ago

I haven't read it but you might want to check out coolsunglasses'[0] book, Haskell Programming from first principles[1]. He wrote it specifically for people who have no background in this stuff. [0] https://news.ycombinator.com/user?id=coolsunglasses https://news.ycombinator.com/user?id=coolsunglasses [1] http://haskellbook.com/ http://haskellbook.com/

ucarion 11y ago

To add to chongli's suggestion, I learned Haskell (and had a great time doing it) from "Learn You a Haskell": http://learnyouahaskell.com/ http://learnyouahaskell.com/

wetmore 11y ago

Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke. What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g) For monads in Haskell, this is the technically correct definition. That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.

dllthomas 11y ago
Cleaning up the parent's formatting as I think it's too late for them to edit. Content is unchanged: That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)

merijnv 11y ago

To be fair, I don't know a single person that explains things using > "just a monoid in the category of endofunctors" In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell. As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...