Haskell.CodeCompared.To/Kotlin

Haskell requires a named main :: IO () entry point that the runtime calls once. Kotlin also needs a top-level fun main(), but requires no surrounding class or object at all — a bare top-level function is sufficient, closer to a scripting language than Java's mandatory class.

Haskell needs do-notation to sequence IO actions, since it desugars to chained monadic binds. Kotlin is strict, so statements inside main simply execute one after another in the order written — no monad or block syntax required for plain sequencing.

Haskell's print uses the Show typeclass, deriving a textual representation for (almost) any value automatically. Kotlin's println relies on every object's inherited toString, which standard collections already implement sensibly — no extra formatting call needed, much like Haskell's derived Show.

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

Haskell reaches for IORef and threads it explicitly through IO with newIORef/modifyIORef/readIORef. Kotlin's var keyword offers a plain, in-place mutable local variable directly — no wrapper type, no monad required — and idiomatic Kotlin style, inherited from Java's imperative habits, reaches for var considerably more often than idiomatic Haskell reaches for IORef.

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

Haskell's lowercase type variable a and Kotlin's angle-bracketed <T> both introduce a generic type parameter, but Kotlin requires it to be written explicitly on the function — Haskell infers that firstOf is generic purely from never constraining a, where Kotlin requires the <T> annotation even though the body needs no further help.

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

Haskell has no native interpolation — the idiomatic route is Text.Printf with positional format specifiers. Kotlin has true string templates built into the language with \${ } placeholders (or bare \$name for a single identifier), 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. Kotlin's String is a genuine java.lang.String, but Kotlin adds extension functions like .reversed(), .map, .filter that make it behave much like a CharSequence collection for many operations — a middle ground between Haskell's literal list and a fully opaque string type.

Haskell's bracket literal [1, 2, 3] becomes Kotlin's listOf(1, 2, 3) function call — Kotlin has no dedicated list-literal syntax. Under the hood the representations differ completely: a Haskell list is a lazy, singly-linked chain of cons cells, while Kotlin's List is backed by a JVM array-based structure, matching most mainstream languages rather than the functional-language linked-list convention.

Both languages call these operations map and filter. Kotlin calls them as methods on the collection using trailing-lambda syntax with the implicit parameter name it, 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 Kotlin's fold take the same pieces — initial accumulator, then a combining function — with the same argument order (accumulator first), and even reuse the same name, one of the closer standard-library vocabulary matches on the site.

Both languages provide an immutable map as a first-class collection: Haskell's Data.Map (usually imported qualified) and Kotlin's mapOf, built from to-infix key-value pairs, needing no import at all. Both a missing-key Map.lookup and a missing-key Kotlin subscript return null/Nothing rather than throwing.

Haskell's Maybe a is a genuine wrapper type — a Just x is a different value from a bare x, and unwrapping is mandatory. Kotlin bakes nullability directly into the type system instead: String? is a type-level annotation on an ordinary String, with no wrapper allocated at all — a String or a nullable String occupy the same runtime representation, just with different compile-time guarantees, closer to Swift's Optional than to Haskell's explicit Maybe.

Haskell's fmap applies a function inside a Maybe without unwrapping it — the Functor typeclass's core operation. Kotlin's ?. safe-call operator does the equivalent job syntactically: user["name"]?.length evaluates to null immediately if the lookup itself was null, otherwise calls .length on the unwrapped value — the same short-circuiting behavior, expressed as an operator rather than a typeclass method.

Haskell's fromMaybe defaultValue maybeValue and Kotlin's maybeValue ?: defaultValue (the "Elvis operator," so named because ?: resembles a sideways emoticon) do the same job — use the value if present, fall back otherwise — but Kotlin expresses it as an infix operator rather than a named function.

This is a real gap unique to Kotlin's JVM interop story, with no Haskell parallel at all: values returned from Java code have an unchecked "platform type," and Kotlin's null-safety guarantees silently do not apply until that value is given an explicit Kotlin type annotation, at which point Kotlin trusts the annotation rather than actually verifying it. A NullPointerException from a mismatched platform type is exactly the class of bug Kotlin's ? system exists to prevent — except at the Java boundary, where it structurally cannot. The Kotlin side is display-only: it deliberately crashes to demonstrate the gap, so it is not run automatically.

Haskell's algebraic data types declare every variant in one data statement; Kotlin expresses the same closed sum type as a sealed class with nested data class subtypes. sealed is the keyword doing the real work — it tells the compiler every subtype is declared in the same file (or module), which is what lets a when be checked for exhaustiveness at all, and is Shape.Circle smart-casts shape to expose .radius with no manual cast needed.

For payload-free variants, idiomatic Kotlin reaches for the simpler, dedicated enum class rather than a sealed class with empty object subtypes — a genuine two-tier system: enum class for a closed set of plain constants, sealed class for a closed set of variants that need to carry different data. Haskell has one uniform data declaration that handles both cases identically.

