Every language on this site so far has been imperative or object-oriented in flavor — even the ones with functional features bolted on (Java's streams, C#'s LINQ) are still fundamentally "do this, then this" languages underneath. Haskell isn't. This course treats it as what it genuinely is: the real origin point for ideas already met elsewhere on this site under different names — Rust's Option/Result, pattern matching, even the whole idea of a trait. This first chapter states the throughline that runs through the entire track: in Haskell, a function's type doesn't just describe its inputs and outputs — it tells you whether that function can have side effects at all.

GHC and GHCi

GHC (the Glasgow Haskell Compiler) is the standard toolchain; GHCi is its interactive REPL — similar in spirit to Python's or Node's own REPLs, useful for quick experiments before committing to a real file.

Your First Program

Two lines: a type signature (main :: IO ()) and the actual definition (main = ...) below it. Here's the reveal this whole course is built around: IO () is not decoration or convention — it's a real, compiler-checked part of the type system, stating plainly that main is a computation which may perform IO and produces no meaningful value ((), pronounced "unit"). Every other language covered on this site writes a main with a signature that says nothing at all about what it does — void main(), static void Main(), no signature whatsoever in Python. Haskell's says it, in the type, from line one.

The Type Signature Convention

:: reads as "has type." GHC can infer nearly every type signature on its own — but by strong, near-universal community convention, every top-level function gets an explicit signature anyway, written directly above its definition. This is a real stated best practice, not busywork: it documents intent and catches a mismatch between what a function was meant to do and what it actually type-checks as, immediately, at the point of definition rather than somewhere downstream.

Laziness — Present From Line One

One small preview before Chapter 5's full treatment: [1..] genuinely describes an infinite list, and nothing about writing it crashes the program — Haskell only computes values as they're actually demanded, and take 3 only ever demands three of them. This is the language's default evaluation strategy, not a special trick, and it touches nearly everything from here on.

Running Programs — Compiled or Interpreted

ghc compiles straight to native machine code — no bytecode, no VM, unlike Java's or C#'s own JIT-compiled-bytecode model. runghc feels interpreted for quick iteration, but it's genuinely compiling in memory first; Haskell is always compiled, never truly interpreted the way Python is.

Coding Challenges

haskell1-1's type signatures used a single arrow. This chapter explains what happens once there's more than one — and it's a genuine, structural surprise for anyone arriving from a language where "a two-argument function" is simply a fact, not a disguise.

Function Definitions & Type Signatures

A type signature reads left to right, each -> separating one more piece from the rest. This chapter is entirely about taking that arrow-chain seriously — it's the first real hint of what's coming.

Hindley-Milner Type Inference

GHC can infer almost any type without a single annotation, using an algorithm called Hindley-Milner. This is a genuinely stronger guarantee than ts1-2's own TypeScript inference: Hindley-Milner is complete for a large, well-defined core of the language — it always finds the single most general type an expression could have, with no ambiguity and no escape hatches needed. TypeScript's inference is real and useful, but structural, local, and leans on any/assertions when it can't fully work something out; Haskell's core inference doesn't have that kind of fallback because it doesn't need one.

Currying — Every Function Takes Exactly One Argument

Here's the reveal: add :: Int -> Int -> Int is really Int -> (Int -> Int) — a function that takes one Int and returns another function, which itself takes one Int and returns the final Int. Multi-argument functions don't actually exist in Haskell; every one of them is a chain of one-argument functions. add 5 genuinely produces a real, callable function — addFive — not a placeholder or a partial-application trick bolted on afterward.

Partial Application in Practice

Because currying is how every function already works, partial application isn't a special feature some functions opt into — any function can be partially applied, always, automatically. This is a real, structural difference from csharp2-3's own Func<> delegates, where building a specialized version of a general function means writing a new lambda wrapper by hand — Haskell just gives you the specialized function directly, for free, from the same definition.

Polymorphic Types — A First Look

