Haskell.CodeCompared.To/Clojure

Haskell requires a named main :: IO () entry point that the runtime calls once. Clojure has no entry-point requirement at all — top-level forms simply evaluate in the order they are read, closer to a REPL session than a compiled program with a fixed starting point.

Haskell needs do-notation to sequence IO actions, since it desugars to chained monadic binds. Clojure is strict, so top-level forms simply evaluate one after another in the order written — no monad or block syntax required for plain sequencing.

Haskell's print uses the Show typeclass, deriving a textual representation for (almost) any value. Clojure's prn prints any value in a re-readable, machine-parseable form — every built-in data structure already knows how to print itself, needing no derivation step at all, since Clojure has no typeclass system for this to opt into in the first place.

Haskell's let ... in and Clojure's let both introduce local, immutable bindings scoped to the following expression — genuinely close in spirit and even in visual shape, once the parentheses are accounted for.

This is a genuine, deep philosophical alignment rarely found elsewhere on this site: both languages treat immutability as a CORE VALUE, not merely a syntactic default that gets opted out of constantly. Clojure, despite being dynamically typed, is culturally as committed to "prefer never mutating" as Haskell is structurally — consing a new element onto numbers leaves the original completely untouched in both languages.

Like Scheme, Clojure has no static type system at all: add has no declared or inferred type anywhere, and (add "two" 3) would run right up until the moment + itself rejects the string argument at runtime — there is no separate compile-time check that could catch this earlier, the way GHC would reject a mistyped call to Haskell's add before the program ever runs.

Clojure's clojure.spec library can describe and validate a function's expected shapes, but it is opt-in tooling layered on top of the language, checked (if at all) at runtime via explicit instrumentation calls — a fundamentally different guarantee from Haskell's type checker, which runs unconditionally, for every function, before the program is ever executed at all.

Haskell's ++ is the general list-concatenation operator, since a String is really [Char]. Clojure's str concatenates any number of arguments, converting each to its string representation first — closer to a universal "stringify and join" function than a dedicated concatenation operator.

A Clojure keyword like :ok is a self-evaluating, interned atomic value that springs into existence at the point of use — no declaration required, comparable by identity, and idiomatically used as map keys and lightweight tags everywhere. Haskell has no equivalent data type; the closest comparison is a nullary constructor of a data type, which — unlike a Clojure keyword — must be declared upfront and belongs to one specific, closed type rather than a shared, open universe of interned atoms.

Haskell has one primary sequential collection — the singly-linked list. Clojure offers a genuinely richer default: [1 2 3 4 5] is a persistent VECTOR (efficient random access and append), a structurally different and more commonly reached-for collection than Clojure's own cons-cell list (built with (list 1 2 3)), which plays the role closer to Haskell's actual list representation.

Both languages call these operations map and filter, with the same argument order (function first). Clojure's #(* % 2) reader-macro shorthand for a one-argument lambda is unique to Clojure — % refers to the single implicit argument, more compact than either language's full lambda syntax.

Both languages provide a persistent, immutable map as a first-class value: Haskell's Data.Map (usually imported qualified) and Clojure's literal { } map syntax, needing no import or constructor call at all. Both a missing-key Map.lookup and Clojure's get return an absence marker (Nothing versus nil) rather than throwing.

Both languages achieve efficient "copy-on-write" behavior the same way: through structural sharing, where a new value reuses most of the internal structure of the old one rather than copying it wholesale. This is why prepending to a Haskell list or conj-ing onto a Clojure vector is cheap despite immutability — a shared implementation strategy, not a coincidence, since both languages need it to make immutability-by-default practical at all.

Haskell's Maybe a is a real, compiler-checked wrapper type — a Just x is a genuinely different value from a bare x, and the compiler forces every caller to unwrap it explicitly. Clojure has nothing resembling Maybe at all: a missing lookup simply returns nil directly, the SAME nil used for every other kind of absence in the language, with no wrapper and no compiler enforcement that anyone ever checks for it.

Clojure's core sequence functions are deliberately designed to treat nil as an empty collection rather than raise an error — a deliberate ergonomic choice called "nil-punning." Haskell has nothing resembling this: attempting to call a list function on Nothing is a straightforward type error, since Nothing and [] are not even the same type. Nil-punning makes Clojure code more forgiving of missing values, at the cost of Haskell-style compiler certainty about which values might actually be absent.

Haskell's (first:rest) pattern and Clojure's [first & rest] destructuring both pull the first element and the rest apart in one binding. Clojure's destructuring is a let-binding feature bolted onto an otherwise dynamically-typed language, not a full pattern-matching system tied to a closed set of constructors the way Haskell's is.

This is a real gap for a Haskeller. Core Clojure has no construct that matches on a value's SHAPE the way Haskell's case destructures a constructor's payload — cond is a chain of independent boolean tests, closer to a sequence of if/else ifs. (The separate core.match library adds genuine pattern matching, but it is an external dependency, not core syntax, unlike Haskell, where matching is fundamental to the language itself.)

Haskell's record pattern Person { name = personName, age = personAge } and Clojure's {:keys [name age]} destructuring both pull specific fields out of a structured value by name in one binding — Clojure's form works on any ordinary map, with no type declaration required anywhere, where Haskell's form only works because Person was already declared as a record type.

Haskell spells a lambda \x -> ... (the backslash evoking the Greek letter lambda). Clojure spells the same idea (fn [x] ...), or — as seen in earlier rows — the terser reader-macro shorthand #(* % %) when the parameter is used positionally and only once or twice.

Haskell's foldl and Clojure's reduce take the same pieces — a combining function, an initial accumulator, then the collection — in the same order, though Clojure's name follows the more common cross-language convention (reduce, matching Python, JavaScript, and Ruby) rather than Haskell's fold family naming.

In Haskell, add 5 alone is already valid — every function is secretly a chain of one-argument functions. Clojure has no automatic currying, but its partial function does the same job explicitly: (partial add 5) returns a new function with the first argument already supplied, functionally identical to Haskell's automatic partial application, just spelled out as an explicit call.

A base-case clause and a recursive clause — Haskell writes them as separate pattern-matched equations, Clojure writes the equivalent single branch inside one if. Both are idiomatic for exactly this shape of recursion in their respective languages.

GHC silently and reliably optimizes an accumulator-passing recursive call like sumList's into a constant-stack-space loop — no special syntax needed. Clojure, running on the JVM (which has no native tail-call optimization), requires the recursive call to be spelled explicitly with recur in tail position — using an ordinary self-call instead of recur would eventually overflow the stack on a long enough list, a real, concrete difference from Haskell's automatic guarantee.

This is a rare, genuine parallel: unlike every strict language this site compares Haskell to, Clojure's core sequence functions are LAZY BY DEFAULT. (range) with no arguments produces a genuinely infinite lazy sequence, and take forces only as many elements as are actually needed — the same behavior, and nearly the same syntax, as Haskell's take 5 [1..].

Chaining filter, map, and take in Clojure evaluates elements one at a time without ever materializing an intermediate collection — exactly the same efficiency property Haskell's laziness gives a chain like filter even . take 3. Of every language this site compares Haskell to, Clojure is the only one where "just chain the lazy functions" is the default behavior rather than something requiring an explicit lazy type or deferred computation.

Both languages default to lazy sequence processing for exactly this reason — summing a million numbers never needs to hold the whole collection in memory at once in either language. Where Clojure differs from Haskell in practice is realized-vs-unrealized bookkeeping: Clojure programmers occasionally reach for doall/dorun to force a lazy sequence eagerly (usually for side effects), a concern that simply does not arise in Haskell, where laziness is even more pervasive and forcing is almost always implicit.

