Haskell.CodeCompared.To/Roc

Haskell requires a named main :: IO () entry point that the runtime calls once. Roc's main! plays the same role, but the ! suffix marks it as effectful — Roc tracks purity in the type system rather than bundling every top-level action inside an implicit IO monad. main! must return a Try; Ok({}) signals success.

GHC compiles straight to a native binary that talks to the OS on its own. Roc instead compiles to a "platform-agnostic app" that cannot perform I/O by itself at all — a separate platform (often written in Rust or Zig) supplies every effect, including echo! here. This page runs on the vendored echo.wasm platform, which supports only echo!.

Haskell needs do-notation to sequence IO actions, since it desugars to chained monadic binds. Roc has no monad to desugar — an effectful block is just an ordinary sequence of statements executed top to bottom, closer to how a strict, imperative-flavored language would read.

Both languages default every binding to immutable, with no assignment operator for a plain name = value binding. Roc, like Haskell, requires a completely separate, visually distinct construct to opt into local mutation at all (next row).

Haskell reaches for IORef (or STRef/MVar) and threads it explicitly through IO with newIORef/modifyIORef/readIORef. Roc's var keyword (with the $-prefixed name it requires) offers a plain, local, in-place mutable variable directly — no wrapper type, no monad, and — because it cannot escape its own function — no risk of it leaking or racing the way a mutable reference might in a less disciplined language.

Haskell's Hindley-Milner-style inference makes explicit type signatures optional almost everywhere. Roc infers aggressively too, but idiomatic Roc code still writes a top-level type annotation above nearly every function — a style convention rather than a requirement, closer to how many Haskell codebases also always annotate top-level bindings even though the compiler could infer them.

Haskell's numeric literals are polymorphic over the Num typeclass, and converting between number types goes through fromIntegral/realToFrac. Roc has no such typeclass-driven polymorphism for numbers: I64 and F64 are concrete, unrelated types from the start, and crossing between them always needs an explicit conversion method like .to_f64().

Haskell's ++ is the general list-concatenation operator, since String is really [Char] under the hood. Roc has a real, distinct Str type (not a list of characters), and the current pinned build has no + or ++ for strings at all — concatenation goes through the Str.concat function, callable in method style as "Hello, ".concat("World!") too.

Haskell has no native interpolation — the idiomatic route is Text.Printf with positional format specifiers. Roc has true interpolated strings with \${ } placeholders, closer to Python f-strings — but note that, unlike Python or JavaScript, Roc will not implicitly stringify a non-Str value: age must be explicitly converted with .to_str() first, or the program fails to compile.

Haskell's String is literally a type alias for [Char], so ordinary list functions like length apply directly and count Unicode codepoints. Roc's Str is an opaque, UTF-8-guaranteed type with no list-of-characters escape hatch — this pinned build has no generic .len() for it either, only the explicit .count_utf8_bytes(), a reminder that Roc strings are measured in bytes, not characters.

The literal syntax is nearly identical. Under the hood the two representations differ completely: a Haskell list is a lazy, singly-linked chain of cons cells, while Roc's List is contiguous in memory (like a vector), despite the functional-language name. Str.inspect plays the role of Haskell's derived Show instance for quick debugging output.

Both languages call the map operation map. Haskell's filter becomes Roc's keep_if (with siblings drop_if and count_if) — a naming choice Roc made deliberately for clarity over the more common "filter" term used almost everywhere else, including Haskell.

