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, A

Answer 1

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 2

Write a haskell compiler :-).

Answer 3

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 4

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 5

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 6

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.