Would be nice if the cheatsheet didn't skim "algebraic data types" and instead split out product and sum types.

I covered sum types here:

http://bitemyapp.com/posts/2014-04-05-grokking-sums-and-cons...

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:

:: String -> Int -> ByteString -> IO String

and turn them into something like:

:: HttpMethod -> HttpStatus -> HttpBody -> IO HttpResponse

Improves type-safety and clarity.

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.