Parametric Subtyping for Structural Parametric Polymorphism

We study the interaction of structural subtyping with parametric polymorphism and recursively defined type constructors. Although structural subtyping is undecidable in this setting, we describe a notion of parametricity for type constructors and then exploit it to define parametric subtyping, a conceptually simple, decidable, and expressive fragment of structural subtyping that strictly generalizes rigid subtyping. We present and prove correct an effective saturation-based decision procedure for parametric subtyping, demonstrating its applicability using a variety of examples. We also provide an implementation of this decision procedure online.


INTRODUCTION
Recursive types, parametric polymorphism (also called generics), and subtyping are all essential features for modern programming languages across numerous paradigms.Recursive types describe unbounded data structures; parametric polymorphism provides type-level modularity by allowing programmers to use instantiations of list[] rather than separate monomorphic types for integer and boolean lists, for example; and subtyping provides flexibility in the ways that objects and terms can be used, enabling code reuse.Structural subtyping, in particular, is especially flexible and expressive and, in principle, relatively lightweight for programmers to incorporate.
This combination of features is present to varying degrees in many of today's widely used languages, such as Go, Rust, TypeScript and Java, but the combination is difficult to manage.For example, subtyping for generics in Java is known to be undecidable [Grigore 2017], so various restrictions on types' structure have been proposed, such as material-shape separation [Greenman et al. 2014;Mackay et al. 2020], and the prohibition of contravariance, unbounded expansion of types, or multiple instantiation inheritance [Kennedy and Pierce 2007], to name a few.
We contend that these restrictions are often either too limiting or too unintuitive for programmers to readily reason about.A reconstruction of the interaction between recursive types, parametric polymorphism, and structural subtyping from first principles is needed, accompanied by a clear, relatively simple declarative characterization of subtyping.However, to the best of our knowledge, no such work has been undertaken thus far.This paper fills that gap.
As a first step, we prove that structural subtyping is undecidable in the presence of recursive types and parametric polymorphism. 1Given this undecidability, our goal is to identify an expressive, practical fragment of structural subtyping that has three properties: (1) The fragment should have a relatively simple declarative characterization, so that the valid subtypings are readily predictable by the programmer.(2) The fragment should be decidable, with an effective algorithm that performs well on the kinds of subtyping problems that arise in practice.(3) The fragment should strictly generalize "rigid subtyping", a form of subtyping in which subtypings exist only between types with the same outermost type constructor, such as It is not immediately clear that such a fragment of structural subtyping should even exist, as seemingly innocent variations of the problem are already undecidable or impractical.Solomon [1978] showed that structural equality for parametric polymorphism can be reduced to equivalence of deterministic pushdown automata, but it took more than 20 additional years to establish decidability [Stirling 2001a,b;Sénizergues 2001], albeit by an intractable algorithm.As another example, even without recursive types, subtyping for implicit, Curry-style polymorphism [Tiuryn and Urzyczyn 2002;Wells 1995] and bounded quantification [Pierce 1994] are both undecidable.
Nevertheless, in this paper, we are able to achieve our goal: we propose a notion of parametricity for type constructors that forms the basis of a suitable fragment of structural subtyping, a fragment that we call parametric subtyping.Parametric constructors will map subtyping-related arguments to subtyping-related results, echoing Reynolds's [1983] characterization of parametric functions as those that map related arguments to related results. 2 Moreover, by exploiting parametricity, we avoid unintuitive restrictions on types' structure and can support even non-regular types [Bird and Meertens 1998;Mycroft 1984].
Because of its fundamental nature, our notion of parametric subtyping and associated decision procedure could be applied to a wide variety of languages: object-oriented languages; lazy and eager functional languages; imperative languages; mixed inductive/coinductive languages, such as call-by-push-value [Levy 2001]; session-typed languages [Caires and Pfenning 2010;Gay and Hole 2005;Honda et al. 1998;Silva et al. 2023]; and so on. 3 We want to emphasize this broad applicability by keeping this paper's technical framework as general as possible.This leads us to make several concrete choices in this paper's presentation.
• We do not consider subtypings such as 0 ⩽ 1 and 1 ⩽ 0 → 1 that arise when some types are uninhabited [Ligatti et al. 2017].This is because we choose to interpret all types coinductively, making them all inhabited, even 0. Nevertheless, the parametric subtyping rules in this paper are sound in languages where some types are interpreted inductively.Had we instead insisted on an inductive treatment of some types, parametric subtypings such as the above would be unsound for lazy functional and session-typed languages, undercutting broader applicability.• Neither do we consider subtypings that rely on implicit, Curry-style polymorphism, such as (∀ .list[]) ⩽ list [int], or bounded quantification, such as ∀( ⩽ {x : real}). × real → , because subtyping is already undecidable in those settings, even without recursive types [Pierce 1994;Tiuryn and Urzyczyn 2002;Wells 1995].In summary, our primary aim is to examine the interaction of explicit, Church-style polymorphism, recursive type constructors, and the fundamental core of structural subtyping.

