Haskell.CodeCompared.To/Scala

Haskell requires a named main :: IO () entry point that the runtime calls once. Every runnable Scala program needs a main method on an object — a similar requirement, but Scala's comes from the JVM's own entry-point convention rather than from any monadic structure. println needs no import, since it comes from the automatically-included Predef.

Haskell needs do-notation to sequence IO actions, since it desugars to chained monadic binds. Scala's main body is an ordinary imperative block — statements execute top to bottom because Scala is strict, with no monad required for plain sequencing.

Haskell's print uses the Show typeclass, deriving a textual representation for (almost) any value. Scala's println relies on every object's inherited toString, which case classes and standard collections already implement sensibly — the output shown, Some(List(1, 2, 3)), needs no extra formatting call, much like Haskell's derived Show.

Haskell's let ... in bindings and Scala's val both bind an immutable name once — val cannot be reassigned, matching Haskell's single-assignment discipline exactly, unlike Scala's separate var (next row).

Haskell reaches for IORef and threads it explicitly through IO with newIORef/modifyIORef/readIORef. Scala's var keyword offers a plain, in-place mutable local variable directly — no wrapper type, no monad required — though idiomatic Scala reaches for var far less often than idiomatic Java or C# would, preferring val almost everywhere.

Scala infers the type of local values the way Haskell does, so everyday code inside a method body reads almost as unannotated as Haskell. The difference surfaces at method boundaries: Scala parameter types and (with rare exceptions) return types are always explicit, the one place Haskell's inference goes further than Scala's.

Haskell's lowercase type variable a and Scala's bracketed [A] both introduce a generic type parameter, but Scala requires it to be written explicitly on the method — Haskell infers that firstOf is generic purely from never constraining a, where Scala requires the [A] annotation even though the body itself needs no further help.

Haskell's ++ is the general list-concatenation operator, since a String is really [Char]. Scala's + is a genuine JVM java.lang.String concatenation, since Scala strings are ordinary Java strings, not character lists.

Haskell has no native interpolation — the idiomatic route is Text.Printf with positional format specifiers. Scala's s"..." string interpolator embeds expressions directly with \${ }, closer to Python f-strings or Ruby's #{}, and needs no import.

Haskell's String is literally a type alias for [Char], so ordinary list functions like reverse apply directly. Scala's String is a genuine java.lang.String, but Scala's implicit conversions make it BEHAVE like a Seq[Char] for many operations (.reverse, .map, .filter all work directly on a String) — a middle ground between Haskell's literal list and a fully opaque string type.

Both languages model lists as singly-linked cons cells and use nearly identical syntax to destructure one: Haskell's (first:rest) versus Scala's first :: rest — the same :: cons operator Scala's List is built from, right down to the symbol.

Both languages call these operations map and filter. Scala calls them as methods on the collection (list.map(f)), where Haskell calls them as free functions taking the list last (map f list) — the same operation, opposite argument order convention.

Haskell's foldl and Scala's foldLeft take the same pieces — initial accumulator, then a combining function — but Scala calls it as a method with two parameter lists: list.foldLeft(initial)(function), splitting what Haskell passes as three ordinary arguments.

Both languages provide an immutable map as a first-class collection: Haskell's Data.Map (usually imported qualified) and Scala's built-in Map, needing no import at all. Map.lookup and Scala's .get both return an optional value rather than throwing on a missing key.

Haskell's Maybe a (Just x/Nothing) and Scala'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 idiomatic defaults in their respective languages.

This is one of the closest matches on the entire site: Scala's Either[String, Int] is spelled identically to Haskell's Either String Int, right down to reusing the names Left and Right for the same two cases with the same convention (Left for failure, Right for success).

Neither compiler lets you treat an Either as if it were the bare success value. Matching both branches — or explicitly calling a combinator that forces a decision about the failure case, like Scala's .getOrElse or Haskell's either function — is the only way out in either language.

Both define a named product type with labeled fields and dot-accessible members. Haskell generates a top-level accessor function per field (x :: Point -> Int); Scala's case class generates genuine object members plus free structural equality, a sensible toString, and pattern-matching support, all from one declaration.

Haskell's point { y = 99 } and Scala's point.copy(y = 99) both produce a new value with one field replaced and every other field copied automatically — Scala's .copy method is generated for free on every case class, playing exactly the role Haskell's built-in record-update braces do.

Haskell's algebraic data types declare every variant in one data statement; Scala expresses the same closed sum type as a sealed trait with case-class subtypes spread across (typically adjacent) declarations. sealed is the keyword doing the real work — it tells the compiler every subtype lives in this file, which is what lets a match be checked for exhaustiveness at all.

A payload-free Haskell constructor like North becomes a Scala case object — a singleton instance rather than a class, since there is only ever one North. This is more verbose than Haskell's single-line enumeration, one of the real costs of Scala expressing algebraic data types through its class hierarchy rather than a dedicated sum-type syntax.

Both compilers statically check whether a match covers every case, but Scala's exhaustiveness checking only fires reliably against a sealed hierarchy or similarly closed type — matching over a plain, unsealed Int like this one relies on Scala recognizing the guard pattern, which is less bulletproof than Haskell's check, which works uniformly across every data type.