Both compilers statically check whether a match covers every case, but the guarantee is stronger in Haskell: GHC's check applies uniformly to any data type. Kotlin's when-as-expression exhaustiveness check only proves genuine completeness for sealed class hierarchies and enum class types — over a plain Int like this one, an else branch is always required, since Kotlin cannot enumerate every possible Int the way it can enumerate every subtype of a sealed class.

Haskell's case ... of and Kotlin's when { } read as dialects of the same construct: conditions tried top to bottom with a catch-all at the end. Kotlin's no-argument when form used here evaluates each branch's condition as an independent boolean expression, closer to a chained if/else if than to Haskell's value-matching case — Kotlin's when (n) { 0 -> ...; else -> ... } subject form is the closer direct analogue for matching against a specific value.

Haskell's built-in tuple syntax (3, 4) and Kotlin's Pair(3, 4) class both support the same destructuring pattern, (x, y) = ..., on the left of a binding — Kotlin has no native tuple syntax beyond Pair/Triple, capping out at two and three elements respectively, where Haskell tuples support any arity.

Both define a named product type with labeled fields, accessed with dot syntax. Haskell needs an explicit deriving (Show, Eq) clause to get printable, comparable records; Kotlin's data class generates toString, equals, hashCode, and a copy method automatically, with no opt-in clause required at all.

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

Haskell spells a lambda \x -> ... (the backslash evoking the Greek letter lambda). Kotlin spells the same idea { x -> ... }, and — when the parameter's name is not worth naming — can shorten it further to the implicit-parameter shorthand { it * it } seen in earlier rows.

In Haskell, add 5 alone is already valid — every function is secretly a chain of one-argument functions. Kotlin functions take a fixed argument list with no automatic partial application at all; getting the same behavior means writing the currying out explicitly, a function that returns a lambda, exactly as shown — the result behaves identically to Haskell's automatic currying, but the intent must be spelled out by hand.

Kotlin functions may declare a default value for any parameter, letting callers omit it entirely — a genuine convenience with no Haskell equivalent at all, since Haskell function calls always supply every argument positionally. The closest Haskell workaround is a record-of-options argument with sensible field values, considerably more ceremony than Kotlin's inline default.

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. Kotlin has no type classes and no equivalent mechanism at all: an extension function like Dog.describe() only adds a method to one specific, named type — there is no way to write one polymorphic describe that dispatches differently per type the way Haskell's does, short of falling back to an ordinary interface (weaker than Swift's protocol extensions, since Kotlin extension functions cannot be added to an interface's implementors retroactively the way a protocol conformance can).

Kotlin interfaces, unlike Java's original interfaces, may supply a default method body directly — the closest Kotlin gets to Haskell's type-class default methods. The real difference from Haskell type classes remains: a type must explicitly declare : Greetable at its own definition site (nominal, like Java/Swift), where a Haskell type may gain a brand-new instance of an existing class anywhere in the program, including for types the class author never anticipated.

Both languages let you add new behavior to a type you do not own (here, the built-in Int). Haskell needs nothing special — an ordinary top-level function is already "extending" Int in every practical sense. Kotlin's extension-function syntax additionally lets the new function be called with dot-method syntax at the call site (7.isPrime() instead of isPrime(7)) — a genuine ergonomic win Haskell has no equivalent for, since Haskell has no method-call syntax at all.

Unlike Scala's Either (an almost exact naming match for Haskell's) or Swift's Result, Kotlin's standard library ships no general-purpose "value or typed error" type at all — the idiomatic move is to declare your own sealed class, as shown here, or reach for Kotlin's narrower built-in kotlin.Result<T> (next row), which fixes the error type to Throwable rather than letting you choose it freely the way Haskell's Either does.

Kotlin's built-in Result<T> plus runCatching wraps a risky computation as a value, similar in spirit to Haskell's Control.Exception.try wrapping a risky IO action as an Either SomeException a. The key difference: Kotlin's Result's failure case is always a Throwable — you cannot choose your own error type the way Haskell's Either lets you choose String, a custom error enum, or anything else.

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. Kotlin's default List is strict and would try to build the entire infinite list immediately (and hang forever); Kotlin's separate Sequence type (created here with generateSequence) is the one that plays Haskell's "infinite list" role, evaluating elements lazily, on demand.

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

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

Kotlin's type system is meant to eliminate unchecked null access, but the !! not-null assertion operator is a deliberate, always-available escape hatch that throws immediately if the value is actually null — functionally identical to Haskell's fromJust, which is exactly as unsafe and exactly as tempting to reach for. Idiomatic style in both languages treats this operator/function as a last resort, not a first instinct, and linters in both ecosystems commonly flag its use.