Overview of parametric subtyping
To provide the reader with some intuition for our notion of parametric subtyping, we will now sketch, at a high level, how parametric subtyping satisfies the three desired properties.
(1) Relatively simple declarative characterization.A pair of type constructors,  [ ì ] and  [ ì ], will be considered parametric if the subtyping problem  [ ì ] ⩽  [ ì ] can be reduced to (finitely many) subtyping problems among the arguments ì  and ì  alone.As an example, consider an interface for stack objects (or, from a functional perspective, a record type for stacks), parameterized by a type  of stack elements: where option[] ≜ +{none : 1, some : }.Programmers sometimes want to ensure that a stack be used according to a particular protocol.For example, when implementing a queue using a pair of stacks (as sometimes done in functional languages), the protocol in which all pushes must occur before any pops can be expressed by the types These rules are admissible in the sense that there exist corresponding infinite derivations that use only the standard structural subtyping rules.More importantly, these are valid parametric subtyping rules because the premises involve only arguments,  and .A rule such as "intlist ⩽ list [𝛽] if int ⩽ ", where intlist ≜ +{nil : 1, cons : int × intlist}, would not be parametric because its premise involves a type, int, that is not an argument.
Given such rules, parametric subtyping is then conceptually rather straightforward: A subtyping between types holds because it has a finite derivation from the admissible parametric subtyping rules.For example, stack[stack [int]] ⩽ qstack 2 [qstack 1 [int]] is a valid parametric subtyping because we can derive from the above admissible parametric subtyping rules.On the other hand, intlist ⩽ list [int] is not a valid parametric subtyping because there is no admissible parametric subtyping rule for intlist ⩽ list[]. 4n Section 3, we present an equivalent characterization of parametric subtyping that is more amenable to metatheoretic proofs.A series of examples in Section 7 demonstrates that the valid parametric subtypings are readily predictable by the programmer and expressive enough for many subtypings desired in practice.
(2) Decidable.In Section 5, we prove that parametric subtyping is decidable by giving a saturation algorithm that is sound and complete with respect to the declarative characterization of parametric subtyping (Theorems 5.2 and 5.4).The algorithm infers, for each pair of type constructors, the most general parametric subtyping rule, if one exists.Moreover, when no such parametric rule exists, the algorithm determines whether the cause is a fundamental violation of structural subtyping or merely a violation of parametricity.After inferring all such admissible rules, a given subtyping problem can be decided by backward proof construction of a finite derivation using the inferred rules.
We have implemented this decision procedure, and it is available online in a virtual machine image [DeYoung et al. 2023b]; the source files are also available in an online repository [DeYoung et al. 2023c].
(3) Generalizes rigid subtyping.Rigid subtyping is characterized by those parametric rules that relate identical type constructors, such as the above rule for stack[] ⩽ stack [𝛽].Our notion of parametric subtyping is indeed strictly more general than rigid subtyping, in that it also admits those parametric rules that relate distinct type constructors, such as the above rule for stack This is a simple but important property.If parametric subtyping somehow did not generalize rigid subtyping, that failure of type constructor "reflexivity" would make parametric subtyping very unintuitive and would likely be indicative of other serious problems.(Comparison to nominal subtyping [e.g., Kennedy and Pierce 2007] as common in object-oriented languages is left to future work.) The most closely related work is that on refinement types, specifically datasort refinements [Freeman and Pfenning 1991]; there are significant differences, however.First, whereas the refinement system refines a nominal type into a collection of structural sorts, we use a single-layer, fully structural system.Second, Davies [2005, Sec. 7.4] defines an algorithm for subsorting parameterized sort constructors that respects parametricity, but requires explicit declarations for the constructors' variance and handles only very limited cases of nested sorts.(On the other hand, he deals with general pattern matching, module boundaries, and intersections, which are beyond the scope of the present work.)Third, Skalka [1997] gives an algorithm to decide the emptiness of refinement types, but does not give a subtyping algorithm and handles only regular type constructors.Last, whereas the nominal core of refinement types means that a defined type cannot later be widened into a supertype, our fully structural system has the advantage of naturally permitting widening.
In summary, the contributions of this paper are: to identify several minimal fragments for which structural subtyping is undecidable (Section 2.3); to give a simple, declarative characterization of parametric subtyping, as a fragment of structural subtyping (Section 3); to present a saturation algorithm for deciding parametric subtyping for parametric polymorphism (Section 5), as well as proofs of its soundness and completeness with respect to the declarative characterization (Theorems 5.2 and 5.4); to implement this decision procedure (Section 6); and to give, as a special case of this decision procedure, a saturation-based decision procedure for structural subtyping of monomorphic types that has several advantages over existing algorithms (Section 4).Details of the proofs sketched here can be found in Appendix A.

STRUCTURAL SUBTYPING FOR PARAMETRIC POLYMORPHISM
In this section, we describe the syntax of types, present a declarative characterization of structural subtyping, and show that it is undecidable in the presence of recursively defined type constructors.

Syntax of types
Programmers write types in the form to which they are accustomed, such as in the type definition list[] ≜ +{nil : 1, cons :  ×list[]}.However, throughout this paper, it will often be convenient to work with types in a normal form that maintains a strict distinction and alternation between named types  and structural types .For this reason, the programmer-defined types will be normalized in a preliminary elaboration phase that inserts additional type constructors, in a manner reminiscent of the conversion of context-free grammars to Greibach normal form [1965] and the syntax Huet [1998] used in deciding extensional equality of total Böhm trees.Details of this elaboration are postponed to Section 6.
For types in normal form, the syntax is as follows.In addition to these syntactic categories, we use  for type constructor parameters and  for explicitly quantified type variables.Notice that definitions enforce the other part of the strict alternation between structural types and named types that is prescribed by this normal form: type constructors  [ ì ] are defined only in terms of structural types , not named types .Moreover, this ensures that all definitions are contractive [Gay and Hole 2005].
Given the shallow syntax of structural types, named types  must also include type parameters , so that the structural body of a definition  [ ì ] ≜  may indeed contain occurrences of parameters ì .Similarly, named types  also include type variables  bound by the ∀ and ∃ quantifiers.
2.1.3Type substitutions.In structural subtyping, definitions  [ ì ] ≜  will be interpreted transparently, with  [ ] and its unfolding,  (), being treated indistinguishably (aside from belonging to distinct syntactic categories).Because such type definitions are closed apart from their parameters ì , the domains of type substitutions  consist only of type parameters .Moreover, substitutions map these parameters to named types , not to structural types, so that the instantiation of a structural type,  (), is itself a well-formed structural type.

Examples.
Here we present two examples to which we will repeatedly return in this paper.
Even and odd natural numbers.As a simple example of a type, the programmer could write the following type definitions to describe a unary representation of natural numbers, as well as even and odd natural numbers.7 (We omit [] when a defined type takes no parameters.)odd ≜ +{s : even} nat ≜ +{z : 1, s : nat} even ≜ +{z : 1, s : odd} The elaboration phase would normalize these types by introducing an auxiliary type name one and revising the definitions of nat and even so that structural and named types alternate: odd ≜ +{s : even} one ≜ 1 nat ≜ +{z : one, s : nat} even ≜ +{z : one, s : odd} To avoid the bureaucracy of having to write types in normal form, future examples given in this paper presume that types will be normalized during elaboration.
The even and odd natural numbers are, of course, subsets of the natural numbers.So, taking a sets-of-values interpretation of subtyping, we ought to have even and odd as subtypes of nat, but we ought not to have nat as a subtype of even and odd.
Context-free languages.As a more complex example, we consider the type of words belonging to the context-free language {L  R  $ |  ≥ 0}.(The terminal symbol, $, is necessary to make the language prefix-free [Korenjak and Hopcroft 1966] and thereby represent the empty word in a typable way.)To aid intuition, we show both the context-free grammar (in Greibach normal form [1965]) for this language on the left and the corresponding, quite parallel, type definitions on the right. 8CFG in Greibach normal form Here, the type e 0 relies on the constructor e[], which describes the language {L  R +1  |  ≥ 0}; that is, the parameter  maintains a continuation to be used when the unmatched R is produced.
Because the type e 0 refers to e[−] only after producing an initial L, the words described by e 0 are indeed a string of Ls followed by the same number of Rs (followed by $).
represent the respective finite natural numbers together with the first limit ordinal,  = s s • • • .This subtlety is familiar from lazy functional languages such as Haskell. 8Once again, because all types are interpreted coinductively in this paper, the type e 0 would also be inhabited by the infinite unf-s  ⩽  var-s (no rules for  ⩽  and  ⩽  when  ≠ ) In a similar way the context-free grammar (again in Greibach normal form) and the type d 0 given below describe the ($-terminated) Dyck language of balanced delimiters, here L and R.

CFG in Greibach normal form
The type d 0 relies on the type constructor d[ ′ ], which describes the context-free language of "nearly balanced" delimiters, in which words of balanced delimiters are followed by one additional unmatched R; once again, the type parameter  maintains a continuation to be used when that unmatched R is produced.The type d 0 refers to d[−] only after producing an initial L, so the words described by d 0 are indeed balanced.
Because {L  R  $ |  ≥ 0} is a subset of the $-terminated Dyck language, we ought to have e 0 as a subtype of d 0 , but not d 0 as a subtype of e 0 .