Haskell's foldl and Roc's .fold take the same pieces in the same order — initial accumulator, then a two-argument function. Roc also ships fold_rev (Haskell's foldr), fold_with_index, and an early-exit fold_until that returns Break(value) to stop partway through.

Haskell's mapM_ runs an effectful action over each element purely for its side effects, discarding the results. The Roc langref specifies a native for word in words { } loop, but the pinned nightly build this page runs on rejects it (the iterator protocol is still being wired up) — so the working form today is .for_each!(...), whose ! suffix marks that its closure performs effects, mirroring mapM_'s intent almost exactly.

A Haskell record needs an explicit data declaration naming its type and fields before it can be used anywhere. Roc records are structural: { x: 1.5, y: 2.5 } simply exists at the point of use, no declaration required, and any two records sharing the same field names and types are considered the same type.

The idea is identical in both — produce a new record with one field replaced and every other field copied — but the syntax position of the "spread" flips: Haskell's defaults { retries = 5 } names the source record first, Roc's { ..defaults, retries: 5 } spreads it first inside the braces.

Both languages destructure a tuple with the same parenthesized, comma-separated pattern. One Roc quirk with no Haskell parallel: a Roc tuple must have at least two elements — there is no such thing as a Roc one-tuple, whereas Haskell has no tuples at all below pairs either, making this a non-issue in practice for both.

A nominal tag union (declared with :=) is Roc's closest match to a Haskell algebraic data type: named, closed, and exhaustively matched, with payload-carrying variants destructured the same way. Construction is qualified as Shape.Circle(2.0), where Haskell just writes the bare constructor Circle 2.0.

This is the feature with no Haskell equivalent whatsoever: structural tags spring into existence at the point of use, with no data declaration anywhere. The if gives period the inferred type [Morning, Afternoon] on the spot, and the match is still checked for exhaustiveness — Haskell-level safety with none of the upfront ceremony.

Roc's .. inside a tag-union type annotation marks it open: describe accepts Go, Stop, or genuinely any other tag at all, so long as there is a wildcard case to catch it. Haskell has no equivalent — every data declaration is a fixed, closed set of constructors, and widening it always means editing the original declaration.

Haskell's case ... of and Roc's match { } read as close dialects of the same construct: patterns tried top to bottom, a guard attached to a pattern (Haskell reuses |, Roc uses if), and a wildcard _ catch-all.

Both compilers statically verify a pattern match covers every case, but they enforce it differently: GHC emits a configurable warning (elevated to an error only under stricter flags), while Roc treats a non-exhaustive match as an unconditional compile error — no flag required, no way to ship the gap.

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.

Haskell's Either String Int renames directly to Roc's Try(I64, Str) — Left/Right become Err/Ok (note the argument order also flips: Roc puts the success type first). But Roc has no built-in Maybe at all — where Haskell would reach for Maybe Int to mean "no error info, just absence," idiomatic Roc either uses Try anyway or an ad-hoc structural tag union like [Found(Int), Missing].

Neither compiler lets you treat a fallible value as if it were the bare success value. Matching both branches — or explicitly calling a combinator that forces a decision about the error case, like Roc's ?? default operator or Haskell's either function — is the only way out in either language.

Haskell's do-notation over Maybe short-circuits on the first Nothing via the generic Monad typeclass, with no visible branching. Roc has no generalized monadic bind, but it does have ? — borrowed directly from Rust, not from Haskell — which unwraps an Ok or early-returns the surrounding function's Err/failure case, reaching the same practical effect through a completely different mechanism.

Haskell's fromMaybe defaultValue maybeValue and Roc's value ?? defaultValue do the same job — use the value if present, fall back otherwise — but Roc expresses it as an infix operator rather than a named function, reading closer to null-coalescing operators in JavaScript or C#.

This is a genuine capability gap in Roc's favor of clarity over cleverness. In Haskell, add 5 alone is already valid — every function is secretly a chain of one-argument functions. Roc functions take a fixed argument list (|x, y| ..., comma-separated, much closer to most mainstream languages), so getting a partial application means writing the wrapping function by hand, exactly as Erlang or C would require.

Haskell spells a lambda \x -> ... (the backslash evoking the Greek letter lambda). Roc spells the same idea |x| ..., pipe-delimited parameters with no arrow at all before the body — the same syntax Roc uses for every named function too, since add = |x, y| x + y is just a lambda bound to a name.

Haskell's . composes functions directly as values, right-to-left. Roc has no composition operator in this build at all (and, per the language churn warning, the |> pipe operator that once approximated left-to-right chaining has since been removed) — composing two functions means writing an ordinary wrapping function that calls one inside the other, spelling out the order explicitly rather than gluing function values together.

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. Roc additionally requires braces around each branch's body, where Haskell needs none.

This is a genuine, notable surprise for a Haskeller: Roc — a language that is pure by default, immutable by default, and effect-tracked in its types — still has real, honest while loops with break/continue. Mutation through var is local to the enclosing function and cannot leak or race, so the language designers were comfortable allowing it, unlike Haskell, which has no loop construct whatsoever and relies on recursion for every repeated computation.

Even with real loops available, recursion is still ordinary and idiomatic in Roc — the base-case-then-recursive-case shape translates directly from Haskell, just with an if/else standing in for Haskell's separate pattern-matched function clauses.

Haskell's [1..] is an ordinary list that only works because Haskell is lazy, generating each element on demand as take asks for it. Roc is strict, like nearly every other language on this site, and its List is a genuinely eager, fully-realized value — there is no way to construct an infinite one at all, so a bounded literal is simply how Roc 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. Roc has no thunks at all: expensive is computed the moment its binding line runs, exactly once, in program order — a much easier execution model to predict, at the cost of Haskell's free memoization-via-laziness trick.

Haskell computes a top-level pure binding lazily, the first time something actually demands its value, at runtime. Roc evaluates every top-level value at compile time — purity guarantees this is always safe — so a top-level definition that would crash (say, an overflow) becomes a compile error rather than something discovered only when the program runs.

Both languages make effectfulness visible in the type, but the mechanism differs. Haskell wraps the return type in IO, letting any function that "contains" IO stay a normal-looking function whose effectfulness only shows up in its result type. Roc instead marks the function ITSELF: a ! suffix on the name and a => arrow in the signature, and — unlike Haskell — a pure function can never even call an effectful one without adopting the ! itself.

This is the sharpest conceptual gap between the two languages. Haskell's Monad typeclass is a single abstraction: any type implementing >>= gets do-notation, uniformly, whether it is IO, Maybe, a list, or a hand-rolled parser. Roc has no typeclasses and no equivalent generalized abstraction — ? works specifically for Try, effectful ! functions are sequenced by ordinary statement order, and there is no way to write one block of syntax that works across all three the way Haskell's do does.

Haskell's error/undefined and Roc's crash serve the same purpose: an unrecoverable abort for a state the program considers impossible, as opposed to an expected failure that should be represented as a value (Either/Try). This row is display-only because the WASM host powering this page halts its own instance on a crash, rather than producing inspectable output.

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 — genuine, nominal, type-directed dispatch. Roc has no type classes and no instance mechanism whatsoever; here, with only one type involved, the Roc side collapses to an ordinary function with no dispatch machinery at all.

Roc's where [a.to_str : a -> Str] constrains a generic type parameter structurally — "any type that happens to have a matching to_str method" — closer to duck typing or a structural interface than Haskell's nominal type classes, where a type must explicitly opt in via a declared instance. In Roc there is no such opt-in step: if the method exists with the right shape, the constraint is satisfied, with no instance declaration linking the two together anywhere.

Haskell requires an explicit deriving (Show) clause to opt a type into human-readable printing (mechanically, an automatically generated type class instance). Roc needs no such opt-in at all: Str.inspect works structurally on any value whatsoever, with no derivation step and no way to forget it — a case where Roc's lack of type classes actually removes a small piece of Haskell ceremony rather than adding any.

Haskell's numeric default is Integer, so an unannotated whole-number computation prints without a decimal point. Roc's numeric default, absent any type annotation, is Dec (a fixed-point decimal type designed to avoid float rounding surprises) — so the exact same-looking expression prints "3.0" in Roc. Annotate with : I64 or suffix a literal (42.I64) whenever the printed form matters.

In Haskell, True/False are unambiguously values of the built-in Bool type — there is nothing else they could be. In Roc, a bare True/False is first read as an ordinary structural tag (indistinguishable from writing Foo), and only unifies with the real Bool type once something forces it to, such as an explicit : Bool annotation or being passed where a Bool is required — skip the annotation and operators like !/.not() may fail to type-check.

Haskell's !! operator indexes a list but crashes with an uncatchable runtime error on an out-of-bounds index — a genuine safety gap. Roc's .get(i) returns a Try, forcing the out-of-bounds case to be handled explicitly, which is the safer of the two designs — but note that the more familiar numbers[1] subscript syntax parses without error in this pinned nightly yet fails to type-check into anything usable, a trap for anyone reaching for it out of habit.

Haskell's base library and its common ecosystem packages have been stable for a very long time. Roc is pre-1.0 and this page pins a specific nightly compiler, so familiar-sounding operations are sometimes missing or renamed: there is no Str.replace yet, string length is count_utf8_bytes(), the |> pipe operator was removed in favor of plain method chains, and triple-quoted multiline strings are not implemented. Expect this table to shrink as Roc approaches its first stable release.