This is actually a rather good cheat-sheet. I'm usually a fan of using cheat sheets, lists of commands, etc. to pick up new languages, but I have my reservations specifically with regard to a cheat sheet for Haskell.
The trouble with the cheat-sheet approach to Haskell stems from the fact that Haskell is quite unlike most other commonly used programming languages, i.e. substantially unlike the languages that someone reading the cheat sheet is likely to know. As a rather strictly FP language with a very strong type system, it is unlike the more mainstream languages on both a deep, technical level and on a superficial level (e.g. syntactically, the 'look' of the code, etc.). This means that you could use a cheat-sheet to write some trivial programs, but it would be hard to progress further, because you would, on a very fundamental level, not know what you are doing.
The same goes for C. While a cheat-sheet can tell you all about the printf function, data structures, types, etc., it is unlikely that a cheat sheet will be sufficiently informative on memory management, using the heap and the stack, pointer arithmetic, etc. --- the really crucial things that one needs to know to write C effectively.
While a Python programmer could use a cheat sheet or learnxinyminutes.com to pick up and write some basic programs in Ruby, it's hard to do the same for languages like Haskell or C, which really require understanding beyond what a 'cheat sheet' communicates.
I actually had made a short list of the main Haskell Cheat Sheets I could find not long ago, and even added one done by myself, mainly to help me navigate through the main Haskell Type Classes.
http://fundeps.com/posts/cheatsheets/2014-03-04-cheat-sheets...
Sorry for the shameless plug. I do intended to publish some more, I hope to have some time soon.
The first example in the cheat sheet is a sum type and they kinda point out value vs. type constructors but product types are taken for granted and they skip to record syntax.
Is there a github source for this cheat-sheet where changes can be submitted?
Edit: Numbers section should mention negative numbers. You have to use parentheses. It's a weird one-off prefix notation thingy. Example:
(-3) to get negative three.
Enumerations might mention the name of the typeclass methods the syntax is invoking. (enumFrom, enumFromThen, enumFromTo, ...). If you're writing an Enum instance while still new to Haskell you'll have to look those names anyway. (And this a cheat-sheet right?)
The mention of Haddock in the comments is good.
I'd be wary of calling the class defined typeclass methods "defaults" because there's a default keyword specifically for typeclasses that does something else.
I wouldn't describe the use of IO wrapped types and if "tricky", it's the same ole' bind (>>=), sugared via "do" syntax or not.
The sheet devotes a lot of space to do syntax. without explaining how it translates to lambdas and bind. That's a bit annoying.
Section on "let" is okay but most Haskellers use "where" anyway. The section can be dropped. Nobody really needs to use "let", that goes double if they're new.
I'd be careful about calling "Module" a module. They're closer to plain old namespaces. ML hackers get really grumpy if we (Haskell users) call our namespaces modules.
I know this inside baseball, but you might as well analogize Haskell "Module" as being like a namespace in other languages anyway. They'll understand what you mean.
Destructuring being shoved under the "let" section is REALLY weird. Destructuring falls under the purview of pattern matching. The destructuring section (it calls it deconstruction) fails to mention that you are specifically destructuring value constructors. See the earlier part of my comment about sum types, product types, type and value constructors.
The one off entry for "in" in just ridiculous.
Don't think I like the alphabetical ordering.
I wouldn't call newtype as being between type and data, although I realize why the comparison is being made. You're constructing a new type, reusing the representation of one other type, and dropping all the baggage associated with the original type so you can decide how the type gets handled.
This is often used to clean up APIs that would otherwise look like:
One off section for "Return" is just as ridiculous as the one for "In", but it's actually worse as it misleads people into thinking return has anything to do with do-syntax. It does not and it is merely a function in the Monad typeclass. I use return outside of "do" all the time. Again, a failure to explain what "do" actually is and lending more importance to mere syntax than it merits.
The trouble with the cheat-sheet approach to Haskell stems from the fact that Haskell is quite unlike most other commonly used programming languages, i.e. substantially unlike the languages that someone reading the cheat sheet is likely to know. As a rather strictly FP language with a very strong type system, it is unlike the more mainstream languages on both a deep, technical level and on a superficial level (e.g. syntactically, the 'look' of the code, etc.). This means that you could use a cheat-sheet to write some trivial programs, but it would be hard to progress further, because you would, on a very fundamental level, not know what you are doing.
The same goes for C. While a cheat-sheet can tell you all about the printf function, data structures, types, etc., it is unlikely that a cheat sheet will be sufficiently informative on memory management, using the heap and the stack, pointer arithmetic, etc. --- the really crucial things that one needs to know to write C effectively.
While a Python programmer could use a cheat sheet or learnxinyminutes.com to pick up and write some basic programs in Ruby, it's hard to do the same for languages like Haskell or C, which really require understanding beyond what a 'cheat sheet' communicates.