Haskell composes function VALUES right-to-left with ., reading inside-out unless you introduce intermediate names. Clojure's ->> ("thread-last") macro threads a value through a sequence of calls top-to-bottom, inserting it as the LAST argument to each — the same transformation, but read in execution order, closer to a Unix pipe or F#'s |> than to Haskell's own idiom.

Clojure actually has TWO threading macros with no single Haskell parallel: -> ("thread-first") inserts the threaded value as the FIRST argument to each call — natural for functions like assoc/dissoc that take the map first — while ->> ("thread-last") inserts it LAST, natural for sequence functions like map/filter that take the collection last. Haskell's single composition operator makes no such distinction, since it just composes functions as values regardless of argument position.

Clojure's defprotocol/defrecord combination offers real, type-directed dispatch: calling describe on a value automatically finds the implementation registered for that value's concrete type, the same "the runtime picks the right implementation for the type" behavior Haskell type classes provide — a genuinely closer match than Scheme has anything for, since Scheme has no polymorphic dispatch mechanism at all. The difference: Clojure resolves this at RUNTIME based on the value's type, since there is no compile-time type checker to resolve it earlier the way Haskell's does.

Clojure's defmulti/defmethod can dispatch on ANY function of the arguments — here, a :category keyword pulled out of an ordinary map, not the value's type at all. Haskell's type-class dispatch is always keyed on a type and only a type; there is no way to make two values of the identical type resolve to different instances based on their runtime CONTENTS the way a Clojure multimethod effortlessly can.

A quoted Clojure form like '(+ 1 2) is simultaneously a piece of Clojure syntax AND an ordinary Clojure list value — printable, inspectable, and passable around as data, then evaluated later with eval if desired. Haskell has no equivalent: its AST is an internal compiler detail, never a value ordinary code can construct or manipulate directly. This "code is data" property (homoiconicity) is the foundation Lisp macros are built on.

The single quote before a form tells Clojure "treat this as literal data, do not evaluate it" — the same three symbols (+ 1 2) mean two entirely different things depending on whether a quote precedes them. Haskell has no comparable built-in mechanism for suppressing evaluation of an expression written in ordinary syntax; every Haskell expression is always evaluated (or, thanks to laziness, evaluated on demand) — never held back as inert data the way a quoted Clojure form is.

Haskell's IORef and Clojure's atom both wrap a single mutable value behind a controlled interface: newIORef/(atom 0) to create it, modifyIORef/swap! to update it with a function, and readIORef/@ (deref) to read it. Clojure's swap! additionally guarantees atomicity via compare-and-swap retry under concurrent access, a safety property IORef alone does not provide — Haskell would reach for MVar or STM for that guarantee instead.

Both languages require an explicit, separate mechanism to opt into mutation at all — a plain Haskell let and a plain Clojure def are both immutable, and neither offers a bare reassignment operator for an ordinary binding. This is a real point of alignment: Clojure, despite being dynamically typed and often assumed to be "more permissive" than Haskell, is just as strict about requiring explicit opt-in machinery (an atom, ref, or agent) before a value can be changed in place.

Haskell uses ordinary infix notation with operator precedence, familiar from arithmetic. Every Clojure operation — arithmetic included — is a prefix call wrapped in parentheses, with no operator precedence to reason about at all: (+ 1 (* 2 3)) must nest the multiplication explicitly, since there is no *-binds-tighter-than-+ rule the way ordinary math notation has. This is consistently the single biggest visual adjustment for a Haskeller new to any Lisp.

Haskell's if requires a genuine Bool — 0 is not even the right TYPE to put there, so this kind of mistake is a compile error, not a surprise at runtime. Clojure has looser "truthiness": every value is truthy in a boolean context EXCEPT nil and false — meaning 0, empty strings, and empty collections are all truthy, unlike several other dynamically-typed languages (Python, JavaScript, Ruby all treat at least some of those as falsy), and unlike Haskell, where the question cannot even arise.