OCaml.CodeCompared.To/Haskell

OCaml's let () = … binds the unit pattern, which both runs the expression and asserts it has type unit. Haskell declares a value named main of type IO () — an action that, when the runtime performs it, yields nothing useful. The distinction matters more than it looks: OCaml's line performs the printing as it is evaluated, while Haskell's main is a value describing a printing that the runtime carries out afterwards. The type signature is optional here — GHC would infer it — but writing top-level signatures is universal Haskell style, where OCaml leaves them to the .mli file.

OCaml's format string is a value of a built-in format type, and the compiler reads its directives to determine exactly what arguments printf demands — a mismatch is a compile error. Haskell's printf is variadic through a type-class trick, and the format string is an ordinary String nobody inspects at compile time, so printf "%d" "text" compiles and fails at runtime. This is a rare case of OCaml having the stronger guarantee. Idiomatic Haskell mostly avoids printf in favor of putStrLn with show and string concatenation.

opam installs packages into a switch and dune compiles against whatever the active switch holds, which is why an OCaml build depends on machine state that the project files do not record. Cabal resolves dependencies per project and writes a plan, and Stack goes further by pinning an entire curated snapshot (Stackage) so that one line names a set of packages known to build together. The nearest OCaml equivalent is a lock file from opam lock, which is opt-in and much less commonly used. The default-language: GHC2021 line has no OCaml counterpart at all — see the extensions row below.

There is no OCaml analogue: OCaml has a single language whose syntax is fixed, and its extension mechanism (ppx) is a build-time preprocessor configured in the dune file rather than a per-file pragma. GHC ships well over a hundred extensions, and a real module often enables a dozen. Modern practice is to adopt a bundle — GHC2021 turns on the set considered settled — and add only the genuinely exotic ones per file. For someone reading Haskell for the first time, the pragmas at the top of a file are the fastest indication of how adventurous it is going to be.

The two operators are exactly swapped. In OCaml, :: is the list constructor and : introduces a type. In Haskell, : is the list constructor and :: introduces a type. Both readings are internally consistent and there is no way to remember which is which except by use. Note the list type too: OCaml writes int list with the constructor after its argument, Haskell writes [Int] with dedicated syntax, and for other constructors Haskell puts them first (Maybe Int where OCaml writes int option).

Haskell still has let … in and it means what OCaml means by it. But the idiomatic form for function-local helpers is where, which attaches to the whole equation and is visible from every guard in it — something let cannot do. The effect on reading is real: an OCaml function builds up to its result from the top, while a Haskell function states its result first and explains the parts below. Neither is better; the reversal takes a while to stop feeling backwards.

OCaml has one equation per function and does its case analysis inside a match, with function as shorthand for the one-argument case. Haskell distributes the cases across separate equations tried in order, which reads well for a definition by recursion and less well when only one argument is being examined among several. Both check exhaustiveness — GHC needs -Wincomplete-patterns to warn, which is on by default in -Wall but not otherwise, so a missing case in Haskell can reach runtime as a "non-exhaustive patterns" crash where OCaml would have warned at compile time.

OCaml's when clause guards one case of a match. Haskell's guards attach to an equation and are tried top to bottom, with otherwise — which is simply the value True under a more readable name — as the conventional catch-all. Neither language counts a guard toward exhaustiveness, so both columns need their fallback. Haskell guards can also bind, with pattern guards (| Just value <- lookup key table), which is the same expressive ground F#'s active patterns cover and which OCaml has no version of.

In OCaml every argument is evaluated before the call, so passing 10 / denominator to a function that might ignore it still divides. In Haskell an argument is a thunk — an unevaluated promise — forced only if and when the function demands its value, so the div above is never performed at all. This is why Haskell needs no special lazy keyword for a guard like this, and why OCaml programmers reach for lazy and Lazy.force, or wrap the value in a unit -> 'a thunk by hand. Note also the backticks: any Haskell function of two arguments can be written infix by surrounding its name with them.

OCaml has to introduce a second sequence type, Seq.t, with its own module of combinators, and code must choose between List and Seq up front — converting between them costs a traversal. Haskell has one list type that is lazy, so [1 ..] is a perfectly ordinary list, map and take are the ordinary functions, and the "streaming" version of an algorithm is usually just the algorithm. This is the most enjoyable consequence of laziness and the reason Haskell code composes as freely as it does.