Lowercase type variables (a) mark a genuinely polymorphic function — comparable in spirit to java2-1's own <T> generics, but without that chapter's own erasure-vs-reification question ever coming up the same way; Haskell's approach is closer to true parametric polymorphism. This is only a first look — full typeclass-based polymorphism arrives properly in Chapter 8.

Coding Challenges

rust1-2 made immutability the default, one keyword (mut) away from mutability whenever it's genuinely needed. Haskell doesn't offer that escape hatch in the first place — this chapter explains what that actually buys, precisely.

No Reassignment, Ever

x = 5 is not an assignment — it's a binding, a permanent name-to-value association. There is no mut equivalent anywhere in the pure part of the language. Once x is bound, there is genuinely no way to reassign it, ever, anywhere in its scope — a stronger guarantee than rust1-2's own default, which is real immutability, but only until mut is written.

"Variables" Aren't Variable

The word "variable" is a slight misnomer inherited from mathematics, not from imperative programming. In Haskell, x behaves exactly like a variable in an algebraic equation — a fixed name standing for a fixed value within its scope — not a storage location that can hold different things over time, the way c1-2's and java1-2's own variables genuinely can.

Referential Transparency

An expression is referentially transparent if it can be replaced by its value with zero change to the program's behavior — anywhere, at any time. Since x is never reassigned, x + x can always be swapped for 10. This is a genuine, checkable algebraic property no mutable-variable language on this site can offer: in C or Java, x + x might legitimately produce a different result on a second evaluation if something reassigned x in between.

Why This Matters — Equational Reasoning

A direct, practical consequence: Haskell code can be reasoned about the way algebra is — substitute equals for equals, refactor by simple substitution, and trust that the substitution never changes meaning. This is genuinely different from tracing through an imperative program, where "what is x right now" depends on execution history and ordering, not just the code as written.

"Mutation" via Shadowing and let/where

This can look exactly like reassignment — it isn't. The inner x is a genuinely new, separate binding that happens to reuse the name x, shadowing the outer one. The original binding is untouched and still exists, just no longer reachable by that name in the inner scope. rust1-2 also has shadowing, but Rust's shadowing coexists alongside real mutation via mut — two genuinely distinct mechanisms that can look similar. Haskell only has the one, since it has no true mutation to distinguish shadowing from in the first place.

Coding Challenges

haskell1-1 promised a genuine surprise once this chapter arrived. Here it is: Haskell has no looping construct at all. Every repeated computation in this language is written as a recursive function — and after haskell1-3's own immutability chapter, the reason why is actually a direct, structural consequence, not a stylistic choice.

Haskell Lists — Syntax & Basics

A list is either empty ([]) or an element consed onto another list (:). All elements share one type — [1, 2, "three"] doesn't type-check at all, a real difference from a dynamically-typed language's own list literals.

No for/while Loops — Recursion Is the Only Way

There is no for, no while, anywhere in Haskell. A "loop" is written as two pattern-matched cases: a base case for the smallest input, and a recursive case that handles one piece and delegates the rest back to the same function.

Why No Loops?

This connects directly back to haskell1-3: a for loop in an imperative language works by mutating a counter variable on each pass. Haskell has no mutation at all — the entire mechanism a for loop depends on simply doesn't exist to build one out of. Recursion isn't a stylistic preference here; it's the only mechanism left once mutation is off the table.

List Comprehensions

Another "this idea started here" moment: py1-6's own first look at Python's list comprehensions covered syntax that was explicitly borrowed from Haskell's (and SETL's) own comprehension notation. [expression | generator, condition] reads almost identically in both languages — a real, documented lineage, not a coincidental similarity.

Standard Recursive Patterns

map, filter, and foldr/foldl aren't special language magic — they're ordinary recursive functions living in the standard library, built exactly the same shape as sumList above. myMap here reimplements the real map's own logic directly, demystifying it completely.

Tail Recursion, Briefly

