Difference between revisions of "How to read Haskell"

From HaskellWiki
Jump to navigation Jump to search
(use haddock)
m
Line 10: Line 10:
 
</haskell>
 
</haskell>
   
  +
----
== Hint: use the haddock ==
 
  +
  +
== Practical tips ==
  +
 
=== Hint: use the haddock ===
   
 
When reading a long piece of Haskell code, one which is broken up into many modules, you should consider keeping a browser window open with the auto-generated API documentation on the side (if any).
 
When reading a long piece of Haskell code, one which is broken up into many modules, you should consider keeping a browser window open with the auto-generated API documentation on the side (if any).

Revision as of 11:21, 3 August 2006

This stub is intended to become a tutorial on reading Haskell. It's aimed at the non-Haskeller who probably doesn't care too much about trying to write code, but wants to understand it.

The tutorial

...needs to be written

-- insert here some horrible (for the non-Haskeller) long example
-- something we can work through slowly (and show why we find it beautiful)

Practical tips

Hint: use the haddock

When reading a long piece of Haskell code, one which is broken up into many modules, you should consider keeping a browser window open with the auto-generated API documentation on the side (if any).

What the heck is xyz?

One problem you might face when reading Haskell code is figuring out some cryptic entity like xyz is.

Hint: order doesn't matter

Outside of a monad, it really doesn't matter what order things in Haskell code appear. So if you see something like this...

foo = whatTheHeckIsBar

you should take into account that whatTheHeckIsBar may be defined somewhere below foo

  • scope in a nutshell
  • except for monads? explain

Hint: use grep

(This might seem really obvious, but it's sometimes easy to forget)

Or use the search feature of your favourite text editor. It's probably defined right there before your eyes, and if it's true to Haskell style, the definition is probably so small you blew right through it. In vi, for example, you could do /= *xyz which searches for =, an arbirtary number of spaces, and then xyz.

Barring that, xyz might be defined in some different module in the code you downloaded. You can look for telltale signs like

import Manamana (xyz)

But note that sometimes programmers get lazy, and they don't specify that xyz should be imported. They just let rip with

import Manamana

So solution number 3 would be do something like grep xyz *.lhs *.hs (Note that literate programs sometimes use non-literate code, so search in both lhs AND hs)

A fourth idea, if you can't find something, is to look it up in Hoogle

Hint: use type signatures

When you see stuff like this

-- example please!
foo :: Bar Ping Pong -> Baz Zed Dubya -> IO (DoublePlus Good)

...don't fight it! These are type signatures and they are an incredibly useful way of getting a rough idea what a function is supposed to do.

elaborate

What confuses non-Haskellers

Since this tutorial is not yet written, we encourage you to note here the things which confuse non-Haskellers about the code code.

  • layout instead of semicolons?
  • super-super-concise stuff (things using liftM and liftM2)
  • the difference between
    x <- foo
    
    and
    x = foo