Structural subtyping
Because our normalized types are separated into named types and structural types, structural subtyping will be given a declarative characterization in terms of derivations of two judgments:  ⩽  for named type  as a subtype of named type , and  ⩽  for structural type  as a subtype of structural type .Derivations of the  ⩽  and  ⩽  judgments will be defined coinductively.That is, these derivations may be infinitely deep (but will be finitely wide).Stated differently, subtyping's coinductive nature and underlying greatest fixed point mean that a subtyping relationship holds in the absence of a counterexample, and that absence is witnessed by a potentially infinite derivation. 9 Returning to the first of our running examples, for even to be a subtype of nat, we must be able to construct infinite derivations of even ⩽ nat.On the other hand, because nat ought not to be a subtype of even, there must not exist a derivation of nat ⩽ even.
The entire set of inference rules used to construct (potentially) infinite derivations of subtyping judgments can be found in Fig. 1.These rules are interpreted coinductively and are most clearly 9 For monomorphic subtyping, merely circular derivations [Brotherston and Simpson 2010], which are finite representations of regular infinite derivations, would suffice [Lakhani et al. 2022].read bottom-up, from conclusion to premises.We will now comment on a few of the rules.[𝜙] exactly when the same subtyping relationship holds for their unfoldings,  () and  (), respectively.This is expressed by the unf-s rule.Additionally, a type variable  is considered to be a subtype of only itself, as captured in the var-s rule.
2.2.2 Structural subtyping of structural types.Aside from the alternation of structural and named types, the rules for structural subtyping of structural types,  ⩽ , are standard [Pierce 2002].The rules decompose the structural types into their immediate subformulas and then require certain subtyping relationships on those subformulas.For example, the +s rule for variant record types is standard (see e.g.[Gay and Hole 2005;Pierce 2002]).For +{ℓ :  ℓ } ℓ ∈ to be a subtype of +{ :   }  ∈ , the condition  ⊆  demands that the latter type offer at least as many alternatives as, but possibly more than, the former type, thereby accounting for width subtyping of variant record types.Moreover, by requiring that  ℓ ⩽  ℓ holds for all alternatives ℓ shared by the two types, this rule also accounts for covariant depth subtyping of variant record types.
Subtyping for the polymorphic quantifiers ∀ .and ∃ . is also standard for explicit, Churchstyle polymorphism.We certainly could have unified the ∀s and ∃s rules into a single s rule, with a side condition that  ∈ {∀, ∃}.However, because ∀ .and ∃ .will type different terms, we prefer to maintain distinct subtyping rules for ∀ and ∃.Moreover, as previously mentioned in Section 1, we do not consider subtyping for implicit, Curry-style polymorphism, nor bounded quantification, in this paper, leaving these as future work.
As previously mentioned, we do not consider subtyping for implicit, Curry-style polymorphism [Odersky and Läufer 1996] or bounded quantification [Cardelli et al. 1994;Cardelli and Wegner 1985] in this paper.Because our interest is in the interaction of subtyping, Church-style polymorphism, and recursion, these are outside the scope of this paper and left as future work.

Examples. We now return to the running examples in the context of structural subtyping.
Even and odd natural numbers.For even and odd to be subtypes of nat, we must be able to construct derivations of even ⩽ nat and odd ⩽ nat.Because structural subtyping derivations are (potentially) infinite, they cannot be directly written down in their entirety.A finite, constructive proof of their existence instead suffices, and a useful proof technique here is coinduction.For example, for even ⩽ nat and odd ⩽ nat, mutual coinduction can be used: We use a dotted line to indicate the coinductive appeals to odd ⩽ nat and even ⩽ nat, which can also be thought of as admissible structural subtyping rules -admissible in the sense that they can always be unfolded to the corresponding infinite derivations, which involve only rules found in Fig. 1.Each of these appeals is guarded by the unf-s and +s rules.
Here, the full expressive power of infinite derivations is not needed.Because the types are monomorphic, circular derivations [Brotherston and Simpson 2010], which are finite representations of regular infinite derivations, would suffice [Lakhani et al. 2022]: For even ⩽ nat, the right-hand derivation segment could be inlined within the left-hand segment, with the inlined coinductive appeal to even ⩽ nat then circling back to even ⩽ nat at the "root".Then odd ⩽ nat is similar.
As a negative example, we cannot derive nat ⩽ odd because, after unfolding nat and odd with the unf-s rule, we would need to show that {z, s} ⊆ {s}, which is simply false.Similarly, we cannot derive nat ⩽ even because, after unfolding nat and even, we would need to derive nat ⩽ odd.
Context-free languages.Recall that {L  R  $ |  ≥ 0} is a subset of the Dyck language and that the type e 0 should accordingly be a subtype of d 0 ; there ought therefore to exist a derivation of e 0 ⩽ d 0 .However, direct application of coinduction is not enough to establish e In other words, the rules marked with dotted lines are admissible and can always be unfolded to the partial derivation on the right-hand side above.This example demonstrates why circular derivations do not suffice for subtyping of recursively defined type constructors that employ non-regular recursion: In the right-hand derivation, we cannot directly close a cycle from e The former is indeed an instance of the latter, but the subtyping depends on having  ⩽  ′ and so we are required to show the instance r[] ⩽ d[ ′ ]: we need the expressive power of non-regular infinite derivations.Given that {L  R  $ |  ≥ 0} and the Dyck language are context-free languages, perhaps it is not surprising that the regularity of circular derivations is insufficiently expressive to establish e 0 ⩽ d 0 .

Undecidability of structural subtyping
A priori, it seems possible that structural subtyping in the presence of recursively defined type constructors might be decidable.After all, structural equality for coinductively interpreted types is decidable [Das et al. 2022], although intractable, by reducing from trace equivalence for deterministic first-order grammars [Jančar 2021].
But as it turns out, structural subtyping is undecidable in the presence of recursively defined type constructors.As previously discussed in Sections 1 and 2, the types in this paper are interpreted coinductively.To prove undecidability, we therefore need a reduction from a correspondingly coinductive property.We choose to reduce from simulation of guarded Basic Process Algebra (BPA) processes [Bergstra and Klop 1984], a property which is itself undecidable [Groote and Hüttel 1994].
2.3.1 Background on basic process algebra.Guarded BPA processes are defined by a set of guarded equations.For our purposes, a general definition of guardedness is unimportant; what is important is that any set of guarded BPA equations can be put into the following Greibach normal form [Baeten et al. 1993]: , where  is nonempty and ,   |  •  .
As usual for process algebras, there is a labeled transition system to describe process behavior.When restricted to processes in Greibach normal form, the labeled transition system consists of a single rule: where The simulation (or "is-simulated-by") relation, ≲, for BPA processes is the largest relation such that whenever  ≲  and   −→  ′ hold, there exists a process  ′ for which  ′ ≲  ′ and   −→  ′ hold.In particular,  ≲  holds for all processes  because  cannot make any transitions.

