Core Syntax at a Glance
This reference covers the syntax and functions you'll reach for constantly: function definitions with pattern matching, for example a recursive Fibonacci function matching on 0, 1, and n, let/where for local bindings, case expressions for branching, list comprehensions such as doubling every even number in a range, and the core types Maybe, Either, and tuples. Keep this as a lookup table rather than a tutorial, the goal is to jog your memory on syntax you've learned once, not to teach these concepts from scratch.
Cricket analogy: A quick-reference sheet is like a fielding-positions cheat card a captain might glance at between overs, not to learn fielding theory from scratch, but to quickly confirm where gully sits relative to point, the way this page reminds you of pattern-matching syntax you've already learned once.
Common Types and Type Classes
The types you'll use constantly: Maybe a, Nothing or Just x, for optional values, Either a b, Left or Right, for a value that's one of two possibilities, typically an error or a result, list a for lists, and tuples for fixed, small groupings of values of possibly different types. The type classes you'll derive or reach for constantly are Eq, for equality, Ord, for comparison, Show, for converting a value to a String for display, and Functor/Applicative/Monad for the container-like and effectful types such as Maybe, lists, IO, and Either.
Cricket analogy: Either a b mapping to Left or Right is like a DRS verdict that is always exactly one of two outcomes, out or not out, never both and never neither, mirroring how an Either value is always exactly a Left or a Right, never partially both.
Frequently Used Standard Library Functions
From Data.List: map, filter, foldr/foldl-prime, sortBy, groupBy, nub, remove duplicates, and zip/zipWith for combining two lists element-wise. From Data.Maybe: fromMaybe, mapMaybe, catMaybes for working with lists of Maybe values without manual pattern matching. From Control.Monad: forM_/mapM_ for running an IO action over a list purely for effect, and when/unless for conditional IO actions without a full if/then/else. Reach for Data.Map, lookup, insert, fromList, whenever you need efficient key-value lookups instead of linearly searching an association list.
Cricket analogy: mapMaybe filtering and transforming in one pass, like keeping only batters clearing a strike-rate threshold, is like a scout who reviews every player's stats and keeps only those clearing a threshold, discarding the rest in a single pass, rather than first filtering then separately transforming, a single Cricinfo query rather than two separate reports.
-- Function definition with pattern matching
fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)
-- case expression
describe :: Int -> String
describe n = case n of
0 -> "zero"
n | n < 0 -> "negative"
| even n -> "positive even"
| otherwise -> "positive odd"
-- List comprehension
evenSquares :: [Int]
evenSquares = [x * x | x <- [1..20], even x]
-- Maybe / Either basics
safeDiv :: Int -> Int -> Either String Int
safeDiv _ 0 = Left "division by zero"
safeDiv x y = Right (x `div` y)
-- Common Data.List / Data.Maybe helpers
import Data.List (sortBy, nub)
import Data.Maybe (fromMaybe, mapMaybe, catMaybes)
import qualified Data.Map as Map
import Data.Ord (comparing, Down(..))
topScores :: [(String, Int)] -> [(String, Int)]
topScores = sortBy (comparing (Down . snd)) . nub
lookupOrDefault :: String -> Map.Map String Int -> Int
lookupOrDefault key m = fromMaybe 0 (Map.lookup key m)
Common Idioms and Gotchas
Common gotchas: equality on Double/Float can fail unexpectedly due to floating-point representation, so compare with a tolerance instead of exact equality; string concatenation with the list-append operator on long lists is O(n) per call, so prefer Data.Text and its builder for heavy string work; and let inside do blocks doesn't need in, unlike a standalone let ... in ... expression, which trips up beginners moving between the two forms. Also remember that an open-ended range like [1..] is a valid infinite list thanks to laziness, and calling length or sum on it will hang forever, always pair infinite lists with take before forcing them.
Cricket analogy: Comparing Doubles with equality unexpectedly failing is like two different stopwatches at a cricket ground showing 18.35 overs but disagreeing at the hundredth-of-a-second level due to how each device rounds internally, visually identical but not bit-for-bit equal, which is exactly why floating-point equality needs a tolerance.
Keep this page bookmarked while working through exercises, when you forget whether fromMaybe takes the default first or the Maybe first, it's default first, fromMaybe :: a -> Maybe a -> a, a 10-second glance here beats guessing and waiting for a type error.
- Pattern matching, case expressions, and list comprehensions are the core syntax for branching and transforming data in Haskell.
- Maybe, Either, and tuples are the workhorse types for optional values, two-way results, and small fixed groupings.
- Eq, Ord, Show, Functor, Applicative, and Monad are the type classes you'll derive or use in nearly every program.
- Data.List (map, filter, foldr, foldl', sortBy, nub, zipWith) and Data.Maybe (fromMaybe, mapMaybe, catMaybes) cover most everyday list processing.
- Data.Map gives O(log n) key-value lookup and should replace linear searches over association lists once performance matters.
- Avoid exact equality on Double/Float; compare with a tolerance instead due to floating-point representation error.
- Infinite lists like [1..] are safe under laziness but must be paired with take before being fully consumed by functions like length or sum.
Practice what you learned
1. What is the type signature shape of fromMaybe?
2. Why should you avoid comparing two Double values with == in Haskell?
3. What happens if you call length [1..] in GHCi?
4. Which module provides efficient O(log n) key-value lookup, as an alternative to a linear-search association list?
5. What does mapMaybe do compared to using map followed by catMaybes separately?
Was this page helpful?
You May Also Like
Haskell Best Practices
Practical conventions and idioms for writing clean, maintainable, idiomatic Haskell code, from naming and type signatures to error handling and module design.
Haskell vs Imperative Languages
A comparison of Haskell's pure functional, lazy, declarative model against the mutable-state, sequential style of imperative languages like C, Java, and Python.
Haskell Interview Questions
Common Haskell interview topics and questions, from type-class fundamentals to monads and lazy evaluation, with explanations you can use to prepare.
Building a CLI Tool in Haskell
A practical walkthrough of structuring a command-line tool in Haskell, covering argument parsing, IO, and packaging with Cabal or Stack.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics