Haskell.CodeCompared.To/OCaml

Haskell needs a named main :: IO () entry point that the runtime calls once. OCaml has no single required entry point at all — a source file is a sequence of top-level bindings evaluated in order, and let () = ... is simply a binding whose left side is the unit pattern, run purely for its side effect. print_endline is the direct analogue of putStrLn.

Haskell needs do-notation to sequence IO actions, since it is sugar over chained monadic binds. OCaml is strict, so it needs no monad for this at all: the semicolon ; simply evaluates the left expression (which must have type unit), discards the result, and evaluates the right expression next, in the order written.

Both languages check the format string against the argument types at compile time — a rare guarantee most languages' printf-style functions lack entirely. Haskell achieves it through Text.Printf's typeclass-based variadic trick; OCaml achieves it because the compiler gives Printf.printf's format string its own special-cased type, format, parsed directly by the type checker.

Both languages bind names with let, and in both, that binding cannot be reassigned — number = 99 afterward is a compile error in either language. This is one of the strongest syntactic and semantic overlaps between the two: the ML-family let is shared, not merely similar.

Both languages make mutation explicit and opt-in rather than the default — but they wall it off differently. Haskell requires an IORef to live inside the IO monad, so the type signature IO Int announces "this may mutate" before you even read the body. OCaml's ref needs no such monadic context at all: ref 0 allocates a mutable cell anywhere, ! dereferences it, and := assigns it, all as ordinary expressions — mutation is real and unrestricted, just not the default the way it would be in Ruby.