Reduction of BPA simulation to structural subtyping. For each guarded BPA equation in
where  is nonempty, we define a corresponding type constructor   [] that encodes the behavior of process variable  , parametrically in a type  that describes the behavior to follow that of  : (  yields a type in normal form because  is finite and  is a named type.)The ideas behind this encoding are twofold.First, width subtyping of ensures that a process  •  can match any transition that  •  can take: width subtyping ensures that the type   [] offers at least those alternatives that the type   [] does.Second, depth subtyping for ensures that this simulation holds hereditarily for the processes to which  •  and  •  transition.We can prove the following.Theorem 2.1.Let  ≜ { }.Then  ≲  if and only if ( ) ⩽ ( ), for all processes  and .
Proof sketch.We prove each direction separately, by coinduction on the respective conclusion.□ The key properties of  necessary for the proof are: that ( ) ⩽ , for all processes ; and that  ⩽ ( ) implies  = , for all processes .Because simulation for BPA processes is undecidable [Groote and Hüttel 1994], we therefore have the following corollary.
Corollary 2.2.In the presence of record types with no alternatives and recursively defined type constructors, structural subtyping is undecidable.
Although they make for an arguably cleaner proof, record types with no alternatives are not at all essential.Even if all record types must have at least one alternative, structural subtyping is still undecidable.The encoding can be revised to include an endmarker, $, as an additional alternative for each   .Let  0 be any closed type, such as  0 ≜ {$ :  0 } or  0 ≜ 1 (among others), and define , where   is defined as above.With the revised encoding, we can prove the following theorem.Theorem 2.3.Let  ≜ {$ :  0 }.Then  ≲  if and only if ( ) ⩽ ( ), for all processes  and .
Corollary 2.4.In the presence of record types and recursively defined type constructors, structural subtyping is undecidable.
Furthermore, because we assign a coinductive interpretation to all types, virtually the same theorems hold for variant record types, with + substituted for in the definitions of   [] -only the subtyping direction changes to " ≲  if and only if ( ) ⩽ ( )."That is, structural subtyping remains undecidable in the presence of variant record types and recursively defined type constructors, even if there are no record types at all. 10

PARAMETRIC SUBTYPING FOR PARAMETRIC POLYMORPHISM
In this section, we identify a fragment of structural subtyping for parametric polymorphism that has a relatively simple declarative characterization.(Section 5 will show that this fragment is also decidable.)We call this fragment parametric subtyping, for its basis is a notion of parametricity.
Recall the context-free languages example from Section 2.2.3 in which we proved that the type e 0 , corresponding to {L  R  $ |  ≥ 0}, is a subtype of the Dyck language type d 0 .We could not use direct coinduction to prove the existence of a derivation of e 0 ⩽ d 0 because that led to an infinite stream of subgoals, e ]], . . ., none of which is an instance of any preceding one.We somehow need to quotient this space into finitely many subproblems, each of which is decidable.
The key insight behind this quotienting comes in revisiting the coinductive generalization that we used to prove e 0 ⩽ d 0 : in Section 2.2.3, we proved that  ⩽  ′ implies e[] ⩽ d[ ′ ] for all named types  and  ′ .This could also be viewed as proving that the following inference rule is admissible from the structural subtyping rules of Fig. 1.
This rule looks very much like the kind of rules around which rigid subtyping is based.However, there is a key difference: rigid subtyping requires such parametric rules to use the same type constructor on both sides of the conclusion.
Most importantly for our purposes, this admissible rule is parametric, in the sense that the type constructors e[−] and d[−] map related arguments,  ⩽  ′ , to related results, e[] ⩽ d[ ′ ].This echoes Reynolds's characterization of parametric functions as those that map related arguments to related results [1983, Sec. 3].Specifically, the right-hand side of his clause, The importance of parametricity in the coinductive generalization used in this example suggests that we ought to consider a notion of subtyping that uses parametric rules, i.e., rules of the form as a candidate for being a decidable fragment of structural subtyping with a relatively simple declarative characterization.

Declarative characterization of parametric subtyping
The requirement that the candidate fragment use only parametric rules could already serve as a relatively simple declarative characterization.However, to develop a decision procedure and prove its correctness, it is very useful to devise an equivalent declarative characterization that is more closely aligned with the presentation of structural subtyping.Before doing so, it is helpful to see why structural subtyping, as defined in Fig. 1, violates parametricity.Consider the type definition snat[] ≜ +{z : , s : snat[]}, which generalizes the type nat via the structural subtyping nat ⩽ snat [1].(The name snat, for "serialized nat", alludes to serialized data structures, as discussed in Section 7.3.)However, the admissible rule for nat and snat[] would be the non-parametric rule "nat ⩽ snat[] if 1 ⩽ ." The unf-s rule of structural subtyping 11 Moreover, the observation that parametric subtyping strictly generalizes rigid subtyping (which relates types only if they have the same outermost constructor) echoes Reynolds's Abstraction Theorem, which states that his relational semantics relates the same expression in different environments.cannot detect non-parametric judgments, such as 1 ⩽  here, because unfolding eagerly applies substitutions and free type parameters do not appear: by the time that structural subtyping reaches this non-parametric judgment, it will be 1 ⩽ [1/] = 1, with the non-parametricity no longer apparent in the judgment.Therefore, instead of eagerly applying substitutions when unfolding, we need to postpone the substitutions, applying them only after determining that they do not conceal any non-parametricity.The idea of postponing substitutions in this way is inspired by the Girard-Reynolds logical relation for parametricity [Girard 1972;Reynolds 1983].The judgments  ⩽  and  ⩽  are revised to postpone substitutions by pushing them onto stacks when unfolding type constructor instantiations.Substitution stacks are given by the grammar and we thus arrive at the judgments  ⟨Θ⟩ ⩽  ⟨Φ⟩ and ⟨Θ⟩ ⩽ ⟨Φ⟩ for parametric subtyping.
As with structural subtyping, a parametric subtyping judgment holds if there exists a (potentially infinite) derivation of that judgment using the rules found in Fig. 2.These declarative rules are again interpreted coinductively and are most clearly read bottom-up, from conclusion to premises.
To better understand these rules, it can be helpful to imagine constructing a (potentially infinite) derivation of  [ ] ⟨Θ⟩ ⩽  [𝜙]  The notion of parametric subtyping given in Fig. 2 is sound with respect to structural subtyping as defined in Fig. 1.The substitutions postponed in stacks Θ and Φ can instead be composed and applied eagerly, transforming instances of the inst-p rule into instances of the unf-s rule and eliminating occurrences of the param-p rule.Proof sketch.Using the mixed induction and coinduction proof technique described by Danielsson and Altenkirch [2010].Specifically, the proof is by lexicographic mixed induction and coinduction, first by coinduction on the (potentially infinite) structural subtyping derivation, and then by induction on the finite substitution stack Θ. □ However, the converse does not hold: parametric subtyping is incomplete with respect to structural subtyping, as the above example involving nat and snat [1] demonstrates.
Theorem 3.2 (Incompleteness of parametric subtyping). and  exist such that the structural subtyping  ⩽  holds but the parametric subtyping  ⟨Θ⟩ ⩽  ⟨Φ⟩ does not, for any Θ and Φ.

DECIDING STRUCTURAL SUBTYPING FOR MONOMORPHIC TYPES
In the next section, we will present a saturation-based decision procedure for parametric subtyping for parametric polymorphism.But parameterized type constructors involve some complications, so in this section, we will provide a gentle introduction to the algorithm by presenting a saturationbased decision procedure for structural subtyping of monomorphic types -that is, recursively defined types that do not take parameters nor use the structural types ∀ .and ∃ ..
Establishing the decidability of structural subtyping for monomorphic types is not a contribution of this paper.One existing decision procedure (see, e.g., [Lakhani et al. 2022]) directly employs backward search for a derivation of the structural subtyping judgment  ⩽ , using the subtyping rules themselves (Fig. 1).This procedure crucially depends on three properties: for monomorphic types, merely circular derivations suffice to characterize structural subtyping; circular derivations are finite; and there are finitely many subtyping problems involving named monomorphic types.
For polymorphic types, these key properties will no longer hold -which is why we will introduce a forward-inference, saturation-based procedure here.But even if one is uninterested in polymorphic types, this forward-inference procedure offers several distinct advantages over the backward-search algorithm, as we will discuss below.