A real, honest performance note: naive recursion can build up stack frames the way sumList above does, since each call waits on the result of the next before it can finish its own addition. This isn't free, and it interacts with Chapter 5's own laziness material in ways that are sometimes genuinely surprising — full treatment is deferred there rather than glossed over here.

Coding Challenges

haskell1-1 previewed take 3 [1..] and promised this chapter would explain why it works. Here's the full answer — and it goes well beyond one convenient trick.

What Laziness Actually Means

An expression isn't evaluated until its value is actually demanded. This is the opposite of eager (or "strict") evaluation, which every other language on this site uses by default — C, Java, Python, C#, Rust all evaluate a function's arguments before the function body ever runs. Haskell evaluates an argument only if, and only when, the function body actually inspects it.

Infinite Data Structures, For Real

fibs is genuinely, structurally infinite and self-referential — it's defined using itself. This is only possible because laziness means the list is never "fully built" anywhere — only as much of it as actually gets demanded is ever computed. take 10 fibs works fine; printing fibs directly would run forever.

undefined and Bottom (⊥) — Errors That Never Surface

haskell1-1's own warn-box previewed this — here's the full explanation. Bottom (⊥) is the formal name for a computation that errors, or loops forever, or is otherwise "unfinished." Because Haskell only forces what's demanded, a bottom value can sit embedded inside a data structure and never actually detonate, as long as nothing ever forces it. This is a real, structural consequence of laziness, not an edge case.

WHNF — Weak Head Normal Form, Briefly

Laziness doesn't mean "left fully unevaluated until printed" — it means evaluated only as far as strictly necessary to make a decision, such as pattern-matching on a constructor. That partial-evaluation point has a real name, weak head normal form (WHNF) — worth knowing the term exists, without needing the full academic definition to use laziness correctly day to day.

Contrasted with java2-4's Stream Laziness

java2-4's own Java Streams are genuinely lazy — intermediate operations don't run until a terminal operation triggers them. But that's an opt-in feature of one specific API; ordinary Java expressions, method calls, and arithmetic are all strictly eager by default, Streams or not. Haskell's laziness applies to every expression in the entire language, all the time, with no separate "lazy API" to reach for — a genuine difference in scope, not just a similarity in spirit.

seq and Forcing Strictness When Needed

Laziness isn't free — haskell1-4's own tail-recursion aside foreshadowed this. A long chain of unevaluated computations (called thunks) can build up and eventually need forcing all at once, which can blow the stack. seq forces evaluation to WHNF immediately, on purpose, when a programmer decides laziness is working against them in a specific spot — a real, practical tool, not an admission that laziness was a mistake.

Coding Challenges

This is one of the two chapters (alongside Chapter 8) where this course's own "origin point" framing pays off most directly and concretely. What rust1-6 introduced as Option<T> and Result<T, E> — genuinely modeled on exactly what's covered here.

data Declarations — Product Types

Point bundles two Ints together — a product type, named because the number of distinct Point values is the product of each field's own possible values. Structurally comparable to csharp2-5's own positional records, decades earlier.

Sum Types — Multiple Shapes, One Type

This is the real deal: a value of type Shape is either a Circle or a Rectangle, never a hybrid of both — a sum type, named because the total possibilities are the sum of each variant's own. This is the direct genetic ancestor of rust1-6's own data-carrying enums.

The Real Lineage — Maybe and Either ARE Just ADTs

Here's the central reveal: Maybe and Either aren't built-in language magic — they're defined using the exact same data syntax available to any programmer, sitting in the standard library like any other type. rust1-6's own Option<T> and Result<T, E> were explicitly modeled on these two — None/Some maps directly onto Nothing/Just, and Err/Ok maps directly onto Left/Right. Same shape, same idea, arriving in Haskell decades earlier.

Recursive Data Types

