Tag: Hindley-Milner

Choosing between Hindley-Milner (HM) and bidirectional typing is a foundational decision for anyone building a new programming language, extending a type checker, or designing a robust DSL for production use. The trade-offs run deeper than syntax or ergonomics—your decision will profoundly affect extensibility, error reporting, and future-proofing. This guide breaks down the technical mechanics, real-world consequences, and design philosophies behind each system, giving you actionable insights to steer your next type system project.

Key Takeaways:

• Hindley-Milner provides seamless type inference with minimal boilerplate but struggles with modern language features.
• Bidirectional typing splits type checking for better control, supporting advanced constructs and more helpful error diagnostics.
• Hybrid systems are now the norm, but choosing the right foundation remains crucial for language maintainability and extensibility.
• Your choice shapes everything from onboarding new developers to adding generics, subtyping, or type-directed code generation.

Hindley-Milner vs. Bidirectional Typing: What Are They?

Both Hindley-Milner (HM) type inference and bidirectional typing are frameworks for deducing types of expressions in statically typed languages, but their approaches, power, and extensibility diverge quickly as your language evolves.

Hindley-Milner (HM) Inference

• The classic inference engine behind ML, OCaml, Haskell (pre-GADTs), and Elm.
• Can infer types for almost every construct, requiring annotations only for recursive definitions or ambiguous polymorphism.
• Based on unification and generalization, producing principal types for expressions (Wikipedia).
• Excels in closed-world, functional languages with limited polymorphism or subtyping.

HM is lauded for its ability to make code concise and readable, removing the need for most type annotations and accelerating prototyping and education.

Bidirectional Typing

• Splits the process into type synthesis (“what is the type of this expression?”) and type checking (“does this expression match this type?”).
• Dominates in advanced languages—Scala, TypeScript, Rust, F*, and many dependently-typed systems.
• Lets you require annotations only where inference is ambiguous or advanced features are present (GADTs, existential types, type classes, etc.).
• Enables better error messages and supports extensibility without sacrificing type safety (Thunderseethe’s Devlog).

Bidirectional typing is designed for extensibility—letting you introduce new type features, improve diagnostics, and evolve syntax without breaking the core inference logic.

Practical Implications: When Each System Shines

Your choice of type system shapes not just syntax, but the entire developer experience, build performance, and your ability to support new patterns over time. Here’s how these paradigms play out as your language or DSL matures.

When to Use Hindley-Milner

• You want to maximize productivity for users who value terse, annotation-free code.
• Your domain is functional with minimal subtyping, existential types, or ad-hoc polymorphism.
• Teaching, academic, or prototyping environments where rapid iteration matters more than extensibility.
• Legacy codebases or platforms aiming for minimal migration friction.

Hindley-Milner’s global inference is unmatched for simple, compositional code. However, introducing new features (e.g., type classes, GADTs) often requires significant extensions or even a complete shift in the inference model.

When to Use Bidirectional Typing

• Your language roadmap includes advanced features—dependent types, GADTs, type-level programming, or subtyping.
• You need actionable, fine-grained error messages (e.g. for large enterprise codebases or onboarding new contributors).
• Annotations at library boundaries are tolerable or even desirable for documentation and discoverability.
• Your user base expects IDE integration, type-directed tooling, and scalable inference for large codebases.

Bidirectional typing is the backbone of extensible, modern languages. It enables soundness and clarity as your feature set grows, at the cost of more up-front annotation and slightly steeper learning curves.

Real-World Examples and Code Comparisons

How do these approaches work in practice? Let’s compare actual code and see where inference, annotations, and extensibility impact the developer’s workflow.

Example 1: Hindley-Milner (OCaml)

(* OCaml: HM infers the type of 'compose' with no annotation *)
let compose f g x = f (g x)
(* Compiler infers: val compose : ('b -> 'c) -> ('a -> 'b) -> 'a -> 'c *)

HM’s power: you write only logic, and the system determines principal types globally. This is ideal for mathematical or compositional code, such as parser combinators or AST traversals.

Example 2: Bidirectional Typing (Scala, TypeScript)

// Scala: Type parameter must be annotated for generics
def identity[A](x: A): A = x
// Without [A], Scala cannot infer the polymorphic type in all contexts

// TypeScript: Bidirectional typing, annotation required for function generics
function mapArray<T, U>(arr: T[], fn: (x: T) => U): U[] {
  return arr.map(fn);
}
// Without <T, U>, TypeScript cannot infer mapArray's full polymorphism

Bidirectional systems infer types locally where possible, but require explicitness at function boundaries or when expressing higher-order polymorphism. This enables richer type features, such as conditional types and mapped types in TypeScript.

Example 3: GADTs and Advanced Constructs (Rust, Scala 3)