A forward-inference decision procedure for monomorphic structural subtyping
To devise a decision procedure for monomorphic subtyping based on forward inference, we will exploit the fact that subtyping is a safety property and return to the idea that, in keeping with the safety slogan "nothing bad ever happens," a subtyping relationship  ⩽  holds when there is no counterexample.Very roughly speaking, our algorithm proceeds as a kind of automated refutation by contradiction, assuming that a derivation of  ⩽  exists and repeatedly inverting that assumed derivation to check that no violations of subtyping occur (i.e., that nothing bad happens) before reaching another subtyping problem,  ′ ⩽  ′ .Because the given set Σ of type definitions contains finitely many definitions  ≜  and  ≜  and there are therefore finitely many subtyping problems  ⩽ , we can check each problem in this way.
More precisely, the forward-inference procedure uses three judgments: the primary judgment,  ≼  ⇒ ⊥; and two intermediate judgments,  ≼  ⇒  ≼  and  ≼  ⇒  ≼ .(Notice that we use ≼ to distinguish these from the declarative ⩽.) Ultimately, the judgment  ≼  ⇒ ⊥ will be inferred if and only if  ⩽̸ , allowing us to decide the structural subtyping  ⩽  by running forward inference to saturation and checking that  ≼  ⇒ ⊥ has not been inferred.(Saturation is guaranteed, as we will prove in Theorem 4.3 below.)The judgments  ≼  ⇒  ≼  and  ≼  ⇒  ≼  are inferred if and only if  ⩽  and  ⩽ , respectively, would necessarily occur as subderivations of any derivation of  ⩽  (assuming such a derivation exists).
Alternatively, these judgments can be seen as describing necessary consequences of  ⩽ .From yet another perspective, these judgments can be seen as stating those constraints that must hold for the structural subtyping  ⩽  to be derivable, with ⊥ being the unsatisfiable constraint.This last perspective will prove particularly useful in Section 5 and the decision procedure for parametric subtyping of polymorphic types presented there.
4.1.1Forward inference.Forward inference proceeds according to the rules found in Fig. 3. Unlike the structural subtyping rules of Fig. 1, these algorithmic rules are interpreted inductively and most clearly read top-down, from premises to conclusion.To provide some intuition for this forward-inference decision procedure, we will walk through a few of the rules in detail.
The init-f rule.Suppose that the premises  ≜  and  ≜  hold.If  ⩽  is derivable, then, by inversion, it must have been derived by applying the unf-s structural subtyping rule to a subderivation of  ⩽ .That is,  ⩽  would necessarily occur as a subderivation of  ⩽  when  and  are defined by  ≜  and  ≜ , justifying the inference of  ≼  ⇒  ≼  by the init-f rule.
. Forward inference rules for deciding structural subtyping of monomorphic types (f for 'forward').These rules are interpreted inductively.The notation   means that  and  use distinct top-level structural type constructors, such as + and 1.
The compose-f ⊥ rule.Suppose that the premises  ≼  ⇒  ′ ≼  ′ and  ′ ≼  ′ ⇒ ⊥ have already been inferred.Thus, any derivation of  ⩽  would necessarily contain a subderivation of  ′ ⩽  ′ , and moreover  ′ ⩽  ′ is not derivable.Therefore,  ⩽  is also not derivable, justifying the inference of  ≼  ⇒ ⊥ by the compose-f ⊥ rule.
The mismatch-f ⊥ rule.Suppose that the premises  ≼  ⇒  ≼  and   have already been inferred, where   indicates that  and  have distinct top-level structural type constructors, such as +{ℓ :  ℓ } ℓ ∈ 1.Because the first premise has been inferred, any derivation of  ⩽  would necessarily contain a subderivation of  ⩽ .Because  , inversion shows there is no structural subtyping rule that could possibly form this subderivation.Hence  ⩽  is not derivable, justifying the inference of  ≼  ⇒ ⊥ by the mismatch-f ⊥ rule.
Because {z, s} ⊆ {z, s} as well as {s} ⊆ {z, s}, the +f rule then allows us to infer even ≼ nat ⇒ one ≼ one and even ≼ nat ⇒ odd ≼ nat; as well as odd ≼ nat ⇒ even ≼ nat as necessary consequences of the initial judgments about even ≼ nat and odd ≼ nat.At this point, saturation has been reached: no inference deduces any judgment that has not already been inferred.Because even ≼ nat ⇒ ⊥ has not been inferred upon saturation, we may conclude that even ⩽ nat is derivable -i.e., that even is a subtype of nat.Likewise, we conclude that odd is a subtype of nat.

Correctness of the forward-inference decision procedure
The forward-inference algorithm is both sound and complete with respect to (the monomorphic fragment of) structural subtyping as defined in Fig. 1.The proof of soundness relies on a key lemma.Proof sketch.From left to right, by appealing to Lemma 4.1; from right to left, by induction on the finite derivation of  ≼  ⇒ ⊥ to establish a (meta-)contradiction. □ We do not provide further details of these specific proofs here because this forward-inference procedure for structural subtyping of monomorphic types will be subsumed by the decision procedure for parametric subtyping of polymorphic types that will eventually be presented in Section 5.
The preceding theorem establishes that the above forward-inference algorithm is a semi-decision procedure.However, in this setting, forward inference is, in fact, guaranteed to saturate, making our algorithm a full-fledged decision procedure for structural subtyping of monomorphic types.Theorem 4.3 (Termination).Forward inference according to the rules of Fig. 3 always saturates.
Proof sketch.Finitely many definitions of the form  ≜  and  ≜  can be drawn from a given set Σ of definitions.For each such pair of structural types  and , there are finitely many subformulas (without unfolding type definitions).Each of the rules found in Fig. 3 infers a judgment  ≼  ⇒  ≼  only if either  and  are subformulas of  and , respectively, or  and  are subformulas of  and , respectively (again, without unfolding definitions).Therefore, only finitely many judgments can be inferred, so forward inference must eventually saturate.□

Further remarks
With respect to a backward-search decision procedure for structural subtyping of monomorphic types (see, e.g., [Lakhani et al. 2022]), the above forward-inference algorithm has two advantages.First, it is naturally incremental and compositional: If additional type definitions are introduced later in the program, inferences involving only prior definitions still hold and need not be performed again; only inferences involving the newly introduced definitions need to be performed.Second, the forward-inference algorithm can take advantage of inferences made along one branch when considering another branch.
With respect to the backward-search algorithm, our forward-inference algorithm, as formulated in Fig. 3, does not account for structural subtypings that arise from uninhabited types that exist when types' interpretation is inductive or mixed inductive/coinductive, such as those in work by Ligatti et al. [2017] and Lakhani et al. [2022].In this paper, we choose to work only with types that are interpreted coinductively.Because all such types are inhabited, the above forward-inference algorithm needs not account for such subtypings.We conjecture that the algorithm can be extended to inductive and mixed inductive/coinductive settings, but we leave that as future work.

DECIDING PARAMETRIC SUBTYPING FOR PARAMETRIC POLYMORPHISM
Leveraging the structure of the forward-inference algorithm for deciding structural subtyping of monomorphic types presented in the preceding section, we will now present a related algorithm for deciding parametric subtyping of polymorphic types.
At a high level, the algorithm uses saturating forward inference to derive the most general admissible parametric rules for each pair of defined type constructors, such as "e[] ⩽ d[ ′ ] if  ⩽  ′ ".Then, once these rules have been derived, a parametric subtyping problem can be decided by a second, backward proof construction phase that builds a finite derivation using the rules derived during the first phase.

Details of the decision procedure
As in the special case algorithm for monomorphic types (Section 4), there are three judgments for necessary consequences of a subtyping relationship between two types involving type constructors.However, now that type constructors may take parameters, these judgments must account for those parameters.Also, we choose to explicitly incorporate variances into the judgments for convenience.Possible variances  and  are co-and contravariance, which we write as + and −, respectively.(Bivariance is handled as mutual co-and contravariance, and nonvariance is handled implicitly by the algorithm.)An operation, ¬, on variances, given by ¬(+) = − and ¬(−) = +, is also useful.
Because the forward inference judgments will use explicit variances and because we will want to relate them to the declarative characterization of parametric subtyping, it is helpful to define the abbreviation  ⟨Θ⟩ ⩽   ⟨Φ⟩ such that:  [𝜙] ⟨Φ⟩ (assuming such a derivation exists).
5.1.1Phase 1: Forward inference.Forward inference proceeds according to the rules found in Fig. 4. Once again, these rules are interpreted inductively and are more clearly read top-down, from premises to conclusion.Many of the rules are carried over from the decision procedure for structural subtyping of monomorphic types that was described in Fig. 3 (page 15, Section 4), with the addition of parameters and variances.For example, the essential aspects of the ×f, +f, and mismatch-f ⊥ rules are unchanged from Fig. 3.We will detail a few of the other rules.
The compose-f rule.The most important difference between the rules of Fig. 4 and those of Fig. 3 is that it is now possible to infer judgments of the form These represent constraints that must hold of any instantiation  [ ] ≼  [𝜙] #  of type constructors  and .This idea is captured in the compose-f rule: Suppose that the first premise, . Forward inference rules for phase 1 of deciding parametric subtyping for parametric polymorphism (f for 'forward').These rules are interpreted inductively.The notation   means that  and  use distinct top-level structural type constructors, such as + and 1.Also,  ⊆ +  iff  ⊆ ; and Fig. 5. Backward proof construction rules for phase 2 of deciding parametric subtyping for parametric polymorphism (b for 'backward').These rules are interpreted inductively.

Example
. Returning to our running example of context-free languages, we can examine the inferences made by our algorithm to infer admissible subtyping rules for pairs of type constructors.By virtue of the init-f rule, the following judgments, among others, will be inferred.
Because {R} ⊆ {L, R} ⊆ {L, R} and {$} ⊆ {L, $} ⊆ {L, $}, the +f rule then allows us to infer as necessary consequences of the initial judgments.The compose-f rule can be applied to (6) and (7), as well as to (9) and (7), to infer (The compose-f rule could also be applied to ( 12) and ( 8) but that has already been inferred as (7).)At this point, saturation has been reached for all pairs of constructors above.Because no such pair has had ⊥ inferred as a consequence by the time saturation occurs, admissible subtyping rules for all such pairs do exist.Collecting the respective atomic constraints, namely (7) and (8), we see that these admissible rules are and one ≼ one # + .5.1.3Phase 2: Backward proof construction.Having inferred the most general admissible parametric rule for each pair of type constructors, the second, backward proof construction phase begins.For this phase, we introduce a judgment  ≼  # .Given a parametric subtyping problem  ≼  # , the types  and  are examined, searching for a derivation according to the rules of Fig. 5.
Because parameters can only appear free within type definitions, neither  nor  can be a parameter.Also, a type variable is a subtype of only itself, so there are no rules for  ≼  [𝜙]

Correctness of the decision procedure for parametric subtyping
The algorithm described above is both sound and complete with respect to the declarative characterization of parametric subtyping given in Fig. 2. We give only sketches of the proofs here; details can be found in the extended version of this paper [DeYoung et al. 2023a].
Following the pattern laid out for monomorphic types, the proof of soundness relies on the following key lemma that generalizes Lemma 4.1.
Completeness also requires a lemma, but then follows by structural induction on the type .
Lemma 5.3. ( Proof sketch.Each part is proved as follows. (1) Directly, noting that only the init-f rule can derive (3) We generalize the lemma to show that  [ ] ⟨Θ⟩ ⩽   [𝜙] ⟨Φ⟩ and  [ ì ] ≼  [ ì ] #  ⇒ ⊥ together imply a meta-contradiction.This is proved by induction on the finite derivation of We must also prove that forward inference and backward proof construction terminate.
Theorem 5.5 (Termination).Forward inference and backward proof construction according to the rules of Figs. 4 and 5, respectively, terminate.
Proof sketch.Finitely many definitions  [ ì ] ≜  and  [ ì ] ≜  can be drawn from a given set Σ of definitions and combined with one of two variances, so the init-f rule infers only finitely many judgments By induction, we can show that each of the other rules found in Fig. 4, including the compose-f rule, will infer a judgment and  are proper subformulas of  and .Moreover,  and  have finitely many subformulas (without unfolding definitions).
But special care needs to be taken with the ∀f and ∃f rules.Because there is an infinite supply of fresh variables, it might seem like these rules could be applied to a given judgment, such as /] #  ′ and so on.However, we treat inferred judgments as equivalent up to -renaming of their free type variables, which are implicitly universally quantified over the judgment.Therefore, up to -renaming, the ∀f and ∃f rules only infer a single judgment per distinct premise.This kind of subsumption of -equivalent judgments is a standard assumption in resolution-based saturation procedures [Robinson 1965].
Because only finitely many judgments can be inferred, forward inference in phase 1 must terminate.Backward proof construction in phase 2 terminates because its recursion occurs at successive subformulas.□ Saturating forward inference facilitates sharing of inferred subtyping constraints across branches.
Because of issues with non-regular type constructors (see Section 2.2.3), this is essential to capture non-regularity.It is thus unclear if the algorithm could be recast in a recursive functional way.
If we would like certain definitions to act as mere abbreviations that are (conceptually) always expanded, then our system can easily accommodate this as long as those definitions are not recursive.To integrate such nonrecursive type abbreviations into the declarative characterization of parametric subtyping, we could add the following rule and restrict the inst-p to apply only when neither type constructor is a nonrecursive abbreviation.
Forward inference in phase 1 and backward proof construction in phase 2 of the decision procedure would similarly expand nonrecursive abbreviations.It is easy to see that both phases still terminate.Because of mutual recursion, the implementation proceeds in two phases: first checking basic consistency and normalizing types, thereby introducing additional, internal definitions.The second phase executes the saturation algorithm (Section 5) and answers queries by consulting the saturated database.There are only the following few minor points of departure from this paper.

