What's the next step to learning Haskell after monads?

Question

I've been gradually learning Haskell, and even feel like I've got a hang of monads. However, there's still a lot of more exotic stuff that I barely understand, like Arrows, Applicative, etc. Although I'm picking up bits and pieces from Haskell code I've seen, it would be good to find a tutorial that really explains them wholly. (There seem to be dozens of tutorials on monads.. but everything seems to finish straight after that!)

Answer 1

Here are a few of the resources that I've found useful after "getting the hang of" monads:

• As SuperBloup noted, Brent Yorgey's Typeclassopedia is indispensable (and it does in fact cover arrows).
• There's a ton of great stuff in Real World Haskell that could be considered "after monads": applicative parsing, monad transformers, and STM, for example.
• John Hughes's "Generalizing Monads to Arrows" is a great resource that taught me as much about monads as it did about arrows (even though I thought that I already understood monads when I read it).
• The "Yampa Arcade" paper is a good introduction to Functional Reactive Programming.
• On type families: I've found working with them easier than reading about them. The vector-space package is one place to start, or you could look at the code from Oleg Kiselyov and Ken Shan's course on Haskell and natural language semantics.
• Pick a couple of chapters of Chris Okasaki's Purely Functional Data Structures and work through them in detail.
• Raymond Smullyan's To Mock a Mockingbird is a fantastically accessible introduction to combinatory logic that will change the way you write Haskell.
• Read Gérard Huet's Functional Pearl on zippers. The code is OCaml, but it's useful (and not too difficult) to be able to translate OCaml to Haskell in your head when working through papers like this.

Most importantly, dig into the code of any Hackage libraries you find yourself using. If they're doing something with syntax or idioms or extensions that you don't understand, look it up.

Answer 2

Regarding type classes:

• Applicative is actually simpler than Monad. I've recently said a few things about it elsewhere, but the gist is that it's about enhanced Functors that you can lift functions into. To get a feel for Applicative, you could try writing something using Parsec without using do notation--my experience has been that applicative style works better than monadic for straightforward parsers.

• Arrows are a very abstract way of working with things that are sort of like functions ("arrows" between types). They can be difficult to get your mind around until you stumble on something that's naturally Arrow-like. At one point I reinvented half of Control.Arrow (poorly) while writing interactive state machines with feedback loops.

• You didn't mention it, but an oft-underrated, powerful type class is the humble Monoid. There are lots of places where monoid-like structure can be found. Take a look at the monoids package, for instance.

---

Aside from type classes, I'd offer a very simple answer to your question: Write programs! The best way to learn is by doing, so pick something fun or useful and just make it happen.

In fact, many of the more abstract concepts--like Arrow--will probably make more sense if you come back to them later and find that, like me, they offer a tidy solution to a problem you've encountered but hadn't even realized could be abstracted out.

However, if you want something specific to shoot for, why not take a look at Functional Reactive Programming--this is a family of techniques that have a lot of promise, but there are a lot of open questions of what the best way to do it is.

Answer 3

Typeclasses like Monad, Applicative, Arrow, Functor are great and all, and even more great for changing how you think about code than necessarily the convenience of having functions generic over them. But there's a common misconception that the "next step" in Haskell is learning about more typeclasses and ways of structuring control flow. The next step is in deciding what you want to write, and trying to write it, exploring what you need along the way.

And even if you understand Monads, that doesn't mean you've scratched the surface of what you can do with monadically structured code. Play with parser combinator libraries, or write your own. Explore why applicative notation is sometimes easier for them. Explore why limiting yourself to applicative parsers might be more efficient.

Look at logic or math problems and explore ways of implementing backtracking -- depth-first, breadth-first, etc. Explore the difference between ListT and LogicT and ChoiceT. Take a look at continuations.

Or do something completely different!

Answer 4

Far and away the most important thing you can do is explore more of Hackage. Grappling with the various exotic features of Haskell will perhaps let you find improved solutions to certain problems, while the libraries on Hackage will vastly expand your set of tools.

The best part about the Haskell ecosystem is that you get to balance learning surgically precise new abstraction techniques with learning how to use the giant buzz saws available to you on Hackage.

Answer 5

Start writing code. You'll learn necessary concepts as you go.

Beyond the language, to use Haskell effectively, you need to learn some real-world tools and techniques. Things to consider:

• Cabal, a tool to manage dependencies, build and deploy Haskell applications^*.
• FFI (Foreign Function Interface) to use C libraries from your Haskell code^**.
• Hackage as a source of others' libraries.
• How to profile and optimize.
• Automatic testing frameworks (QuickCheck, HUnit).

^*) cabal-init helps to quick-start.

^**) Currently, my favourite tool for FFI bindings is bindings-DSL.

Answer 6

As a single next step (rather than half a dozen "next steps"), I suggest that you learn to write your own type classes. Here are a couple of simple problems to get you started:

• Writing some interesting instance declarations for QuickCheck. Say for example that you want to generate random trees that are in some way "interesting".

• Move on to the following little problem: define functions /\, \/, and complement ("and", "or", & "not") that can be applied not just to Booleans but to predicates of arbitrary arity. (If you look carefully, you can find the answer to this one on SO.)

Answer 7

You know all you need to go forth and write code. But if you're looking for more Haskell-y things to learn about, may I suggest:

• Type families. Very handy feature. It basically gives you a way to write functions on the level of types, which is handy when you're trying to write a function whose parameters are polymorphic in a very precise way. One such example:

data TTrue = TTrue
data FFalse = FFalse

class TypeLevelIf tf a b where type If tf a b weirdIfStatement :: tf -> a -> b -> tf a b

instance TypeLevelIf TTrue a b where type If TTrue a b = a weirdIfStatement TTrue a b = a

instance TypeLevelIf FFalse a b where type If FFalse a b = b weirdIfStatement FFalse a b = a

This gives you a function that behaves like an if statement, but is able to return different types based on the truth value it is given.

If you're curious about type-level programming, type families provide one avenue into this topic.

• Template Haskell. This is a huge subject. It gives you a power similar to macros in C, but with much more type safety.

• Learn about some of the leading Haskell libraries. I can't count how many times parsec has enabled me to write an insanely useful utility quickly. dons periodically publishes a list of popular libraries on hackage; check it out.

Answer 8

Contribute to GHC!

Answer 9

Write a haskell compiler :-).