A lazy foldl does not add as it goes: it builds a thunk representing ((0 + 1) + 2) + 3 … a hundred thousand levels deep, and only collapses it when the result is demanded — using far more memory than the numbers involved, and risking a stack overflow on the way down. foldl' (with the prime) forces each intermediate result, which is what OCaml's fold_left does unconditionally. The habit to build is to reach for foldl' by default, and to be suspicious of any accumulator that is not forced. Nothing in OCaml prepares you for this, because in a strict language the question cannot arise.

The two columns print the same three lines, and the whole lesson is in the code that produced them. lazy (21 * 2) builds a suspension that is not evaluated at the binding; Lazy.force evaluates it the first time and returns the stored result every time after. That is precisely what a Haskell thunk is, which is why the Haskell column needs no annotation — an ordinary let already does it, and the multiplication happens at most once no matter how many times the value is printed. The difference is that OCaml makes it a type: int Lazy.t is not int, and the force is visible at every use. Haskell makes it the ordinary meaning of let and gives you seq and bang patterns as the opt-out.

OCaml's double has type int -> int while printing to the terminal, and nothing in the signature warns a caller. Haskell will not allow that: printing produces a value of type IO (), so a function that prints has an IO in its result type, and that propagates to everything that calls it. The practical consequence is architectural rather than syntactic — Haskell pushes effects to the edges of a program because the type system makes their spread visible, and a large Haskell codebase ends up with a thin IO shell around a pure core. OCaml programmers often build the same architecture by discipline; Haskell makes it the path of least resistance.

OCaml's ; is an operator that evaluates the left side for its effect and then the right. Haskell's do is syntax that desugars into >>= and >> — so the block above is a single expression combining three IO actions into one, not a list of statements. The visible consequence is that let inside a do block has no in (it scopes to the rest of the block), and that binding a result from an action uses <- rather than let. Everything else about the shape carries over.

Neither column touches IO, because neither function does anything but compute. This is worth seeing after the previous two rows, because the impression they leave is that Haskell wraps everything in monads, and it does not: the majority of a Haskell program looks exactly like the majority of an OCaml program. What changes is that Haskell enforces the separation between this kind of function and the effectful kind, and OCaml leaves it to you. Note div for integer division, since / in Haskell is for fractional types only.

OCaml separates interface from implementation with a .mli file, so a module's public signatures live in a different file from the code and there is nothing to write inline. Haskell has no separate interface file; the export list at the top of a module controls visibility, and type signatures sit directly above each definition. Writing them is not required but is near-universal, partly as documentation and partly because inference for a top-level definition can produce a more general or more surprising type than intended. There is also a real reason to write them: without one, the monomorphism restriction can make a binding less polymorphic than you expected.

OCaml has no operator overloading at all, which is why floats get their own family of operators (+., *.) and why a numeric helper has to be written once per type. Haskell resolves * through the Num class, and Num a => a -> a reads as "for any type a that has a Num instance." The literal 2 is itself polymorphic — it means fromInteger 2 at whichever type is needed. What OCaml offers instead is a functor parameterized over the operations, which is more explicit, more verbose, and cannot be resolved automatically at the call site.

OCaml's let value = value * 2 creates a new binding whose right-hand side refers to the old one, because the new name is not in scope until after the in. Haskell's let is recursive: the name being bound is in scope in its own right-hand side, so let value = value * 2 defines a value in terms of itself and produces an infinite loop rather than a doubling. GHC will warn about the shadowing with -Wall, but the program still hangs. Use a new name, as the target column does — this is a genuine trap, and it fails at runtime rather than at compile time.

The types are written the same way ((Int, Int)) and destructured the same way. Haskell provides fst and snd for pairs and nothing for larger tuples, which is a gentle push toward records — the same push OCaml gives by not providing accessors either. The naming difference is conventional: Haskell uses camelCase for values and PascalCase for types and constructors, where OCaml uses snake_case for values and capitalizes modules and constructors.

type String = [Char] is a real type synonym: a Haskell string is a lazy singly linked list of characters, one cons cell and one pointer per character. That makes length a full traversal, indexing linear, and memory use roughly an order of magnitude worse than OCaml's packed byte array. It also means every list function works on strings for free, which is why map, filter and reverse need no string-specific variants. For real text handling Haskell programs use Data.Text, a packed UTF-16 array much closer to what OCaml gives you by default — see the next row.

Data.Text is a packed array of UTF-16 code units with the operations you would expect, and it is what any Haskell program handling real text uses. The friction is that it is not the type a string literal has, so OverloadedStrings is needed to let literals become Text, the module must be imported qualified because its names collide with the Prelude's list functions, and output needs Data.Text.IO rather than putStrLn. OCaml has one string type that is already packed, so none of this arises — though OCaml's is bytes with no encoding guarantee, where Text knows it holds Unicode.

