The Haskell Cheatsheet | Hacker News Reader

The Haskell Cheatsheet

cheatsheet.codeslower.com

85 pointsrohshall25 comments

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.

Besides GHCi this is my reference shelf

- http://www.cl.cam.ac.uk/~ns441/files/thips.pdf

- http://acm.wustl.edu/functional/hs-breads.php

___________

- http://www.haskell.org/hoogle/

- http://www.haskell.org/haskellwiki/Typeclassopedia

- Prelude source and http://www.haskell.org/onlinereport/haskell2010/haskellch9.h...

_______________

- 2010, 98 reports (which are very readable, unstiff/undry docs

- use google to search stackoverflow/questions/tagged/haskell

- http://ezyang.com/haskell.html

____________

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:

http://www.haskell.org/tutorial/

http://haskell.cs.yale.edu/euterpea-2/haskell-school-of-musi...

http://www.amazon.com/Pearls-Functional-Algorithm-Design-Ric...

http://strictlypositive.org/slicing-jpgs/

http://www.fing.edu.uy/inco/cursos/proggen/Transparencias/Po...

(on about the 17th google page for "haskell cheat"

___________________

also symbolhound works pretty well for searching stackoverflow for symbolic operator/function names, e.g. haskell <$>

http://symbolhound.com/?q=haskell+%3C%24%3E

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:

  Prelude GOA> let True ? x = \_ -> x ; False ? _ = \f -> f
  Prelude GOA> True ? 4 $ 5
  4
  Prelude GOA> False ? 4 $ 5
  5
  Prelude GOA> False ? 4 $ True ? 3 $ 7
  3
  Prelude GOA> False ? 4 $ False ? 3 $ 7
  7

Pretty neat, I think.

Wow, GOA, that's a flashback. 2004??

Is it now the mark of the n00b, or something? Or just your own involvement is old?

FTR, I started playing with Haskell early 2012 and I have no idea what GOA is. All I ever see at my prompt is ghci.

If this is what GOA is, it actually sounds incredibly useful: http://www.haskell.org/haskellwiki/GHC/GHCi#GHCi_on_Acid. Looking up docs/source for modules? Enumerating typeclass instances? Yes please.

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.

On a higher level, there's Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia.

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.

http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveNPl... http://hackage.haskell.org/trac/haskell-prime/wiki/NoNPlusKP...

Is it a Cheatsheet if it has 14 pages? Serious question, English is not my mothertongue.

No, this is more of a quick reference.

Cheatsheets should be as short as possible, avoiding long explanations. For example, comments might be described as "comments: line: -- ; block (nestable): {- -}"

I would like to have some of the common language extensions, and what they do too. I can never remember the syntax for GDATs...

Start with the spelling. :)

  data GADT a where
       Constructor0 :: Field a -> Field b -> GADT (a, b)
       Constructor1 :: ...
       ...

> Anata ha Nihongo wo hanashimasuka?

You should probably change this to something like 「日本語版はこちら」 (Japanese version here), and not write it in the Latin alphabet.

It's terrible Japanese too.

My Japanese is really, really rusty, but isn't "anata" considered disrespectful?

Also, I thought the accepted transliteration was "wa", not "ha", but don't quote me on that.

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.

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.

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.

> relative to just writing the code in the order you want things to happen in an imperative language

When you write them in the order you want, you're implicitly chaining them with a primitive chain operator that's built-into the language.

In Haskell, this is exactly what "do" notation does. So in what sense is it "overcomplicated"?

Example, Python:

  def func(x, y, z):
    foo(x())
    otherFunc(lambda : y.hello(z))

Haskell:

  func x y z = do
    foo =<< x
    otherFunc (hello y z)

The syntax is slightly more verbose for chaining actions as arguments (foo), but more concise when passing around first-class actions (hello).

i remember Haskell in college...shudder

Reply on news.ycombinator.com