I think much of what this cheatsheet covers really did not give me any problems when I was first learning Haskell. Most of the syntax is well-designed and intuitive: for example, list comprehensions are just like set-builder notation from math and pattern matching does exactly what it looks like. (As an aside, I think this is a good example of why syntax does matter. I learned Haskell at the same time as Scheme, with no prior functional programming experience. Haskell's pattern matching syntax made understanding complex recursion far easier than Scheme's if and cond statements.)
Much of these difficulties are also ameliorated with a good text editor (Emacs). With good syntax highlighting and indentation, it's easy to write syntactically valid code. It also really helps to be able to easily load and run GHCi.
I think haskell has more orthogonal language features than, say, java, where everything holds together pretty well but you can't un-congeal features and use by themselves.
Books: Hudak's "School of Music" (tho I'm not sure how interesting it is unless you know how to read/play music), and the 3 books by Hutton, Thompson, and Bird. It has been remarked that the "gentle Intro" is actually kind of harsh, the Hutton and Thompson books really are gentle intro's:
Not directly related to this cheatsheet, but I was reminded by the section on operators: you can combine multiple binary operators to get something a lot like ternary operators. E.g., in ghci:
I'd forgotten about GOA -- it was a little toy project I came up with to embed lambdabot in GHCi. Looks like it was revived, moved to github, and growing happily. Major flashbacks.
I love the idea of a cheatsheet for Haskell, but I'd like to point out that the things covered by the cheatsheet are also the things I had the least trouble with starting out.
Things like the syntax of pattern-matching and datatypes I'd repeatedly Google for until I remembered, but relatively speaking it wasn't a huge time sink. The things that I did burn time on were things like getting types right inside monads, various other type-theory things, and cabal quirks.
I hope this cheatsheet helps people get started with Haskell, but my gut feeling is that the bigger hurdles will need another cheatsheet.
n + k patterns should probably not be mentioned. They are considered ugly/bad, are removed from the newest standard and support for them is behind a pragma in GHC (NPlusKPatterns) and other compilers.
Cheatsheets should be as short as possible, avoiding long explanations. For example, comments might be described as "comments: line: -- ; block (nestable): {- -}"
Yes, it's best to avoid the use of "anata", which is why I removed it. Also, it's just phrased really poorly in general - it feels like a literal translation from English, which rarely works with Japanese. And it is indeed "wa", not "ha". It's often mistakenly written as "ha" because the hiragana used for the particle "wa" (は) is read as "ha" in other contexts. I would also say that it should be "o", not "wo", since it's pronounced "o".
Although it touches on 'do' syntax, I think it could use a little more on monads, which is really the crux of haskell programming. (>>=) and return, and an example or two. Maybe something on lifting.
Monads are important, but I don't think it's fair to call them the "crux" of Haskell programming. For some reason, monads are over-dramatized and get far more attention than other great Haskell features and abstractions, possibly making Haskell's already unfair reputation as difficult and academic even worse.
Monads are important, but I don't think it's fair to call them the "crux" of Haskell programming
That may be overstating things a little, I agree. On the other hand, a programming language that can't model ordering of events along some sort of timeline isn't useful for many practical applications, and monads have so far proven to be the most effective way of introducing those concepts into Haskell's naturally timeless environment. They're also absurdly overcomplicated for modelling simple but not trivial cases, relative to just writing the code in the order you want things to happen in an imperative language. So if the goal is to get more people to use Haskell to write useful software, I would expect a lot of emphasis on monads and related concepts.
But you end up having to use monads if you want to do IO or interact with many popular packages, so being able to use monads well ends up being an essential skill for getting anything done at all.
Much of these difficulties are also ameliorated with a good text editor (Emacs). With good syntax highlighting and indentation, it's easy to write syntactically valid code. It also really helps to be able to easily load and run GHCi.