OCaml names each conversion for both its source and destination (string_of_int, int_of_string, float_of_string) and offers nothing at all for a user-defined type — printing a record means writing a printer or reaching for a ppx deriver. Haskell's show and read are methods of the Show and Read classes, and deriving (Show, Read) on a data type generates both. Note the annotations in the target column: since read is polymorphic in its result, the type has to come from somewhere, and here there is nothing else to determine it.

OCaml separates list elements with semicolons and Haskell with commas — which is the more conventional choice, and is one more thing to retrain. The functions correspond closely: List.map/map, List.filter/filter, List.length/length, List.rev/reverse, and Haskell's live in the Prelude rather than a module, so they need no qualification. Haskell adds range syntax ([1 .. 10]) and list comprehensions, neither of which OCaml has.

The two columns produce the same pairs. Haskell's comprehension reads as set-builder notation: generators with <-, filters as bare boolean expressions, and the result expression at the front. OCaml has to compose concat_map with filter_map, and every additional generator adds a nesting level. The comprehension is also lazy, so it can draw from an infinite generator as long as something downstream stops taking. This is one of the clearest ergonomic wins Haskell has over OCaml for everyday code.

OCaml's Map.Make (String) is a functor application: it builds a module specialized to string keys, carrying the comparison function, and every operation goes through that module. Haskell's Map.insert has type Ord k => k -> a -> Map k a -> Map k a — the ordering comes from the Ord class and the compiler finds it, so there is nothing to instantiate. The qualified import is needed because Data.Map deliberately reuses Prelude names such as lookup, filter and map.

OCaml's fold_left is strict, and it is the right tool. Haskell's foldl is lazy and is almost never what you want — foldl' from Data.List is the strict version and the one to reach for, as the laziness section explained. Haskell's foldr corresponds to OCaml's fold_right but behaves very differently on long or infinite lists, since laziness lets it terminate early. Note also maximum, which raises on an empty list exactly as the OCaml column's min_int seed silently returns a wrong answer — neither is safe, and the safe versions are maximumMay-style helpers or a pattern match on the list.

Both languages give add the type Int -> Int -> Int, which associates to the right as Int -> (Int -> Int), so applying it to one argument is ordinary application rather than a special feature. This is knowledge that transfers with zero adjustment. Haskell leans on it harder in practice, because its standard library is uniformly designed for it and because operator sections — the subject of the next row — make partial application even lighter.

Both languages can write ( + ) 1 to apply an operator prefix-style to its first argument. Only Haskell can write (`div` 2) to fix the second, which is the case that comes up constantly — dividing by, subtracting from, appending to. OCaml has to write a lambda. The one Haskell gotcha is (- 1), which parses as negative one rather than a subtraction section; subtract 1 is the workaround, and it is the single most common section mistake.

OCaml's |> is "apply the function on the right to the value on the left," so a pipeline reads in execution order. Haskell's . is genuine function composition — (f . g) x is f (g x) — so the pipeline reads in the opposite order, with $ at the end supplying the argument. Haskell does have & in Data.Function, which is exactly OCaml's |>, and some codebases prefer it. Being fluent in both directions is necessary to read Haskell, because the composition style is far more common.

OCaml lets a parameter be named with ~ and defaulted with ?, and the trailing () marks the point at which the function is fully applied. Haskell has no such thing at any level, so the substitute is a record of options with a default value and record-update syntax to override fields — which is readable but requires declaring a type for what OCaml expresses in a signature. The upside is that the options record is a first-class value that can be built up and passed around, which the OCaml form cannot be.

OCaml writes origin.x, and the field name is scoped to the record type. Haskell generates a top-level function called x of type Point -> Int, so access is x origin — a function call, not a projection. That is why Haskell records are so often criticized: two record types in one module cannot both have a field named x, because both would generate a top-level x. Modern GHC softens this with DuplicateRecordFields and OverloadedRecordDot (which finally gives origin.x), but a great deal of existing code prefixes every field with its type name to work around it. OCaml has never had this problem.

deriving (Show, Eq) generates real instances at compile time, so print and == work on the type and — crucially — so does any generic code with a Show or Eq constraint. OCaml has no deriving in the language: ppx_deriving supplies it as a build-time preprocessor, spelled [@@deriving show, eq]. OCaml does have the polymorphic =, which compares any two values by walking their runtime representation, so structural equality needs nothing declared — at the cost of raising at runtime on functions and looping on cyclic values, both of which Haskell rejects at compile time.

