- Learn You a Haskell for a Great Good!
- A Gentle Introduction to Haskell
- Exam
- Haskell: The Bad Parts (Part 1)
- Haskell: The Bad Parts (Part 2)
- Tail recursion
- All About Strictness
- Fixing foldl
-
Data.FoldableandData.Traversable -
Data.Function -
Debug.Trace -
Data.Text - Semigroups
-
System.FilePath - A Guide to GHC's Extensions
- JSON (
aeson) - Sending HTTP requests (
http-clientandwreq) - Calling a REST API
-
Data.Time - Regexes
- Arrows
- Lenses
-
async - Real World Haskell: Chapter 24
- Bartosz Milewski's Parallel and Concurrent Haskell lectures
-
Control.Concurrent
- Add QuickCheck tests to
Identities.hs - Project Euler 1-20
- Read the
Preludesource code - Falling Water in Haskell
- Equilibrium Index in Haskell
- Spiral Matrix in Haskell
- BST
The easiest way to get up and running with Haskell is with Stack. This will install GHC (the compiler), Cabal (the build system and package manager), and Stack (a Cabal wrapper for reproducible builds and isolated environments).
- Install the Haskell extension
:q: quit:l: load file:t: show type of expression:k: show kind of type:i: show info for function, operator, or type
https://wiki.haskell.org/Programming_guidelines
I've looked at a couple code formatters.
I've tried ormulu through the Haskell VS Code extension. It doesn't offer any sort of config, unfortunately.
I've tried stylish-haskell and played around with the config, but couldn't really get a result I like.
I mostly care about lining up = in where clauses, cases, and patterns, and lining up :: in records.
I'm not too crazy about lining up import statements, as long as they're sorted.
I don't like putting , before comma-separated elements.
I get that it keeps things lined up but just doesn't look natural.
Every formatter seems to do that.
I also prefer Allman-style braces, but both formatters want to put the first element on the same line as the brace.
And I'm not being pragmatic here and just pick a format and sticking with it. I'm fine doing that with JavaScript, but I'm coding in Haskell because I like the way it looks.
- Camel case for all names
- Types names are capitalized
- Function names are lowercase
- Defining operators should only be done by libraries
- Use spaces instead of tabs
- Format your code so you need to indent only one level at a time
-- Good
case foo of
Foo -> "Foo"
Bar -> "Bar"
-- Bad
case foo of Foo -> "Foo"
Bar -> "Bar"The "Bad" case can quickly end up with code too far to the right if clauses are nested. You can also end up with irregular indentation (# of spaces not divisible by 4 or whatever you chose) and renamings can force you to re-indent everything.
- Don't write code where a different order of evaluation may lead to incorrect results.
- Common example: reading and writing to the same file