Haskell's case ... of and Scala's match { } read as dialects of the same construct: patterns tried top to bottom, a guard attachable to a pattern (both reuse the word if/| respectively — Scala's if, Haskell's |), and a wildcard _ catch-all.

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 do-notation is syntactic sugar over the general Monad typeclass — it works identically for IO, Maybe, lists, and any other type with a Monad instance. Scala has no single IO monad baked into the language (though libraries like cats-effect provide one) — ordinary strict imperative code already sequences actions without needing any special notation, since there is no IO value to thread through pure code the way Haskell does.

This is the closest match to Haskell's do-notation of any language on the site: Scala's for { x <- ...; y <- ... } yield ... desugars to exactly the same flatMap/map chain Haskell's do-notation desugars to for Monad, and it short-circuits on the first None automatically, with the same <- arrow spelling Haskell uses.

Unlike F#'s separate, unrelated computation expressions or Roc's complete absence of a generalized abstraction, Scala's for-comprehension really does generalize the way Haskell's do-notation does: the exact same syntax that worked for Option in the previous row works unchanged for List, Either, or Future, because the Scala compiler desugars for into calls to whichever flatMap/map/withFilter methods the underlying type happens to define — structural, not typeclass-based, but genuinely uniform across types the way Haskell's Monad is.

Haskell spells a lambda \x -> ... (the backslash evoking the Greek letter lambda). Scala spells the same idea x => ..., and — when the parameter is used exactly once and its type is already known from context — can shorten it further to the placeholder syntax _ * _ seen in earlier rows.

This is a genuine difference. In Haskell, add 5 alone is already valid — every function is secretly a chain of one-argument functions. Scala supports currying natively via multiple parameter lists — def add(x: Int)(y: Int) — but it is opt-in: a normal def add(x: Int, y: Int) cannot be partially applied at all, and even with multiple parameter lists, add(5) _ (the trailing underscore) is required to explicitly request the remaining function as a value rather than a syntax error.

A base-case clause and a recursive clause, nearly a mechanical translation — the main syntactic difference is that Scala's single def uses an if/else where Haskell writes separate pattern-matched equations for the base case and the recursive case.

Haskell's [1..] is an ordinary list that only works because Haskell is lazy by default, generating each element on demand as take asks for it. Scala's default List is strict and would try to build the entire infinite list immediately (and hang forever); Scala's separate LazyList type is the one that plays Haskell's "infinite list" role, evaluating and caching elements only as they are demanded.

In Haskell, every binding is lazy unless forced otherwise — expensive is not actually computed until print demands it. Scala is strict by default, so achieving the same deferred, compute-once-and-cache behavior requires the explicit lazy keyword — laziness is opt-in machinery in Scala, not the ambient evaluation model, though lazy val does genuinely cache its result after the first access, matching Haskell's thunk-memoization behavior exactly once triggered.

Unlike F#'s interfaces, Roc's structural constraints, or ReScript's complete absence of ad-hoc polymorphism, Scala's implicit parameters give a genuinely working analogue to Haskell type classes: Describable[A] is the class, implicit val dogDescribable is the instance, and show's implicit ev: Describable[A] parameter is resolved automatically by the compiler searching for a matching implicit value — the same "the compiler picks the right implementation for the type at the call site" behavior Haskell's type classes provide, just spelled with an explicit parameter instead of Haskell's built-in dispatch syntax.

The same display call resolves to a different implicit instance depending on the argument's type — Int versus Double — exactly as Haskell's toDisplay resolves to a different type-class instance automatically. The caller never names which instance to use in either language; the compiler figures it out from the type.

Haskell requires an explicit deriving (Eq) clause to opt a type into structural equality — mechanically, an automatically generated type-class instance. A Scala case class gets structural equality, hashing, and a sensible toString automatically with no annotation at all, one case where Scala's default behavior is more convenient than Haskell's.

Both languages support exceptions (Haskell's Control.Exception, Scala's inherited JVM try/catch), but idiomatic code in both prefers modeling expected failure explicitly with Maybe/Either or Option/Either, reserving exceptions for genuinely unexpected, unrecoverable situations.

Scala's Try[A] (Success/Failure) is a standard-library type built exactly for this: wrap a computation that might throw, and get back a pattern-matchable value instead of an exception that must be caught. Haskell's Control.Exception.try plays the identical role, wrapping the risky action in an IO (Either SomeException a) — same idea, expressed through IO and Either rather than a dedicated Try type.

Haskell has no escape hatch into ordinary in-place mutation outside of explicit IORef/STRef/MVar machinery threaded through IO. Scala, being a hybrid OOP/FP language on the JVM, ships genuinely mutable collections (scala.collection.mutable.*) as first-class citizens right alongside the immutable ones — nothing in the language stops a Scala codebase from being written in an entirely imperative, Java-like style, a discipline Haskell enforces structurally that Scala only encourages by convention.

Haskell has no null concept at all — absence is always represented explicitly via Maybe. Scala, inheriting the JVM, still permits null for any reference type (though idiomatic Scala avoids it almost entirely in favor of Option), so a stray NullPointerException remains possible in a way it structurally cannot be in Haskell.