OCaml's mutable keyword makes one field assignable with <-, and the surrounding code stays ordinary. Haskell has no mutable fields at all: the field holds an IORef, which is a mutable box, and reading or writing it is an IO action — so purity is preserved and every function that touches the counter now advertises IO in its type. Note modifyIORef' with the prime, which forces the new value; the lazy modifyIORef accumulates thunks inside the reference and is a classic space leak.

OCaml's Rectangle of float * float takes a tuple, so the constructor is applied as Rectangle (2.0, 3.0). Haskell's Rectangle Double Double is a curried function of two arguments, applied as Rectangle 2.0 3.0 — and it can be partially applied, so Rectangle 2.0 is a valid Double -> Shape. That is a genuine expressiveness difference, small but constantly visible. OCaml has an inline-record form (Rectangle of { width : float; height : float }) which Haskell matches with record syntax on a constructor.

OCaml's option with Some and None is Haskell's Maybe with Just and Nothing. The combinators correspond: Option.map is fmap, Option.bind is >>=, Option.value ~default is fromMaybe. The important structural difference is that Haskell's versions are not Maybe-specific — fmap and >>= are class methods that work for lists, Either, IO and everything else with an instance, which is the subject of the higher-kinded section below.

A Haskell newtype may have exactly one constructor with exactly one field, and in exchange the compiler guarantees it is erased — a UserId is represented at runtime as an Int, with no allocation and no indirection. OCaml's single-constructor variant is a heap block unless the compiler can unbox it, which it does for some cases via [@@unboxed]. The other thing newtype buys is a second set of type-class instances for an existing type — the standard trick for giving one type two different Ords, which Haskell's coherence rule otherwise forbids.

A polymorphic variant tag belongs to no particular type: two unrelated functions can accept overlapping sets of tags, and the inferred type records exactly which tags a value may carry, giving open extensible sums with nothing declared in advance. Haskell has no equivalent in the language. The usual approximations are a type class with several instance types, which is open but abandons exhaustiveness checking, or an extensible-sum library built on type-level lists, which works and is heavy. The other OCaml-only feature is the module system itself, covered below.

The OCaml column has to name a module, IntDescription, and the caller must know that name — the association between int and its description is carried by the module, not the type. Haskell attaches the instance to Int itself, so describe 42 resolves with nothing named at the call site, and any function with a Describable a constraint finds the instance automatically. That automatic resolution is what makes classes feel lighter, and it is bought with a rule OCaml does not impose — see the coherence row.

A functor is a function from modules to modules, so parameterizing means building a module, naming it, and calling through it. A class constraint (Ord a =>) puts the requirement on the type variable and lets the compiler find the instance, so there is nothing to instantiate and nothing to name. Both are resolved at compile time and neither costs anything at runtime — GHC passes a dictionary but specializes it away in practice. What the functor can still do that the constraint cannot is take several types and several operations at once, and be applied twice to the same type with different behavior.

Coherence is what makes describe 42 unambiguous — there is only one candidate, so the compiler never has to ask which, and two libraries can never disagree about how Int is ordered. The price is that Int cannot have two Ord instances, and OCaml's "apply the functor twice" has no translation. Haskell's two answers are both shown: pass a comparator as a value (sortBy), or wrap in a newtype whose only purpose is to carry the other instance — Down is exactly that, shipped in the standard library for this case.

OCaml's signature is a first-class thing: it can be named, reused, required by a functor, and applied to several implementations, and it hides the definition from everything outside the module including the rest of the same file. Haskell's mechanism is the module header's export list — exporting Counter without Counter(..) hides the constructor — which is simpler, entirely adequate for this purpose, and not composable in the way a signature is. There is no Haskell way to say "this module must match that interface" and have the compiler check it independently of any use.

In OCaml a type variable stands for a type. In Haskell it may stand for a type constructor, so Functor f quantifies over things like Maybe, [] and IO that are not types until applied to one. That is what makes a single fmap possible, and it is the foundation of Applicative, Monad, Traversable and the rest. OCaml can express this — by passing a module with a type 'a t, which is precisely what a functor does — but it cannot infer it, so every use is explicit and the abstraction stays local rather than becoming a shared vocabulary.

OCaml gives each type its own bind in its own module, and code written for one does not work for another. Haskell's >>= is a single method of Monad, so Maybe, lists, Either, IO, State and parser types all share it — and so does every function written generically over Monad m. That shared vocabulary is the real payoff of higher-kinded types, and the reason a Haskell programmer can reuse traverse, mapM and sequence across contexts that have nothing else in common. It is also the reason Haskell has a reputation for abstraction: the vocabulary has to be learned before ordinary library documentation reads clearly.

