Haskell.CodeCompared.To/ReScript

Haskell requires a named main :: IO () entry point that the runtime calls once. ReScript has no such requirement — a source file compiles to an ordinary JavaScript module, and top-level statements just run in order when that module loads, with no wrapping function at all.

Haskell needs do-notation to sequence IO actions, since it desugars to chained monadic binds. ReScript is strict, so top-level statements simply execute one after another in the order written — no monad or block syntax required for plain sequencing, matching ordinary JavaScript's execution model.

Haskell's print uses the Show typeclass, deriving a textual representation for (almost) any value automatically. ReScript has no Show-equivalent typeclass at all — Js.log hands the value straight to JavaScript's console formatter, which does a reasonable job on plain data but has no notion of a derivable, customizable "show" instance the way Haskell does.

Haskell's let ... in introduces bindings scoped to the following expression. ReScript's top-level let needs no explicit in — each binding is simply available to every subsequent line, matching JavaScript's const more closely than Haskell's let.

Both languages default every binding to immutable, with no assignment operator for a plain let. Getting real mutation in ReScript means reaching for a ref cell (next row) — closer to Haskell's IORef than to JavaScript's freely-reassignable let.

Haskell reaches for IORef and threads it explicitly through IO with newIORef/modifyIORef/readIORef. ReScript's ref is a direct structural cousin: ref(0) allocates a mutable cell, := updates it, and .contents reads it — the same "explicit mutable box" idea, just without a surrounding IO monad to sequence it through.

Both languages use a Hindley-Milner-style inference algorithm inherited from the ML family, so explicit type signatures are usually optional. ReScript's double here has no annotation at all — the compiler infers int => int from how x is used, exactly as Haskell would infer Int -> Int.

Haskell places a function's type signature on its own line above the definition, using ::. ReScript annotates parameters and return types inline, using :, closer to TypeScript than to Haskell's separate signature line — both are optional whenever inference can work it out alone.

Haskell's numeric literals are polymorphic over the Num typeclass, and crossing between representations goes through fromIntegral. ReScript has no numeric-tower typeclass either, but it goes a step further at the syntax level: int and float even use different arithmetic operators (+ versus +., * versus *.), so mixing them is caught immediately, not just at the type level.

The operator is spelled identically — ++ — in both languages, though the meaning differs: Haskell's ++ is the general list-concatenation operator (since String is really [Char]), while ReScript's ++ is dedicated purely to string concatenation, since ReScript strings are genuine JavaScript strings, not character lists.

Haskell has no native interpolation — the idiomatic route is Text.Printf with positional format specifiers. ReScript reuses JavaScript's template literals directly: backtick strings with \${ } placeholders — but note ReScript will not implicitly stringify a non-string value inside one, so age needs an explicit conversion first.

Haskell's String is literally a type alias for [Char], so ordinary list functions like length apply directly. ReScript's string is a genuine, opaque JavaScript string with no list-of-characters representation underneath, so string-specific operations live in the Js.String2 module rather than the list/array functions.

ReScript does have a list type — a singly-linked list matching Haskell's representation exactly, spelled list{1, 2, 3} — but idiomatic ReScript reaches for array instead, since arrays compile directly to JavaScript arrays with no conversion cost at the JS interop boundary. This page follows that convention: the closest match in spirit is list, but the closest match in practice is array.

Both languages call these operations map and filter, in Haskell as unqualified Prelude functions and in ReScript as Js.Array2 module functions threaded through the -> pipe operator — reading data-first, left to right, rather than Haskell's function-first nested-call style.

Haskell's foldl and ReScript's Js.Array2.reduce take the same pieces — initial accumulator, then a two-argument function — but ReScript inherits JavaScript's reduce naming and argument order (accumulator first in the callback) rather than Haskell's foldl naming.

Haskell's Maybe a (Just x / Nothing) and ReScript's option<'a> (Some(x) / None) are the same idea with renamed constructors — both replace null with an explicit, compiler-enforced "value or absence" type, and both are common enough to be considered the idiomatic default in their language.