// Rust: Requires explicit enum annotations for exhaustiveness
enum Expr {
    Num(i32),
    Add(Box<Expr>, Box<Expr>),
}

fn eval(e: &Expr) -> i32 {
    match e {
        Expr::Num(n) => *n,
        Expr::Add(lhs, rhs) => eval(lhs) + eval(rhs),
    }
}

// Scala 3: GADTs require explicit type parameters
sealed trait Expr[T]
case class Num(value: Int) extends Expr[Int]
case class Add(lhs: Expr[Int], rhs: Expr[Int]) extends Expr[Int]

// Type checker uses bidirectional rules to ensure type safety at construction and pattern matching

In both Rust and Scala 3, bidirectional typing allows the type system to support advanced constructs like GADTs, existential types, and exhaustiveness checking—features that would be intractable with pure HM.

Comparing Design Tradeoffs and Performance

Your type system’s foundation affects not only developer ergonomics, but also compiler complexity, incremental build performance, and ecosystem growth. Here’s a detailed comparison:

As you scale your language or DSL, the ability to adapt your type system to new patterns and user needs is critical. If your roadmap includes plugins, macros, or evolving generics, bidirectional typing is often the safer bet for long-term maintainability.

Hybrid Patterns in Modern Languages

Most successful statically-typed languages today blend Hindley-Milner and bidirectional typing. This hybrid approach lets you deliver the best of both worlds: high-productivity inference for most code, and explicit, extensible checks for advanced features.

• Haskell: Uses classic HM inference for simple terms, but switches to bidirectional (and sometimes even manual) typing for GADTs, type families, and type classes.
• TypeScript: Infers types for most expressions, but demands annotations for generics, conditional types, and some mapped types.
• Scala: Blends local inference with explicit type parameters and boundary checks, supporting both rapid prototyping and scalable, maintainable codebases.
• Rust: Leverages bidirectional typing for enums, traits, and pattern matching, while still allowing local inference for many expressions.

This trend mirrors the evolution of other systems—where initial simplicity gives way to hybrid, compositional architectures as complexity grows. For a parallel in platform strategy, see our post on diagram management and software lock-in risks.

Design Guidance for Hybrids

• Start with HM-style inference for core language constructs, minimizing friction for new users.
• Introduce bidirectional rules for advanced features, ensuring you can add GADTs, subtyping, or dependent types without rewriting the core checker.
• Document annotation requirements and error reporting strategies as part of your language’s public API—unclear boundaries are the leading cause of frustration for contributors and maintainers.

Common Pitfalls and Pro Tips

Implementation choices can backfire if you underestimate the complexity of new features or the annotation burden on users. Here’s what practitioners have learned:

Common Pitfalls

• Assuming global inference will scale: As soon as you add type classes, subtyping, or type-level functions, HM inference can become unpredictable or fail altogether.
• Annotation fatigue: Bidirectional typing can create “annotation hell” if you require explicit types everywhere—design your API to minimize repetitive annotations.
• Poor error messages: In both systems, unclear or non-local error messages quickly frustrate users and slow adoption. Invest in contextual diagnostics early.
• Ignoring migration and evolution: If you anticipate future features, architect your type checker for modularity and staged evolution.

Pro Tips for Language Designers

• Use Hindley-Milner for teaching, DSLs, or languages focused on rapid prototyping with stable features.
• Adopt bidirectional typing where extensibility, error reporting, and advanced type features are critical.
• Design your annotation syntax and error messages as “first-class citizens”—users will judge your language by these details.
• Study hybrid implementations for real-world patterns: Thunderseethe’s Devlog and Lobsters community analysis are excellent starting points.
• Talk to your users—annotation friction and cryptic errors are the top reasons developers abandon new languages or DSLs.

If you’re interested in how policy and platform choices affect developer experience and lock-in, explore our analysis of SaaS policy shifts and the downstream effects on engineering teams.

Conclusion & Next Steps

The Hindley-Milner versus bidirectional typing debate is less about right or wrong, and more about matching your type system to your language’s ambitions and your users’ expectations. If simplicity, minimal annotations, and a focus on functional programming are your goals, HM is a proven foundation. But if you expect your language to grow—adding generics, subtyping, or dependent types—bidirectional typing gives you the flexibility, extensibility, and diagnostic clarity needed for modern ecosystems.

Hybridize thoughtfully, and invest in clear annotation boundaries and actionable error messages from day one. For deeper dives into language architecture, long-term support, and portability, see our analysis of diagram longevity and platform evolution and how legacy support shapes future-proofing in IT strategy.

Ready to implement? Map your language’s feature roadmap, prototype both inference models, and test with real-world codebases early. The right type system will keep your language usable and maintainable for the long haul.