I have been working on my programming language Mux for a while now, and I have been really interested in the way that different programming languages handle type systems. Mux uses a strong and static type system, and I have been exploring the different ways that type systems can be designed and implemented, and just adding in different features.
\nWhile learning about this, the one type system that keeps coming up again and again is the Hindley-Milner type system.
\n\nOne of the most influential type systems in the history of programming languages is the Hindley-Milner type system, which has been used in languages like ML, Haskell, and OCaml. HM has also had large influence on languages like Rust, C#, and Swift, which have adopted some of its features and concepts. However, despite its widespread adoption and influence, it still has several limitations and shortcomings that have been identified over the years.
\nMux specifically does not use the strictest version of the Hindley-Milner type system, and instead uses some different approaches to type inference and type checking. In this article, I will discuss some of the limitations of the Hindley-Milner type system, and why I chose to use a different approach in Mux.
\nDue to the widespread usage of TypeScript as of late, I will be drawing similarities and differences between Mux and TS and their HM systems over the course of this article, but this applies to many PLs!
\nOne of the simplest examples of HM type inference is the identity function:
\nlet identity = fun x -> xThe compiler can infer that its type is:
\n'a -> 'aHere, 'a is a type variable. The identity function does not care what type it receives. Whatever type it receives, it returns that same type. This is called parametric polymorphism. The function can be used with an int, a string, or any other type without needing a separate implementation for each one. This smells a lot like generics!
And that is exactly how TypeScript expresses this:
\nfunction identity<T>(x: T): T {\n return x;\n}Mux makes a similar distinction to TypeScript:
\nfunc identity<T>(T x) returns T {\n return x\n}So in this case, Mux is very similar to HM. The difference is in how Mux handles type inference and genericity in other cases. There are other concepts that we will go over first, but this is a good introduction to the basic idea of HM. Maybe you can see where this is going...
\nFirst, I think there are a lot of things that HM does that is very useful and important.
\nHM's type inference is one of its biggest strengths. For example, instead of writing something to the effect of:
\nlet x: int = 42we can write:
\nlet x = 42and the compiler can determine that x has type int. TypeScript's is essentially the same:
\nlet x = 42;The compiler knows that x is a number without requiring an annotation. Mux also supports this kind of local inference:
\nauto x = 42The difference is in where Mux wants inference to happen.
\nMux is intentionally more explicit about the types that define an API, while allowing inference inside expressions and local variables. More on what can and can't be inferred to come shortly.
\nAnother important part of HM is unification. Suppose the compiler knows that some value has type 'a and later discovers that the value is being used as an int. The compiler can unify the two types, effectively determining that:
'a = intThis is what allows HM to infer surprisingly complicated types without requiring annotations everywhere. TypeScript has a similar concept when it infers generic type parameters:
\nfunction first<T>(items: T[]): T {\n return items[0];\n}\n\nconst x = first([1, 2, 3]);The compiler sees that the argument is a list of numbers, so it infers that T is a number and therefore x is a number. TypeScript can also do some more advanced inference (which i think is kinda cool btw). For example:
\nfunction echo<const T>(value: T): T {\n return value;\n}\n\nconst x = echo([1, 2, 3] as const);The type checker can infer that T is the tuple type:
\nreadonly [1, 2, 3]instead of number[]. This is a more advanced feature that is very cool, but Mux does not currently support it :(
Mux does this inference for generic calls as well:
\nfunc first<T>(list<T> items) returns T {\n return items[0]\n}\n\nauto x = first([1, 2, 3])\n\n/* we can also define x as:\n * list<int> x = first([1, 2, 3])\n *\n * but we don't need to in this case :)\n */The compiler can infer T is an int without requiring the explicit instantiation:
\nfirst([1, 2, 3])This is one of the places where Mux directly benefits from HM-style unification.
\nThe interesting part is not that HM can infer types. It is how much information we want the compiler to infer in Mux. For Mux, I decided that inference should remove boilerplate without removing useful information from the code. This has its tradeoffs, but I like it so...
\nConsider our identity function again. During type inference, the compiler can determine that its type is:
\n'a -> 'aBut it still needs to decide whether 'a should mean one specific type, or whether the function can actually be used polymorphically. HM generalizes the type variable, giving us:
forall 'a. 'a -> 'aThat means each use of identity can pick its own 'a:
identity 42\nidentity \"hello\"The first use can instantiate 'a as int, while the second can instantiate it as string. This is an important distinction. The compiler is not simply saying that identity has some unknown type. It has determined that identity is universally polymorphic over 'a. Inferring a type, then generalizing its free type variables, is a major part of what makes Hindley-Milner so powerful.
Mux takes a different approach. Rather than discovering that a function should be universally polymorphic and then generalizing its inferred type, Mux makes the generic parameter explicit in the declaration. Consider:
\nfunc identity<T>(T x) returns TThe <T> is there on purpose: the polymorphism is part of the function's declaration rather than something the compiler has to discover from the function body. This is one of the recurring design decisions in Mux: the compiler still performs type inference, but the programmer explicitly defines where polymorphism exists. Then at compilation time, Mux compiler will monomorphize the function. This is what Rust does, for example. So when we call identity with 42 and \"hello\" in Mux, we get something like this to use at runtime:
func identity$string(string x) returns string;\nfunc identity$int(int x) returns int;This bloats some of the code, but it is a way easier way to reason about, and debug a compiler. Plus, it is faster at runtime!
\nTypeScript is already on Mux's side here. Generic parameters are explicit in the declaration:
\nfunction map<T, U>(items: T[], f: (value: T) => U): U[] {\n return items.map(f);\n}The generic relationship is explicitly visible as T -> U. A reader can immediately see that map takes an array of T, applies a function from T to U, and produces an array of U. An HM language can instead be written without explicitly declaring those type parameters:
\nlet map = fun f xs ->\n ...The compiler can infer the equivalent polymorphic type. That is incredibly powerful, but I don't think it is the best tradeoff for Mux. Mux instead makes the public API explicit:
\nfunc map<T, U>(\n list<T> items,\n func(T) returns U f\n) returns list<U> {\n ...\n}The Mux version is more verbose, but in my opinion it is more readable and easier to reason about because the important type relationships are visible where the function is defined. And when calling it, the compiler still does the boring work:
\nauto strings = map(numbers, to_string)rather than requiring:
\nauto strings = map<int, string>(numbers, to_string)This gives Mux a useful separation:
\n\n\nThe programmer declares the API. The compiler determines the concrete types.
\n
The interesting thing about HM is that if the compiler doesn't know a type yet, it can introduce a type variable and keep going.
\nFor example, an empty list can conceptually have the type 'a list. There is nothing inherently wrong with that. The compiler knows it is a list, but it does not yet know what the elements are.
TypeScript has a similar situation:
\nconst empty = [];The compiler has very little information about what empty is supposed to contain.
\nMux intentionally does not allow this ambiguity. Code with this declaration:
\nauto empty = []will result in the following message:
\nerror: Cannot infer type for empty list literal\n--> test.mux:1:14\n |\n 1 | auto empty = []\n | ^\n |\n= help: Use an explicit type annotation, e.g. list<int> myVar = []This is a useful error because it tells the programmer exactly what information is missing and how to provide it. The other thing they can do is provide enough information for the compiler to infer it from the values in the list:
\nauto filled = [1, 2, 3]Here, the compiler can infer that filled is a list of ints. This raises a broader point. There is a difference between a type being representable by the type system and a type being useful to the programmer. HM is perfectly capable of representing 'a list. But an 'a list that no later use ever pins down is a type the compiler will eventually refuse anyway, at some random spot that has nothing to do with where the empty list was declared.
The Mux programmer can also write:
\nlist<int> empty = []Now there is no unresolved type variable. The programmer has explicitly provided the information the compiler was missing. This comes down to a subtle difference in philosophy.
\nHM asks:
\n\n\nCan this type remain polymorphic or unresolved?
\n
Mux asks:
\n\n\nDo we have enough information to determine this type here?
\n
If the answer is no, Mux asks the programmer for more information instead of carrying the unknown type forward. That is a deliberate tradeoff, not a technical limitation. And I think the resulting code is easier to reason about. When I see:
\nlist<int> empty = []I immediately know what the collection contains. I do not need to find another use of empty somewhere else in the program to figure out what type the compiler eventually inferred for it.
\nUsage of 'a tells us almost nothing about 'a.
That is exactly what we want for the identity function. It becomes less useful when writing functions that need to operate on the generic value. TypeScript solves this using constraints:
\nfunction stringify<T extends Printable>(value: T): string {\n return value.print();\n}Now T is still generic, but the compiler knows that T satisfies Printable. Mux has the same basic idea through generic bounds and interfaces, more similar to Rust and Go in this regard:
\nfunc stringify<T is Printable>(T value) returns string {\n return value.print()\n}This lets Mux express a distinction that plain HM polymorphism does not naturally express. The classic HM-era answer to this is type classes, like Haskell's, layered on top of the base system. Mux just uses a simpler spelling.
\nT means:
\n\nThis function is parameterized over some type T.
\n
While:
\nT is Printable means:
\n\nThis function is parameterized over some type T that is known to satisfy Printable.
\n
This is much more useful for a language with interfaces and generic programming. The compiler can still treat T as an unknown concrete type, while also knowing what operations are guaranteed to be available on it.
\nI think of Mux as borrowing one of HM's most useful pieces: unification-based type inference. Mux then builds a different type system around it:
\nThe philosophy is fairly simple:
\n\n\nThe programmer should describe the important type relationships. The compiler should fill in the boring parts.
\n
HM showed how far a compiler can go in inferring those relationships automatically.
\nMux is therefore not trying to replace HM's inference model so much as make a different set of tradeoffs about where that inference is allowed to operate.
\nWhat I learned from making Mux is that just because the compiler can infer something does not necessarily mean that it should.
", "url": "https://mux-lang.dev/blog/hindley-milner-type-system/", "title": "The MuxLang Type System: What Hindley-Milner Got Wrong", "summary": "I have been working on my programming language Mux for a while now, and I have been really interested in the way that different programming languages handle type systems. Mux uses a strong and static type system, and I have been exploring the different ways that type systems can be designed and implemented, and just adding in different features.", "date_modified": "2026-08-09T00:00:00.000Z", "author": { "name": "Derek Corniello", "url": "https://github.com/derekcorniello" }, "tags": [ "type-systems", "language-design", "hindley-milner" ] } ] }