Neither compiler lets you treat an option/Maybe as if it were the bare inner value. A switch/case covering both Some/Just and None/Nothing — or an explicit combinator that forces a default, like ReScript's Belt.Option.getWithDefault — is the only way out in either language.

This is a problem category that simply does not exist for Haskell: since Haskell has no interop boundary with a language that has null, its Maybe only ever needs to represent absence that the Haskell program itself created. ReScript, compiling to and interoperating with JavaScript, needs the separate Js.Nullable.t<'a> type to safely represent a value that might arrive as null or undefined from the JS side, with Js.Nullable.toOption converting it into ReScript's own safe option.

Haskell's algebraic data types and ReScript's variants are effectively the same feature under a different name — both declare a closed set of tagged, optionally payload-carrying alternatives, and both are deconstructed with pattern matching the compiler checks for exhaustiveness. Both languages inherit this feature from the same ML lineage.

A payload-free algebraic data type in Haskell and a payload-free variant in ReScript both compile down to a small, compiler-checked closed set of tags — a near-mechanical translation, right down to the constructor names.

A recursive sum type referencing itself — the classic binary tree — translates almost line for line, though ReScript requires the explicit type rec keyword for a self-referencing type (mirroring the let rec it also requires for the recursive function), where Haskell's data declarations may always refer to themselves with no extra marker.