A data type can reference itself — a genuine binary tree needs no more than this. Recursive data alongside haskell1-4's own recursive functions, and the two ideas reinforce each other constantly: processing a Tree almost always means writing a recursive function over it.

Record Syntax for Product Types

Named-field syntax, comparable again to csharp2-5's own record syntax — Haskell's own version predates C#'s by decades too, though honestly, it carries a real historical wart C#'s doesn't share, covered next.

Coding Challenges

Every function written since haskell1-4 has already used pattern matching, informally — sumList's []/(x:xs) equations, haskell1-6's own next. This chapter formalizes it, and traces the real lineage to Rust's match and C#'s own switch patterns.

Matching on Constructors

Multiple function equations are pattern matching — each one matches a specific constructor shape, tried top to bottom until one succeeds. This has been in use since Chapter 4 without being named.

case Expressions

case is the explicit, single-expression form of what multiple top-level equations do implicitly — useful when pattern matching is only part of a function body, not the whole thing.

Guards

A guard (| condition) adds a boolean condition on top of a successful pattern match. This is the direct conceptual ancestor of C#'s own when clause in csharp2-5's switch patterns, and Rust's own match guards — Haskell had this decades before either.

As-Patterns

all@(x:_) binds the entire matched value to all while also binding its parts (x) separately — using both the pieces and the whole without re-matching or reconstructing anything. A genuinely nice convenience with no exact equivalent named in either Rust's or C#'s own pattern syntax on this site.

Exhaustiveness Checking

GHC can warn — and, with a flag, hard-error — when a set of patterns doesn't cover every constructor of a type. Name this plainly: Haskell's pattern matching was exhaustiveness-checked long before rust1-6's own match or csharp2-7's own exhaustive switch over sealed types existed. Both of those are, in a real sense, downstream of this exact idea.

Nested Patterns

Patterns nest arbitrarily deep — matching straight into a Maybe (Tree a) in one shot, with no chain of manual unwrapping required.

Coding Challenges

Fundamentals closes with the chapter this whole course has been building toward: the mechanism behind every ==, every show, every print call used since Chapter 1 — and the real, documented origin of an idea already met on this site under a different name.

The Problem Typeclasses Solve — Ad-Hoc Polymorphism

== needs to behave differently for Int, for String, for a custom Shape — but should still be called the exact same way regardless. This is ad-hoc polymorphism: one function name, genuinely different implementations per type, dispatched based on which type is actually involved. A real, important contrast with haskell1-2's own parametric polymorphism (id :: a -> a), which works identically for every type with zero per-type customization at all.

class and instance — Defining a Typeclass

A class declares a capability; an instance provides the actual per-type implementation. Any type can gain MyEq by writing its own instance — the capability isn't limited to types the language ships with.

Eq, Ord, and Show — The Standard Trio

Eq gives ==//=; Ord gives </>/compare; Show gives the conversion to String that has been powering every print/show call used throughout this entire course, now properly explained. deriving, already used without comment in haskell1-6 and haskell1-7, is GHC automatically writing the obvious structural instance for straightforward cases.

The Real Ancestor of rust2-2's Traits

Here's the closing reveal: Haskell's typeclasses, introduced in 1988, are the direct historical ancestor of rust2-2's own trait system. Genuinely the same core idea — a capability defined separately from any specific type, implemented per-type, dispatched by which type is actually involved. Rust's own designers have been explicit about this lineage. Stated plainly, closing the loop this entire course opened back in haskell1-1: this course exists to show where these ideas really came from, and this is the clearest case of all.

How Dispatch Actually Works — Dictionary Passing, Briefly

A real, honest technical note, kept light: GHC implements typeclass polymorphism by secretly passing a "dictionary" of the relevant functions alongside any call using a typeclass-constrained function. This is genuinely different from java1-5's/csharp1-5's own vtable-based dynamic dispatch, and different again from cpp2-1's/rust2-3's monomorphization — a real, distinct third mechanism, worth naming even without going deep here.

Coding Challenges