Our implementation in
6.1 Nonrecursive type abbreviations.
The implementation allows type definitions (which are always treated parametrically) but also explicit type abbreviations which may be parameterized but must be nonrecursive.These abbreviations are expanded structurally, as described above.Depending on the larger language context, an alternative would be to treat every nonrecursive type definition as an abbreviation.

Elaboration to normal form.
Before elaboration, every definition in Σ has the form  [ ì ] ≜  where  is structural (which guarantees contractiveness) but may not be in normal form.We map each such definition to  [ ì ] ≜  * , using the auxiliary translation  † in which  need not be structural.In the process, we may introduce further, internal definitions.Here,  † is defined pointwise.Computing the free type parameters free() avoids creating internal definitions with unnecessary parameters.Also, notice that, during elaboration, quantified type variables  become parameters  that are then instantiated with the corresponding variable  after normalization.Therefore, no case for () † is needed.We can also obtain additional sharing (and therefore faster convergence of the saturation algorithm) in the clause for () † by reusing a definition  [ ì ] if  [ ì ] ≜  * is already in the definitions Σ (modulo renaming of the parameters).
6.3 Indexing in the database.
In the implementation, we combine all facts We keep constraints C in a normal form where no entries are repeated and any conjunction with ⊥ is reduced to ⊥ alone.This facilitates efficient lookup and detection of saturation.