OCaml's binding operators are a genuine improvement over nested matching, and the syntax is very close to do. The difference is that let* must be defined for each type — the line let ( let* ) = Option.bind commits this scope to options, and using Result in the same scope means a different operator or a different scope. Haskell's do desugars to >>=, which is resolved by the Monad instance of whatever type the expression has, so the very same block works for Maybe, Either, lists and IO with nothing declared.

traverse turns a list of computations into a computation of a list, short-circuiting on the first failure — and because it is defined over Traversable t and Applicative f, the same function works for Maybe, Either, IO, and over trees and maps as well as lists. OCaml has no such function because it cannot abstract over the container and the effect at once; each combination is written out, and most codebases end up with a small pile of option_all, result_all and map_option helpers. This is worth knowing about before reading Haskell library code, where traverse is everywhere.

OCaml's ('a, 'b) result has Ok and Error; Haskell's Either e a has Right and Left, with the convention that Right is the success (a pun on "right" meaning correct). Note that the type parameters are in the opposite order — the error comes first in Either and second in result — which is not arbitrary: it makes Either e a type constructor of one argument, so it can have Functor and Monad instances that operate on the success case. That is the higher-kinded machinery deciding the shape of the type.

An OCaml exception is a lightweight declaration, raisable and catchable anywhere, and idiomatic for ordinary control flow — Not_found from a standard-library lookup is normal. A Haskell exception is a data type with an Exception instance, and while it can be thrown from pure code (via throw) it can only be caught in IO, because catching is an effect. That asymmetry pushes Haskell toward Either for anything a caller should handle and reserves exceptions for genuinely exceptional conditions and for IO failures. The try above needs its result type annotated so the handler knows which exception it is catching.

OCaml pairs each raising function with an _opt variant (List.hd/List.hd_opt, List.nth/List.nth_opt), so the safe version is discoverable from the unsafe one. Haskell's head, tail, fromJust and !! have no such companions in the Prelude; the idiomatic answer is to pattern match instead, as above, or to use a library such as safe. GHC has recently begun warning on head and tail, which is a good indication of how the community feels about them.

OCaml's ref is a record with one mutable field, and ! and := are ordinary functions usable anywhere. Haskell's IORef is the same box, but newIORef, readIORef and modifyIORef all return IO actions, so a function that uses one has IO in its type and cannot be called from pure code. That is the purity rule applied consistently rather than a limitation of the box. Use modifyIORef' rather than modifyIORef: the unprimed version stores a thunk, and a loop like this one accumulates four thousand of them in a longer program.

The OCaml function's type is int -> int whether or not it mutates, so its purity is a claim the reader has to take on trust. runST makes the same claim checkable: the ST monad carries a phantom type variable that runST quantifies over in a way that makes any escaping reference a type error, so a function using it really is pure and the compiler knows it. This is the piece of Haskell that answers "but sometimes mutation is the right algorithm" — you get the mutable array or counter, and you still get the pure signature.

An OCaml Domain is an operating-system thread with its own minor heap, so the guidance is to create roughly as many as you have cores and multiplex work across them with a library scheduler. A Haskell forkIO thread is a green thread managed by the GHC runtime, costing a few hundred bytes, so spawning one per connection or per task is normal practice. Haskell also has real parallelism across cores — the runtime multiplexes green threads onto OS threads when built with -threaded. An MVar is a mutable box that is either full or empty, so it serves as both a mutex and a one-shot channel, which is why it works as the result slot here.

In OCaml the mutex and the data are separate, and the connection between them exists only in the programmer's head — delete the Mutex.lock lines and the program still compiles and quietly loses increments. An MVar puts the data inside the lock: taking it empties the box, so no other thread can proceed until it is put back, and modifyMVar_ handles both halves. Forgetting is not expressible. OCaml 5's runtime does guarantee that a data race cannot corrupt memory, so the failure mode is a wrong number rather than a crash — but a wrong number is still wrong.

An STM action is a transaction: it runs optimistically, and if another thread touched anything it read, it is retried. The property that matters is composability — two correct transactions combine into one correct transaction with no lock ordering to design and no possibility of deadlock, which is exactly what mutexes cannot do. The type system enforces it: STM is a separate monad, so no IO can leak into a transaction that might be retried. OCaml has no equivalent in the standard library; the kcas package supplies one, and it is a library choice rather than the default.