Both languages let a new let introduce a fresh binding that shadows an older one with the same name, without being an error — each is a distinct binding under the hood, not a mutation of the first. Haskell idiom favors a trailing prime (value') to keep them visually distinct; OCaml programmers commonly just reuse the bare name, since the shadowing is unambiguous to the compiler either way.

Neither function needed a type annotation — both compilers inferred the full type from how number is used. This is the single most important thing the two languages share: a Hindley-Milner-family inference engine that can reconstruct an entire function's type from its body, with annotations serving as documentation and compiler-checked sanity checks rather than a requirement.

This is the sharpest type-system gotcha for a Haskeller arriving from the same ML family. In Haskell, numeric literals are polymorphic through the Num typeclass, so 2 + 3.5 just works: 2 is inferred as a Double to match. OCaml has no operator overloading at all — + works only on int, and a completely separate operator, +., works only on float. Writing 2 + 3.5 in OCaml is a compile error; the literal 2 must be written 2.0 and combined with +..

Both languages let you annotate a function's parameter and return types, and both will infer them perfectly well without any annotation at all. The syntax differs — Haskell's separate :: signature line above the definition versus OCaml's inline (name : type) parameter annotations — but the underlying philosophy, "annotate for the reader, not for the compiler," is identical.

Both languages use a dedicated infix operator for string concatenation rather than overloading +, but they picked different symbols: Haskell's ++ is the same operator used to concatenate any list (since a String is [Char]); OCaml gives strings their own dedicated operator, ^, distinct from its list-concatenation operator @, because an OCaml string is not a list under the hood.

Both languages treat strings as immutable values by default, and both build a transformed copy rather than mutating in place — Haskell's map over a String (really a [Char]) and OCaml's String.map do the identical job. OCaml does still expose a genuinely mutable Bytes.t type for the rare case in-place mutation is needed, with no Haskell equivalent at all outside of the ST or IO monads.

Haskell's length and !! work on any list, strings included, and both are O(n) since a Haskell String is a genuine linked list of characters. OCaml strings are packed byte arrays, so String.length and the special .[index] syntax are both O(1) — a real performance difference that follows directly from the two languages' different underlying string representations.

The bracketed list literal looks almost the same, but two symbols swap meaning between the languages: Haskell's cons operator is : and its list-literal separator is ,; OCaml's cons operator is :: and its list-literal separator is ;. Reaching for a comma inside an OCaml list literal ([2, 3, 4]) is a classic Haskeller mistake — it does not error the way you'd expect, since OCaml would parse [2, 3, 4] as a single-element list containing a tuple.

This is a genuine capability gap, not just a syntax difference. Haskell's Data.Array is immutable — numbers // [(2, 99)] builds an entirely new array, leaving the original untouched (mutable arrays exist only via IOArray/STArray inside IO/ST). OCaml's array is mutable by default and in place — numbers.(2) <- 99 updates the existing array directly, with no monad, no wrapper type, and no new allocation, because OCaml never tried to make mutation the exceptional case in the first place.

The three functions have direct one-to-one counterparts — List.map, List.filter, List.fold_left/List.fold_right — and behave the same way. The idiomatic style of chaining them differs: Haskell tends to nest function calls inside-out or use . composition, while OCaml's own |> pipe operator (which later inspired F#'s and Elixir's identical operator) lets the pipeline read top-to-bottom in the order it executes.

The recursive structure and the cons pattern itself are identical in spirit — split into empty-list and head/tail cases. Notice the rec keyword on the OCaml side: unlike Haskell, where every top-level binding can refer to itself and its siblings automatically, OCaml requires let rec (rather than plain let) whenever a function needs to call itself.

Both languages treat if as an expression that produces a value, not a statement — both branches are mandatory, and both must have the same type, because the whole construct must evaluate to one value. This is a place where OCaml and Haskell agree with each other and diverge from most C-descended languages, where if is a statement and a separate ternary operator is needed for the expression form.

This difference follows directly from strictness. OCaml has a genuine imperative for ... to ... do ... done loop construct built into the language, because iterating and mutating are ordinary, unremarkable operations in a strict language. Haskell has no loop construct of any kind — forM_ is an ordinary library function (not special syntax) that repeats an IO action once per list element, the closest Haskell gets to "looping".

OCaml's built-in while ... do ... done reads exactly like the imperative loop a Rubyist or a C programmer already knows, because mutable state and repeated mutation are ordinary in a strict language. Haskell has to build the equivalent by hand out of an IORef and explicit recursion — there is no dedicated loop syntax to reach for at all, since looping-via-mutation is exactly the pattern Haskell's design steers you away from.

Structurally these are the same construct with different keywords: case number of versus match number with, both followed by a list of patterns and results, both defaulting to _ as the catch-all. Both compilers also share the same valuable guarantee: an incomplete match triggers a compiler warning (and, in OCaml, can be promoted to a hard error), rather than silently doing nothing.

Haskell's pipe-guard syntax on an equation and OCaml's when clause on a match arm do the identical job: attaching an extra boolean condition to a pattern that must also hold for that branch to be chosen. OCaml's when guard is written per-arm inside one match, where Haskell's guards live directly on the function equation instead of inside an explicit case.

The underscore wildcard _ means the same thing in both. The "as"-pattern also transfers, just with the keyword on opposite sides: Haskell writes whole@(first : _) with the binding name first; OCaml writes (first :: _) as whole with the binding name last — same capability (bind both the whole value and a piece of its structure in one pattern), mirrored syntax.

A genuine, easy-to-forget gotcha: every Haskell binding, top-level or let, can refer to itself (and its siblings) with no special keyword — recursion is simply the default. OCaml requires the explicit rec keyword: plain let factorial n = ... factorial (n - 1) ... without rec either fails to compile (the inner factorial is unbound) or, worse, silently refers to some unrelated outer binding of the same name if one exists.

Every function in both languages is curried automatically — a three-argument function is really a chain of three one-argument functions, and supplying fewer arguments than the full arity yields a new function waiting for the rest, with no special closure syntax needed in either language. This is a deep shared trait of the ML lineage, not a coincidence.

OCaml's |> is where the pipe operator was born — F#, Elixir, and others all copied it directly from OCaml, and it is idiomatic, everyday OCaml. Haskell has no built-in equivalent; its most common combinator, $, runs the opposite direction (low-precedence right-to-left application, avoiding parentheses rather than sequencing a pipeline), and the left-to-right pipe some Haskellers reach for, & from Data.Function, is a small library addition rather than a core, ubiquitous idiom.

This is a near-perfect one-to-one correspondence: Haskell's Just/Nothing and OCaml's Some/None are the identical type in every way that matters, both making "this might not have a value" a type-level fact the compiler forces you to handle, rather than a runtime nil that can silently propagate.

Both languages force you to handle both cases through ordinary pattern matching — there is no way to reach for the wrapped value without acknowledging the empty case might occur instead, in either language. The syntax is nearly a character-for-character match once you swap Nothing/Just for None/Some.

Haskell's fmap comes from the general Functor typeclass, so the identical call also works on lists, Either, and any other functor — one function, many types. OCaml has no typeclass mechanism to unify this, so each module provides its own separately named function: Option.map for options, List.map for lists, and so on — same behavior for options specifically, but no shared abstraction tying them together.

This is nearly a direct syntax transliteration: Haskell's data Shape = Circle Double | Rectangle Double Double and OCaml's type shape = Circle of float | Rectangle of float * float declare the identical sum type, with capitalized constructor names in both languages and exhaustive pattern matching enforced by both compilers.

A recursive algebraic data type — here a binary tree referencing itself in its own definition — works identically in both languages, and the recursive traversal function has the same two-case shape: a base case for the empty constructor, a recursive case that processes both children. This pattern (self-referential sum types plus structurally recursive functions over them) is the bread and butter of both languages equally.

Polymorphic variants (the backtick-prefixed constructors, like \`Red) are a genuinely OCaml-specific feature with no Haskell counterpart. An ordinary OCaml variant, like an ordinary Haskell data type, must be declared before use and is a fixed, closed set of constructors. A polymorphic variant needs no declaration at all — the type is inferred structurally from the constructors actually used, and different functions can accept overlapping or open-ended sets of tags. This is a form of structural typing Haskell's nominal type system does not offer.

Record declaration, construction, and field access are all close cousins: named fields with types, construction with { field = value; ... }, and access with either a generated field-accessor function (Haskell's name person) or dot notation (OCaml's person.name). Both give you compile-time-checked field names instead of a Ruby hash's free-form, unchecked keys.

The "copy with one field changed" idiom is nearly identical syntax in both: Haskell's alice { age = 31 } and OCaml's { alice with age = 31 } both build a brand-new record sharing every field except the one named, leaving the original completely untouched in both languages.

OCaml lets a record declare any individual field mutable, and the <- assignment operator then updates that one field in place, on the existing record, with no new allocation and no wrapper type. Haskell has nothing resembling this at the record level — every Haskell record field is immutable, full stop, and the only way to "change" one is the copy-and-update syntax from the previous example, which always allocates a new record.

This is the deepest structural difference between the two languages, and it has no clean one-to-one mapping. Haskell resolves "which implementation for which type" through type classes, with the compiler picking the right instance automatically based on the type at the call site. OCaml has no type classes; the closest analogue is a module signature (module type) implemented by a specific module, but the caller must know and reference the module explicitly (Dog.describe) — there is no automatic, type-directed dispatch the way Haskell's typeclass resolution provides.

A Haskell type class declares a set of required functions that any conforming type must implement, and so does an OCaml module signature — both are, at heart, an interface. The key difference in practice is that Haskell allows many types to share one class and be used interchangeably wherever that class is required (via polymorphism over the class), while an OCaml module implementing a signature is used through its own explicit name — there is no equivalent to calling generic code against "any type implementing this signature" without extra machinery (functors, see below).

An OCaml functor — confusingly, an entirely different concept from Haskell's Functor typeclass, despite the shared name — is a function from modules to modules: MakePrinter takes any module matching the Item signature and produces a brand-new module built around it. This is higher-order module programming with no real Haskell equivalent; Haskell's typeclasses solve a related problem (making code generic over a type) through a completely different mechanism (dictionary-passing resolved by the type at the call site, not an explicit module application written by the programmer).

Both languages have real exceptions, but the cultures differ sharply. In idiomatic OCaml, raising and catching exceptions (exception, raise, try ... with) is the everyday, first-reached-for way to signal failure — helped along by strict evaluation, where an exception fires predictably at the moment the failing expression is actually evaluated. Idiomatic Haskell reaches first for pure values — Maybe and Either — specifically because laziness makes it hard to predict exactly when a thrown exception would actually fire, so exceptions are reserved for truly exceptional, unrecoverable situations.

Haskell's Either String Int (Left for failure, Right for success) and OCaml's built-in result type (Error for failure, Ok for success) are structurally the exact same two-constructor sum type, just with more purpose-specific constructor names in OCaml's version — a small but genuinely helpful readability improvement over the more generic Left/Right.

Haskell's error and OCaml's failwith both raise an exception carrying a message and unwind the program if uncaught, and both are meant strictly for "this should be impossible" situations rather than ordinary, expected failure — the same escape hatch, reached for the same way, in both languages.

This is the single deepest difference between the two languages, and nearly everything else on this page follows from it. Haskell evaluates lazily by default: an expression is not computed until (and unless) its value is actually demanded, so const 42 (error "...") genuinely never evaluates its second argument. OCaml evaluates strictly (eagerly) by default: every function argument is fully evaluated before the function body runs, full stop — calling the equivalent function with a failing expression as an argument would raise immediately, whether or not the body ever looks at that argument.

Because Haskell is lazy by default, an infinite list like [1 ..] is completely ordinary — take 5 only forces the first five cons cells, and the rest are simply never computed. OCaml's ordinary list is fully strict and cannot represent an infinite list at all (building one would loop forever trying to construct the whole thing). OCaml provides a separate type, Seq.t, built from explicitly lazy thunks (fun () -> ...), specifically for this use case — laziness is available, but it is an opt-in, explicitly-typed choice rather than the default evaluation strategy.

Because pure Haskell code has no inherent notion of "when," the language specification deliberately leaves evaluation order of pure expressions unspecified except where IO or explicit sequencing forces an order (Debug.Trace.trace is a debugging escape hatch precisely because ordinary pure code offers no such guarantee). OCaml's strict, eager model gives it a concrete, specified evaluation order for these same constructs, so interleaved side effects in ordinary "pure-looking" code are predictable in a way Haskell never promises.

This is close to a line-for-line transliteration — both versions pick the first element as pivot, filter the rest into two partitions with the same two predicates, and recursively sort and reassemble them with concatenation (++ in Haskell, @ in OCaml). The near-identical elegance here is not a coincidence: pattern matching on lists plus list comprehension/filter idioms are a shared strength of the whole ML/Haskell family.

Both naive versions recompute the same subproblems exponentially many times, with identical two-base-case, one-recursive-case structure. Adding memoization diverges sharply, though: idiomatic OCaml reaches for a genuinely mutable Hashtbl cache updated in place as a side effect (natural in a strict, mutation-friendly language), while idiomatic Haskell instead builds a lazily-evaluated, self-referential infinite list or array of results — memoization achieved entirely through laziness, with no mutable cache at all.

One last look at how closely the two languages align on the exact combination this page keeps returning to — a recursive algebraic data type plus a structurally recursive function pattern-matching over it. Swap data/type, | placement, and capitalization conventions, and the two definitions are otherwise a direct translation of each other, right down to using the same built-in max function by the same name.