Lists
The polymorphic type of lists of elements of a type , as well as the types of empty and nonempty lists, can be defined as follows.According to this type, a serialized tree is a list of leaf and node labels.A leaf is followed by a suffix of type ; a node is followed by the pair of the tree's root element of type  and the serialization of the left subtree, which itself is followed by the serialization of the right subtree.12This type crucially depends on nested types to express the invariant that stree[, ] describes preorder traversals of binary trees.Our saturation algorithm verifies that stree[, ] is covariant in both  and .
Although unrelated to subtyping concerns, it is interesting to observe that the above type definition can, in fact, be derived syntactically by repeatedly applying type isomorphisms to the definition stree None of the isomorphic types in this sequence are mutual subtypes, however.In particular, although the types stree[, ] and tree[] ×  are isomorphic, we do not have tree [𝜏] as a subtype of stree [𝜏, 1], nor vice versa, for any .Comparing the leaf branches of both types, we see that, for these parametric subtyping relationships to hold, 1 ⩽  and  ⩽ 1 must hold for all types , regardless of the fact that stree [𝜏, 1] ultimately instantiates  with 1.This is simply not true when  is, for example, either +{ } or 1 × 1.
Once again, the absence of subtyping relationships does not mean that the type stree[, ] cannot be related to tree[] × .Given a term language with support for nested types, it would still be possible to write explicit coercions between these types to serialize and deserialize trees.Then, the right subtree is looked up in this object, and the value of type  associated with the entire nonempty tree is ultimately returned.This example makes essential use of a record type to represent the object's methods, but most importantly, nested types are crucial to expressing the higher-order nature of lookups.In the usual way, our algorithm confirms that treefn[, ] is contravariant in  and covariant in .
7.4.2Total functions on spines.In a similar way, we can derive a type definition for total functions on (left) spines, using the types spine[] and etree defined in Section 7. Subtyping polymorphic types.In this paper, we chose to have a foundational approach, including the features strictly necessary to handle parametric datatypes in programming languages.Bird and Meertens [1998] and Hinze [2000] noted that implementing generalized tries required the use of nested datatypes and non-regular recursion, which is our setting for this paper.Other type systems have been developed to explore non-regular data structures.In the context of session types, Thiemann and Vasconcelos [2016] proposed context-free session types with predicative polymorphism, extended later with impredicative polymorphism [Almeida et al. 2022]; subtyping was also explored [Silva et al. 2023].Nested session types were proposed by Das et al. [2022] and were proved to be more expressive than context-free session types [Das et al. 2022;Gay et al. 2022].
Inspired by the structural nature of types, these works have focused on structural subtyping and equivalence relations.For session types, the subtyping problem has been shown to be undecidable [Padovani 2019;Silva et al. 2023], even though the corresponding type equality problems are decidable [Almeida et al. 2020;Das et al. 2022;Solomon 1978].In Section 2.3, we present the result more generally for type systems with record types, explicitly identifying sets of minimal features that guarantee the undecidability of subtyping.The undecidability of the subtyping relation leads to the design of incomplete algorithms.The parametric subtyping relation we propose allows us to both tackle the incompleteness problem and to understand exactly to what extent the previous relations are incomplete, distinguishing cases where parametricity is not satisfied from cases where types actually exhibit distinct behaviors and are therefore not in (any) subtyping relation.Parametricity materializes the idea that types behave uniformly for all possible instantiations.This notion was first proposed by Reynolds [1983] for System F [Girard 1972], further explored by Wadler [1989] and then extended to nested types by Johann and Ghiorzi [2021].None of these works focused on the subtyping relation.The combination of parametricity and subtyping is the main contribution of our work through type constructors that map (subtyping-)related arguments to (subtyping-)related results, in a relation that we called parametric subtyping.
Several works focus on mixing subtyping with (explicit) parametric polymorphism via bounded quantification [Cardelli and Wegner 1985].The most standard formulation is the second-order lambda-calculus with bounded quantification,  ≤ [Cardelli et al. 1994], but subtyping was proved to be undecidable [Pierce 1994], even without recursion.Several  ≤ fragments have been identified as having a decidable subtyping relation [Cardelli and Wegner 1985;Castagna and Pierce 1994;Katiyar and Sankar 1992;Mackay et al. 2020], also extended with recursion [Abadi et al. 1996;Zhou et al. 2023] or higher-order polymorphism and polarized application [Steffen 1999].System  ≤ was the ground for many developments in OOP [Rompf and Amin 2016].As none of the applications we want for our type system seem to require bounded polymorphism at its most fundamental core, we limit our setting to parametric polymorphism and explicit quantifiers.
Other work studies the interaction of subtyping with type inference and implicit polymorphism, such as that of Dolan and Mycroft [2017] and Lepigre and Raffalli [2019].As previously mentioned, even without recursive types or type constructors, subtyping for implicit polymorphism is already undecidable [Tiuryn and Urzyczyn 2002;Wells 1995], meaning that implicit polymorphism would not be a good starting point for our study of non-regular type constructors and parametricity.In addition to this difference, Dolan and Mycroft [2017] focus on generative, regular type constructors, whereas our work deals with structural, non-regular type constructors.
Semantic vs algorithmic subtyping definitions.Semantic typing and subtyping are favored in non-regular structural type systems over their declarative versions.Initially, semantic relations were motivated by the set-theoretic properties of types [Castagna and Frisch 2005;Frisch et al. 2002;Lakhani et al. 2022], but for non-regular types the need for a semantic relation to model the behavior of types was even more natural, by means of simulations and bisimulations [Das et al. 2022;Gay and Hole 2005;Silva et al. 2023].
Algorithmic approaches for monomorphic or regular (sub)typing systems, such as standard fixedpoint algorithms [Gay and Hole 2005], sequent calculus [Das et al. 2022], cyclic proofs [Brotherston and Simpson 2010;Lakhani et al. 2022], step indexing [Ahmed 2004[Ahmed , 2006;;Appel and McAllester 2001;Dreyer et al. 2009;Lakhani et al. 2022], sized types [Abel and Pientka 2016] or bouncing threads [Baelde et al. 2022], are effective.However, these mechanisms are not scalable when we navigate beyond regular types.In section 2.2.3, we illustrate the narrow scope of the above approaches and the limitations of their application to nested types.To limit the recursion depth, a recursion bound is usually used, leading to incompleteness [Das et al. 2022] or even unsoundness 13 .The undecidability of structural subtyping for the non-monomorphic fragment gives us no hope of finding a sound and complete algorithm.In this paper, we free our type system from this limitation by proposing the novel notion of parametric subtyping, which takes advantage of parametricity without completely abandoning structural subtyping.In an attempt to overcome the limitations of alternatives such as bouncing threads or cyclic proofs, we end up finding a sweet spot that takes advantage of saturation-based methods to perform forward-inference, often used in constraint solving [Jaffar and Lassez 1987] and unification [Huet 1976;Martelli and Montanari 1982].

CONCLUSION
In this paper, we presented a theory of parametricity for type constructors that forms the basis for parametric subtyping, a decidable, practical, and expressive fragment of structural subtyping for parametric polymorphism.Moreover, the saturation-based decision procedure has led to an effective implementation that performs well on a variety of practical examples.
One opportunity for future work is to extend our results to a mixed inductive/coinductive type system, as in call-by-push-value [Levy 2001], that accounts for subtypings that rely on types being uninhabited or full, such as +{ } ⩽  and  ⩽ +{ } →  for all  and .We do already have a prototype implementation that does so, but the decision procedure's theory and accompanying correctness proofs appear to be more complicated.Other opportunities include extension to bounded quantification, integration with intersection and union types, and development of a notion of parametric subtyping for higher-order kinds.
Proof.Using the mixed induction and coinduction proof technique described by Danielsson and Altenkirch [2010].Specifically, the proof is by lexicographic mixed induction and coinduction, first by coinduction on the (potentially infinite) structural subtyping derivation, and then by induction on the finite substitution stack Θ.To construct a derivation of  ′ ⟨ ′ ; Θ⟩ ⩽  ′ ⟨ ′ ; Φ⟩, we will appeal to the coinductive hypothesis.This appeal is valid because it will be guarded by the above rule.To make the appeal, we need to first establish the three preconditions.To construct a derivation of  ′ ( ′ )⟨Θ⟩ ⩽  ′  ′ ( ′ )⟨Φ⟩, we will again appeal to the coinductive hypothesis.This appeal is valid because it will be guarded, by this rule as well as the above rule.The second and third preconditions follow immediately from our earlier assumptions.
• • for a given , , and  into a single entry  [ ì ] ≼  [ ì ] #  ⇒ C, where constraints C are given by elist ≜ +{nil : 1} list[] ≜ +{nil : 1, cons :  × list[]} nelist[] ≜ +{cons :  × list[]} By running our saturation algorithm and examining the atomic constraints on list[] and itself, we can verify that list[] is covariant in ; we can similarly verify that nelist[] is covariant in .Moreover, our algorithm confirms the parametric rules elist ⩽ list[], as well as nelist[] ⩽ list[] if  ⩽ .And lists of nonempty lists of even natural numbers are, more generally, lists of lists of natural numbers, and our algorithm confirms that list[nelist[even]] ⩽ list[list[nat]], for example.Similarly to lists, the polymorphic type of binary trees of s can be defined as follows.tree[]≜+{leaf: 1, node :  × (tree[] × tree[])} Thus, a tree of s is either leaf with the unit value, or node with a tuple of an element of type  and the left and right subtrees.Our saturation algorithm verifies that tree[] is covariant in .Similar to those for lists, the types of empty and nonempty trees of s are subtypes of tree[]: etree ≜ +{leaf : 1} netree[] ≜ +{node :  × (tree[] × tree[])} 7.2.2Spines.Because the left and right spines of a tree are essentially lists, we might at first expect to have list[] ⩽ tree[] whenever  ⩽ .However, even if we were to coordinate the label names across the two types, that subtyping relationship would not hold because it would require list[] ⟨/⟩ ⩽ (tree[] × tree[])⟨/⟩ -that is, it would require a (nonempty) sum type to be a subtype of a product type.Indeed, saturation yields list[] ≼ tree[] # + ⇒ ⊥ for that reason.Instead, we could define a type of left spines as follows; right spines would be symmetric.spine[]≜+{leaf:1,node:×(spine[] × etree)} With this definition, we do have spine[] ⩽ tree[] when  ⩽  because the product type spine[] × etree is a subtype of tree[] × tree[] under / and /.7.2.3Object-oriented lists and trees.On a related note, we could take a more object-oriented approach to lists and trees, using record types instead of eager products: olist[] ≜ {out : +{none : 1, some :  × {fst : olist[] }}, size : nat} otree[] ≜ {out : +{none : 1, some :  × {fst : otree[], snd : otree[]}}, size : nat} Even purely structurally, olist[] ⩽ otree[] does not hold when  ⩽ , but otree[] ⩽ olist[]does when  ⩽  and is in the parametric fragment.This is somewhat counterintuitive, but nevertheless the correct relationship: any context that expects a list can use a tree's spine instead.7.2.4 Perfect binary trees.Taking advantage of the support for nested types, we can adapt Bird and Meertens's prototypical example of perfect binary trees[1998].Our algorithm confirms that perfect[] is covariant in .However, even purely structurally, perfect[]is not a subtype of tree[] for any  and .That would require perfect[ × ] to be a subtype of tree[] × tree[], which cannot be: perfect[ × ] is a variant record type, whereas tree[] × tree[] is a product type.Essentially, the difference amounts to one between breadth-first and depth-first representations of trees.However, the lack of a subtyping relationship does not mean that the type perfect[] is unusable: given the support for nested types, an explicit coercion from perfect[] to tree[] could still be written.Serialized binary trees.Here we adapt an example from Thiemann and Vasconcelos [2016] and consider it in the context of subtyping: We may sometimes wish to serialize a binary tree to send it across the network or write it to a file.A type that describes serialized trees is stree[, ], parameterized by both the type of data elements, , and a suffix (or continuation) type, : stree[, ] ≜ +{leaf : , node :  × stree[, stree[, ]]} .
way of serializing polymorphic data, this is as near to a true serialization as is possible.Moreover, for concrete instances of tree, such as with nat data, it is possible to give true serializations that inline the serialization of their data elements: snattree[ ] ≜ +{leaf : , node : snat[snattree[snattree[ ] ] ] }, where snat[ − ] is defined as in Section 3.1.used [Connelly and Morris 1995;Hinze 2000;Wadsworth 1979 subtyping direction is reversed because of contravariance in the underlying function types.)7.4.3Tries for trees and spines.In prior work[Connelly and Morris 1995;Hinze 2000;Wadsworth 1979], the trie data structure for lists and strings was generalized to represent partial (not total) functions on more complex algebraic structures, such as binary trees.A type definition for tries from keys of type tree[]to values of type  can be derived from trie[, ] ≜ tree[] → option[],where option[] ≜ +{none : 1, some : }.