Haskell's case ... of and ReScript's switch { } read as dialects of the same construct: patterns tried top to bottom, an if-guard attachable to a pattern (Haskell reuses | here, ReScript borrows JavaScript's if keyword), and a wildcard _ catch-all.

Both compilers statically analyze whether a pattern match covers every possible case and warn when it does not, catching a whole class of runtime crash before the program ever executes — a shared strength both languages inherit from taking algebraic data types seriously.

Tuple destructuring is essentially identical syntax in both languages — a parenthesized, comma-separated pattern on the left of a binding, matched positionally against the tuple's shape.

Both define a named product type with labeled fields, accessed with dot syntax. ReScript's record fields are separated by , rather than Haskell's field-accessor-function style, and — unlike Haskell — ReScript infers the record's type from the fields used at the call site, so the type point = { ... } declaration is sometimes entirely optional.

Haskell's point { y = 99 } and ReScript's { ...point, y: 99 } both produce a new record with one field replaced and every other field copied automatically — ReScript's syntax borrows JavaScript's object-spread ... directly, rather than Haskell's dedicated record-update braces.

This is a genuine surprise for a Haskeller expecting ML-family defaults. Older BuckleScript/ReasonML curried every function automatically, but modern ReScript (v11+, including the 12.3 this page targets) compiles multi-argument functions to genuine fixed-arity JavaScript functions for cleaner, more predictable JS interop and performance — calling add(5) alone is a compile error, not a partial application. Partial application still exists, but only through explicitly-nested single-argument lambdas (next row).

Writing add as a chain of one-argument functions — (x) => (y) => x + y, exactly what Haskell's Int -> Int -> Int desugars to under the hood — restores the partial-application behavior a Haskeller expects, since add(5) now genuinely returns a single-argument function rather than being a call with a missing argument. The tradeoff: every call site must also use single-argument application, add(5)(10) rather than add(5, 10), so this style is not idiomatic ReScript outside of contexts that specifically want Haskell-like partial application.

Haskell spells a lambda \x -> ... (the backslash evoking the Greek letter lambda). ReScript spells the same idea x => ..., borrowing JavaScript's arrow-function syntax directly — the same syntax ReScript uses for every named function, since let add = (x, y) => x + y is simply an arrow function bound to a name.

An ordinary Haskell top-level binding may always refer to itself — no special keyword needed. ReScript requires the explicit rec keyword (let rec) before a function can call itself; without it, the function's own name is not in scope inside its own body, and the compiler rejects the self-reference outright.

Haskell's . glues function VALUES together, right-to-left, without ever mentioning the argument — genuinely point-free style. ReScript has no equivalent composition operator; instead its idiomatic tool is the -> pipe operator, which threads a concrete VALUE through a sequence of function calls left to right, closer to method chaining than to function composition.

A Haskell pipeline nests function calls and must be read from the inside out (or introduces a fresh temporary variable per step, or uses Data.Function's rarely-used & operator). ReScript's -> makes the equivalent pipeline read top-to-bottom in execution order, its single most idiomatic feature for exactly this kind of data transformation.

In both languages if produces a value rather than merely branching, and else is mandatory in both, since without it there would be no value on the false path. ReScript additionally requires braces around each branch's body, where Haskell needs none.

ReScript does compile for/while loops to genuine JavaScript loops (unlike Haskell, which has neither), but idiomatic ReScript still favors recursion and higher-order array functions over an imperative loop for anything beyond raw iteration — closer to Haskell's culture than to typical JavaScript style.

Haskell's [1..] is an ordinary list that only works because Haskell is lazy, generating each element on demand as take asks for it. ReScript is strict, like the JavaScript it compiles to, and has no way to construct an infinite sequence at all, so a bounded literal is simply how ReScript gets "the first five numbers" directly.

In Haskell, every binding is lazy unless forced otherwise — expensive is not actually computed until print demands it, and repeated use of the same thunk is cached automatically. ReScript has no thunks at all: expensive is computed the moment its binding line runs, matching ordinary JavaScript's eager evaluation exactly.

Haskell's Either String Int has no built-in ReScript equivalent shipped in the standard library the way option is — the idiomatic move is to declare your own two-case variant, commonly named result and shaped just like this (and, in fact, identical to Rust's Result). It is one extra step Haskell does not require, since Either already ships in base.

Both languages let an exception carry a typed, named identity rather than a bare string: Haskell declares one via data plus an Exception instance, ReScript via the dedicated exception keyword. Both are then caught with pattern matching — Haskell's case over the Either that try produces, ReScript's catch { } block matching directly on the exception's constructors.

Haskell resolves "which implementation for which type" through type classes, with the compiler automatically picking the right instance based on the type at the call site. ReScript has no type classes, no instance mechanism, and — unlike F#'s OO interfaces or Roc's structural where constraints — not even a well-established workaround; with only one type involved, as here, the ReScript side collapses to an ordinary, non-polymorphic function.

Where Haskell dispatches toDisplay automatically based on the argument's type, ReScript has no shared name to dispatch through at all — the idiomatic answer is simply two differently-named functions, intToDisplay and floatToDisplay, resolved the ordinary way by which name the caller writes. There is no attempt to fake type-directed dispatch; ReScript's culture, coming from the JS ecosystem, is comfortable with explicit, differently-named functions instead.

Haskell requires an explicit deriving (Eq) clause to opt a type into structural equality (mechanically, an automatically generated type class instance) — with no deriving clause, == would not even compile. ReScript needs no opt-in step at all: structural equality via == works on any variant or record out of the box, with no deriving-equivalent keyword to remember, because there is no type-class machinery underneath it to opt into in the first place.

Haskell's div is a named function for integer division that truncates toward negative infinity. ReScript reuses the ordinary / symbol for integer division (truncating toward zero, matching JavaScript's Math.trunc behavior rather than Haskell's floor behavior on negative operands) and requires the entirely separate /. operator for float division — mixing them up is a compile error, not a silent bug.

ReScript effectively ships two overlapping standard libraries: Belt (richer, more ergonomic, the modern recommendation for real projects) and Js (a thinner, more direct mapping onto JavaScript's own built-ins). Compiled Belt output includes require() calls assuming a Node or bundler environment, which fails when eval'd directly in a browser page with no module loader — exactly the execution model this site's live run buttons use, which is why every example on this page sticks to Js.*.