1 Introduction
Applications of the induction and coinduction principles, and of concepts related to them, in scientific fields are plenty, including ones in economics and econometrics [35], in mathematical physics [38], in computer science, and in many other areas of mathematics itself. Their applications in computer science, in particular, include ones in programming language semantics—which we touch upon in this article—as well as in relational database theory (e.g., recursive or iterated joins) and in concurrency theory.^{1}^{1}1For more details on the use of induction, coinduction, and fixed points in computer science, and for concrete examples of how they are used, the reader is invited to check relevant literature on the topic, e.g., [26, 39, 15, 42, 32].
Fixed points, induction and coinduction have been formulated and studied in various subfields of mathematics, usually using different vocabulary in each field. The interested reader is invited to check our concise comparative survey in [8].
Of particular interest to programming languages researchers, in this article we give attention to the fundamental conceptual difference between structural type theory, where type equality and type inclusion are defined based on type structures but not on type names, and nominal type theory, where type equality and type inclusion are defined based on the names of types in addition to their structures. Given their difference in how each particularly defines the inclusion relation between types (i.e., the subtyping relation), the conceptual difference between structural typing and nominal typing expresses itself, prominently, when fixed points and related concepts are formulated in each of structural type theory and nominal type theory.
As such, in this article we present the formulation of these concepts in the theory of types of functional programming languages (which is largely structurallytyped) in 2.1 (2.1 Inductive and Coinductive Functional Data Types), then we follow that by presenting their formulation in the type theory of objectoriented programming languages (which is largely nominallytyped) in 2.2 (2.2 ObjectOriented Type Theory).
In 7 of [8] we summarized the article by presenting tables that collect the formulations given in the article. Based on the tabular comparison in 7 of [8] and based on the discussions in 2 (and in 3 of [8]), we discuss in 3 (3 Structural Type Theory versus Nominal Type Theory) some of the fundamental differences between structural typing and nominal typing, particularly ones related to type negation and coinductive types, and we also discuss some consequences of these fundamental differences.
2 Programming Languages Theory
Given the ‘types as sets’ view of types in programming languages, this section builds on the settheoretic presentation in 3 of [8] to present the induction and coinduction principles using the jargon of programming languages type theory. The presentation allows us to demonstrate and discuss the influence structural and nominal typing have on the theory of type systems of functional programming languages (which mostly use structural typing) and objectoriented programming languages (which mostly use nominal typing).
2.1 Inductive and Coinductive Functional Data Types
Formulation
Let be the set of structural types in functional programming.^{2}^{2}2By construction/definition, the poset of structural types under the inclusion/structural subtyping ordering relation is always a complete lattice. This point is discussed in more detail below.
Let (‘is a subset/subtype of’) denote the structural subtyping/inclusion relation between structural data types, and let (‘has type/is a member of/has structural property’) denote the structural typing relation between structural data values and structural data types.
Now, if is a polynomial (with powers) datatype constructor^{3}^{3}3That is, is one of the , , or data type constructors (i.e., the summation/disjointunion/variant constructor, the product/record/labeledproduct constructor, or the continuousfunction/exponential/power constructor, respectively) or is a composition of these constructors. By their definitions in domain theory [43, 40, 27, 30, 12, 23, 19], these structural datatype constructors, and their compositions, are monotonic (also called covariant) datatype constructors (except for the first type argument of , for which is an antimonotonic/contravariant constructor, but that otherwise “behaves nicely” [34])., i.e., if
then an inductivelydefined type/set , the smallest closed set, exists in , and is also the smallest fixed point of , and a coinductivelydefined type/set , the largest consistent set, exists in , and is also the largest fixed point of .^{4}^{4}4See Table 1 of [8] for the definitions of and .
Further, for any type (where , as a structural type, expresses a structural property of data values) we have:

(structural induction, and recursion)
(i.e., ),
which, in words, means that if the (structural) property is preserved by (i.e., if is closed), then all data values of the inductive type have property (i.e., ).
Furthermore, borrowing terminology from category theory (see 6 of [8]), a recursive function that maps data values of the inductive type to data values of type (i.e., having structural property ) is the unique catamorphism (also called a fold) from to (where is viewed as an initial algebra and as an algebra), and 
(structural coinduction, and corecursion)
(i.e.,
which, in words, means that if the (structural) property is reflected by (i.e., if is consistent), then all data values that have property are data values of the coinductive type (i.e., ).
Furthermore, borrowing terminology from category theory, a corecursive function that maps data values of type (i.e., having structural property ) to data values of the coinductive type is the unique anamorphism from to (where is viewed as an coalgebra and as a final coalgebra).
Notes

To guarantee the existence of and in for all type constructors , and hence to guarantee the ability to reason easily—i.e., inductively and coinductively—about functional programs, the domain of types in functional programming is deliberately constructed to be a complete lattice under the inclusion ordering. This is achieved by limiting the type constructors used in constructing and over to structural type constructors only (i.e., to the constructors , , and their compositions, in addition to basic types such as Unit, Bool, Top, Nat and Int).

For example, the inductive type of lists of integers in functional programming is defined structurally (i.e., using , , and structural induction) as
which defines the type as (isomorphic/equivalent to) the summation of type Unit (which provides the value unit as an encoding for the empty list) to the product of type Int with type itself.

In fact the three basic types Bool, Nat and Int can also be defined structurally. For example, in a functional program we may structurally define type Bool using the definition (for false and true), structurally define type Nat using the definition (for 0 and the successor of a natural number), and, out of other equallyvalid choices, structurally define type Int using the definition (for negative integers, zero, and positive integers).

References
2.2 ObjectOriented Type Theory
The accurate and precise understanding of the generic subtyping relation in mainstream OOP languages such as Java, C#, C++, Kotlin and Scala, and the proper mathematical modeling of the OO subtyping relation in these languages, is one of our main research interests. Due to the existence of features such as wildcard types, type erasure, and bounded generic classes (where classes^{5}^{5}5The notion of class in this article includes that of an abstract class, of an interface, and of an enum in Java [24]. It also includes similar “typeconstructing” constructs in other nominallytyped OO languages, such as traits in Scala [36]. And a generic class is a class that takes a type parameter (An example is the generic interface List in Java—that models lists/sequences of items—whose type parameter specifies the type of items in a list).
play the role of type constructors), the mathematical modeling of the generic subtyping relation in mainstream OOP languages is a hard problem that, in spite of much effort, seems to still have not been resolved, at least not completely nor satisfactorily, up to the present moment
[45, 25, 6, 4, 9, 7].The majority of mainstream OO programming languages are classbased, and subtyping () is a fundamental relation in OO software development. In industrialstrength OOP, i.e., in staticallytyped classbased OO programming languages such as Java, C#, C++, Kotlin and Scala, class names are used as type names, since class names—which objects carry at runtime—are assumed to be associated with behavioral class contracts by developers of OO software. Hence, the decision of equality between types in these languages takes type names in consideration—hence, nominal typing. In agreement with the nominality of typing in these OO languages, the fundamental subtyping relation in these languages is also a nominal relation. Accordingly, subtyping decisions in the type systems of these OO languages make use of the inherentlynominal inheritance declarations (i.e., that are explicitly declared between class names) in programs written using these languages.^{6}^{6}6Type/contract inheritance that we discuss in this article is the same thing as the inheritance of behavioral interfaces (APIs) from superclasses to their subclasses that mainstream OO software developers are familiar with. As is empirically familiar to OO developers, the subtyping relation in classbased OO programming languages is in onetoone correspondence with API (and, thus, type/contract) inheritance from superclasses to their subclasses [46]. Formally, this correspondence is due to the nominality of the subtyping relation [2]. (For a more detailed overview of nominal typing versus structural typing in OOP see [1].)
Formulation
Let (‘is a subtype of’) denote the nominal subtyping relation between nominal data types (i.e., class types), and let (‘has type’) denote the nominal typing relation between nominal data values (i.e., objects) and nominal data types.
Further, let be the set of nominal types in objectoriented programming, ordered by the nominal subtyping relation, and let be a type constructor over (e.g., a generic class).^{7}^{7}7Unlike poset in 2.1 (of structural types under the structural subtyping relation), poset (of nominal types under the nominal subtyping relation) is not guaranteed to be a complete lattice.
A type is called an ‘supertype’ if its image is a subtype of it, i.e., if
and is said to be preserved by . (An supertype is sometimes also called an closed type, lower bounded type, large type, inductive type, or algebraic type). The root or top of the subtyping hierarchy, if it exists (in ), is usually called Object or All, and it is an supertype for all generic classes . In fact the top type, when it exists, is the greatest supertype for all .
A type is called an ‘subtype’ if it is a subtype of its image, i.e., if
and is said to be reflected by . (An subtype is sometimes also called an consistent type, (upper) bounded type^{8}^{8}8From which comes the name bounded generics in objectoriented programming., small type, coinductive type, or coalgebraic type). The bottom of the subtyping hierarchy, if it exists (in ), is usually called Null or Nothing, and it is an subtype for all generic classes . In fact the bottom type, when it exists, is the least subtype for all .
A type is called a fixed point (or ‘fixed type’) of if it is equal to its image, i.e., if
As such, a fixed point of is simultaneously an supertype and an subtype. (Such fixed types/points are rare in OOP practice).
Now, if is a covariant generic class (i.e., a typesgenerator)^{9}^{9}9Generic classes in Java are in fact always monotonic/covariant, not over types ordered by subtyping but over interval types ordered by containment. (See [10].) In particular, for any generic class in Java we have
and if , the ‘least supertype’ exists in , and is also the least fixed point of , and if , the ‘greatest subtype’, exists in , and is also the greatest fixed point of ,^{10}^{10}10See Table 2 of [8] for the definitions of and in the (rare) case when happens to be a complete lattice. then, for any type we have:

(induction)
(i.e., ),
which, in words, means that if the contract (i.e., behavioral type) is preserved by (i.e., is an supertype), then the inductive type is a subtype of , and 
(coinduction)
(i.e., ),
which, in words, means that if the contract (i.e., behavioral type) is reflected by (i.e., is an subtype), then is a subtype of the coinductive type .
Notes

As discussed earlier and in , in structural type theory type expressions express only structural properties of data values, i.e., how the data values of the type are structured and constructed. In nominal type theory type names are associated with formal or informal contracts, called behavioral contracts, which express behavioral properties of the data values (e.g., objects) in addition to their structural properties.

To demonstrate, in a pure structural type system a record type that has, say, one member (e.g., type plane fly() , type bird fly() and type insect fly() ) is semantically equivalent to any other type that has the same member (i.e., type plane is equivalent to type bird and to type insect)—in other words, in a pure structural type system these types are ‘interchangeable for all purposes’.

On the other hand, in a pure nominal type system any types that have the same structure but have different names (e.g., types plane, bird and insect) are considered distinct types that are not semantically equivalent, since their different names (e.g., ‘plane’ versus ‘bird’ versus ‘insect’) imply the possibility, even likelihood, that data values of each type maintain different behavioral contracts, and thus of the likelihood of different use considerations for the types and their data values.^{11}^{11}11For another example, a float used for monetary values (e.g., in finanicial transactions) should normally not be confused with (i.e., equated to) a float used for measuring distances (e.g., in scientific applications). Declaring type money=float type distance=float does not help in a purely structural type system, however, since the types float, money, and distance are structurally equivalent. On the other hand, in a purely nominal type system the declarations of types money and distance do have the desired effect, since the nonequivalence of the types is implied by their different names.^{,}^{12}^{12}12Further, when (1) the functional components of data values are (mutually) recursive, which is typical for methods of objects in OOP [5], and when (2) data values (i.e., objects) are autognostic data values (i.e., have a notion of self/this, which is an essential feature of mainstream OOP [20])—which are two features of OOP that necessitate recursive types—then the semantic differences between nominal typing and structural typing become even more prominent, since type names and their associated contracts gain more relevance as expressions of the richer recursive behavior of the more complex data values. (For more details, see [3] and [39, 19.3].)


In industrialstrength OO programming languages (such as Java, C#, C++, Kotlin and Scala) where types are nominal types rather than structural ones and, accordingly, where subtyping is a nominal relation, rarely is poset a lattice under the subtyping relation , let alone a complete lattice. Further, many type constructors (i.e., generic classes) in these languages are not covariant. As such, and rarely exist in .^{13}^{13}13Annihilating the possibility of reasoning inductively or coinductively about nominal OO types. Still, the notion of a prefixed point (or of an algebra) of a generic class and the notion of a postfixed point (or of an coalgebra) of , under the names supertype and subtype respectively, do have relevance in OO type theory, e.g., when discussing bounded generics [7].^{14}^{14}14In fact, owing to our research interests (hinted at in the beginning of 2.2), inquiries in [7] have been a main initial motivation for writing this note/article. In particular, we have noted that if is a generic class in a Java program then a role similar to the role played by the coinductive type is played by the wildcard type F<?>, since, by the subtyping rules of Java (discussed in [7], and illustrated vividly in earlier publications such as [9, 6]), every subtype (i.e., every parameterized type constructed using —called an instantiation of —and every subtype thereof) is a subtype of the type F<?>. On the other hand, in Java there is not a nonNull type (not even type F<Null>; see [7]) that plays a role similar to the role played above by the inductive type (i.e., a type that is a subtype of all supertypes, which are all instantiations of and all supertypes thereof). This means that in Java greatest postfixed points (i.e., greatest subtypes) that are not greatest fixed points do exist, while nonbottom least prefixed points (i.e., least supertypes) do not exist. Also, since is rarely a complete lattice, greatest fixed points, generallyspeaking, do not exist in Java, neither do least fixed points. These same observations apply moreorless to other nominallytyped OOP languages similar to Java, such as C#, C++, Kotlin and Scala. (See further discussion in Footnote 18 in of [8].)

While not immediately obvious (nor widelyknown), but, as a set of pairs of types, the subtyping relation in nominallytyped OOP is in fact a coinductive set, i.e., is a coinductivelydefined subset of the set of all pairs of class types [39, Ch. 21]. That is because subtyping between two types holds in nominallytyped OOP as long as there is no (finite) reason for it not to hold. The following is in fact how javac, the standard Java compiler, typechecks Java programs: During type checking javac assumes that a subtyping relation between two given types holds unless the type checker can (finitely) prove, using the explicitly specified subtyping declarations in a Java program, that the relation cannot hold.^{15}^{15}15The subtyping relation in Java seems to be even a little bit more complex than a coinductive set. Due to the existence of wildcard/interval types, the Java subtyping relation, together with the containment relation between wildcard/interval types [10], seems to be an instance of a mutually coinductive set (i.e., the coinductive counterpart of a mutually inductive set, which we did not get to discuss in this article but may do in the future.)

In particular, to the best of our knowledge, the Java language specification does not stipulate that the subtyping relation holds between two types only if the relation can be (finitely) proven to hold between the two types (see [24, 4.10]). This missing “disclaimer”, which is usually stipulated in the definition of similar relations but that seems to be intentionally missing in the definition of the subtyping relation between class types (a.k.a., reference types) in Java, allows for the subtyping relation in Java to be coinductive.

References
3 Structural Type Theory versus Nominal Type Theory
3.1 Existence of Fixed Points
The discussion in 2.1, together with that in 3 and 5 of [8], demonstrates that FP type theory, with its structural types and structural subtyping rules being motivated by mathematical reasoning about programs (using induction or coinduction), is closer in its flavor to set theory (and firstorder logic/predicate calculus), since structural type theory assumes and requires the existence of fixed points and in for all type constructors . (For a discussion of the importance of structural typing in FP see [29, 33] and [39, 19.3].)
On the other hand, the discussion in 2.2, together with that in 6 and 2 of [8], demonstrates that OOP type theory, with its nominal types and nominal subtyping being motivated by the association of nominal types with behavioral contracts, is closer in its flavor to category theory and order theory, since nominal type theory does not assume or require the existence of fixed points and in for all type constructors . (For a discussion of why nominal typing and nominal subtyping matter in OOP see [3] and [39, 19.3].)
As such, we conclude that the theory of data types of functional programming languages is more similar in its views and its flavor to the views and flavor of set theory and firstorder logic, while the theory of data types of objectoriented programming languages is more similar in its views and its flavor to those of category theory and order theory. This conclusion adds further supporting evidence to our speculation (e.g., in [6, 4]) that category theory is more suited than set theory for the accurate understanding of mainstream objectoriented type systems.
3.2 Type Negation, Coinductive Nominal Types, and Free Types
In 3 of [11] we noted that negation of a mathematical object (e.g., a logical statement, a set, or a type) is useful in defining coinductive objects. We also noted that negation in set theory amounts to set complementation, which is useful in defining coinductive sets in terms of inductive sets. We wondered also about defining negation in other categories, such as the category of structural types (ordered by structural subtyping) in functional programming languages and the category of nominal types (ordered by nominal subtyping) in objectoriented programming languages. We resume this discussion here.
In objectoriented programming for example (see 2.2), we may try to define negation of a class type as follows. First, let’s define an “implication” type (which may also be called an ‘exponential type’) from type to type as
(1) 
i.e., as the join of all types whose meet with type is a subtype of type ,^{16}^{16}16Formula (1) comes from the study of Heyting algebras (which model constructive/intuitionistic logic). The formula is valid for defining complementation in set theory (where join is interpreted as set union , meet is interpreted as set intersection , is interpreted as set inclusion , and is interpreted as the empty set ), since the inclusion lattice in set theory is a Boolean algebra and every Boolean algebra is a Heyting algebra. As such, in set theory the complement of a set (as a negation of ) can also be defined as
which in other words means defining type negation as
i.e., defining the negation of a type as the join of all types parallel to the type,^{17}^{17}17The term parallel here is used in an ordertheoretic sense. In an ordered set two elements are parallel if neither holds nor holds (i.e., and are “independent elements” of ). This is usually denoted by writing [21, 28, 41]. (Although not widelyknown, but LaTeX has a command \parallel for inputting the symbol ). or more precisely as the join (“lub”) of those types whose meet with the type is the bottom type.
As such, noting (see 2.2) that actually denotes type Null (sometimes also called Nothing or Void) and denotes type Object (or All) then the negation of is (since is the only type whose meet with is equal to ), and the negation of is (since the meet of and every type, including , is ).
However, due to the general lack of (true) union types in most OOP languages^{18}^{18}18In fact the lub() function—defined in the Java language specification—does not compute the least upper bound of a set of types (which itself is an approximation of the true union of the set of types) but it ‘only approximates a least upper bound’ [24, 4.10.4]., for most types (i.e., ones other than and ) the negation of a nominal type will usually be type . This makes the negation of class types, if defined as suggested above, not quite interesting or useful. (Also, as observed in 2.2, the subtyping relation in mainstream OOP languages rarely has fixed points of type generators/constructors).
An alternative way to defining the negation of a type in OOP in a more genuine objectoriented way (i.e., not via defining implication/exponential types) is to allow OO developers to choose which types they wish to negate, rather than trying to define a negation “automatically” for every type. An OO developer may define a “negation” of a type (in a genuine OO way, if they wished to have such a negative type) by them simply extending the negative type from a supertype of the negated type (or from one of its supertypes, depending on which part of the inherited behavioral contract is being negated).
For example, say we have class Window that is extended by class ColoredWindow. An OO developer can define the negation of ColoredWindow by declaring a class NonColoredWindow that extends class Window. (As is standard in nominal typing, it is up to the developer to ensure that a NonColoredWindow is indeed not colored, and in fact also that a ColoredWindow is indeed one.)
Negative types, according to this genuine nominal/OO way of defining them, are totally under the control of software developers, unlike the case in structural/FP typing. It may be noted also that type negation in a genuine OO way is not exclusive. For example, generallyspeaking there is nothing that prevents the OO developer from declaring yet a third subclass of class Window that is not a ColoredWindow yet is also not a NonColoredWindow. (That third class may or may not be useful. The option of declaring it, or not, is available to the developer however. In other words, it is the developer, not the language, who makes the decision as to defining the class or not, based on his or her need for the class.)
The more genuinely OO way of defining negative types presented above, arguably, is better than the FP/structural way (via ), since it gives more control and offers more flexibility to developers. It should be noted, though, that there is a similarity between both ways: they both define type negation by depending (directly, in OOP, and indirectly, in FP) on ‘parallel types’ (see Footnote 17).
Having considered negative nominal types, now what about coinductive nominal types? Understanding these types (as counterparts of coinductive structural types in structural type theory and of coinductive sets in set theory) was the initial motivation for us considering type negation in the first place (see 3 of [11]). The starting point for considering such (strangenamed, but familiar we assert) types will be Equation (1) of [11], which, let’s recall, is the equation that defines coinductive sets (in terms of inductive ones and negation) as
Equation (1) uses three negations, and we have just defined an intuitive notion of type negation for nominal types. Our view of coinductive nominal types will be a combination of both. In particular, we take each negation in Equation (1) separately to define a negative nominal type (that may or may not exist). As such, for a particular generic class (i.e., is a nominal type generator) we define its corresponding coinductive nominal type (if it exists) as the negative of (an approximation of, since nominal types do not have fixed points) the inductive type of a “dual” generic class (which, also, may or may not exist) that is applied to negations of types (if all these negations exist) that can be passed to the generic class as type arguments (!!).
Sounds too complex? (Due to the three negations?) Rest assured, in conclusion, and to make a long story short, intuitivelyspeaking the sought after coinductive nominal type is roughly (i.e., is approximated by) the familiar type —an observation we earlier made (in Footnote 14) without any discussion of type negation. In other words, we have
(again due to the absence of fixed points of generic classes in nominal type theory, a true coinductive nominal type in fact never exists). The type is also called the ‘free type’ corresponding to the generic class .^{19}^{19}19The name ‘free type’ comes from category theory. The concept of a free type corresponding to a generic class is similar (in a precise category theoretic sense) to the free monoid corresponding to a set and to the free category (a quiver) corresponding to a graph [44]. The free type corresponding to a generic class is defined as the parameterized type formed by instantiating the generic class with the wildcard type ?. For example, the free type corresponding to generic class List is the type List<?>. Free types and (Java) type erasure both form an adjunction—they are a pair of adjoint functors between ‘classes & subclassing’ and ‘types & subtyping’. (In order theory, an adjunction is also called a Galois connection. See [4] for more details on this adjunction.) Based on the discussion in the main text, free types and coinductive nominal types agree, i.e., are the same concept. More precisely, free types are the best approximation of (true) coinductive nominal types. In categorytheoretic terms free types are, precisely, instances of final coalgebras. (See Table 2 of [8].)
In light of the discussion (in 3 of [11]) of the intuitions behind coinductive sets (“good/constructible/consistent vs. bad/inconstructible/inconsistent”, and finitelyconstructible vs. infinitelyconstructible) and that coinductive sets contain all elements (all data values, in case of coinductive structural data types) that can be constructed using a generator (i.e., ones that do not “break the rules” of the generator/constructor), it is not surprising that, for a generic class , the free type is the best approximation of the coinductive nominal type . That is because the free type is intuitively understood (e.g., by OO software developers and OO language designers) as the type that contains all objects that can be instances of (recall Java’s instanceof operator) the generic class (i.e., contains all objects that can be constructed using the generic class ). Further, in light of OOP not having a goal of inductive logical reasoning (i.e., finite structural reasoning) about objects, it is not surprising that the inductive nominal type is not supported (nor even an approximation for it) in most OOP languages. If defined, such a type or its approximation will contain only objects (in the OO sense, not the mathematical/category theoretic one) that can be finitely constructed using —which is not of much value (actually, makes little sense) to most OO software developers^{20}^{20}20That is, to developers and designers of industrialstrength and mainstream OO software, who are content as long as a type that contains all objects that can be constructed using (regardless of whether they can be constructed “finitely or infinitely”)—namely the free type —is defined..
3.3 Structural Induction, Nominal Coinduction, and The Future
The discussion regarding coinductive nominal types and their approximations, combined with our observation regarding the coinductiveness of the subtyping relation (as a set of pairs) in nominal type systems (see notes of 2.2), make us conclude that fundamental differences exist between structural type theory (in FP) and nominal type theory (in OOP) regarding, first, the existence (in FP) versus nonexistence (in OOP) of fixed points (and pre/postfixed points) of type constructors (in FP) and generic classes (in OOP) and, second, regarding the dominance of (singular) induction and inductive definitions (in FP) versus the dominance of (mutual) coinduction and coinductive definitions (in OOP).
In light of the existence of circularity and recursive definitions in OOP at multiple levels, i.e., at the level of values (e.g., via this) and at the level of types (e.g., between class definitions, and noting the circular dependency of parameterized types on interval types and vice versa), and in light of other work also discussing coinductive definitions and the use of coinduction in OOP and in nominal type systems (e.g., see [39, p.312] and [13, 45]), we observe that:
“Induction reigns supreme” in functional programming, while in objectoriented programming “coinduction reigns supreme”.
This observation should not be viewed as a mathematical or academic statement but rather as an expression of practicallymotivated fundamental features of OOP and FP. The main practical value of functional programming and the main motivation behind its very existence and behind its continued usage is to enable precise mathematical reasoning about software. The main practical value of objectoriented programming and the main motivation behind its existence and behind its continued usage is the accurate and intuitive modeling of typically highlyinterconnected real or imaginary parts of our world. We, humans, know well how to reason, mathematically, about objects built up from few basic ones (i.e., inductivelydefined objects), yet we also need software to accurately simulate and model parts of our interrelated world—one in which, to overcome circularity and interrelatedness, we are used to holding statements about objects as facts as long as these statements cannot be disproven (i.e., is an inherently coinductive world).
As such, the coexistence of FP (with its mainly inductive type systems) and OOP (with its mainly coinductive type systems), and our continued need for both, is a reflection of our reality, i.e., of what we currently know how to do and of what we currently need to do. It is our opinion that this current state of affairs is not a perpetual one, but is one that particularly invites for the further development of the mathematical methods used to reason about mutually coinductive definitions (and, more generally and more precisely, about mutuallydefined postfixed points) to reach or exceed the same level of mathematical maturity of the mathematical methods and tools used to reason about singular inductive definitions (i.e., about least fixed points). In summary, the current state of affairs invites PL theorists and researchers to make clear and transparent what is currently totally opaque,^{21}^{21}21See, for example, the “totally opaque” code on p.58 of [37]—a standard reference on practical functional programming—which nevertheless has a strong objectoriented flavor! thereby elegantly combining the accurate mathematicalreasoning benefits of functional programming with the accurate worldmodeling benefits of objectoriented programming.
References
 [1] Moez A. AbdelGawad. An overview of nominaltyping versus structuraltyping in objectoriented programming (with code examples). Technical report, eprint available at http://arxiv.org/abs/1309.2348, 2013.
 [2] Moez A. AbdelGawad. A domaintheoretic model of nominallytyped objectoriented programming. Electronic Notes in Theoretical Computer Science (Full version preprint available at http://arxiv.org/abs/1801.06793), 301:3–19, 2014.
 [3] Moez A. AbdelGawad. Why nominaltyping matters in OOP. eprint available at http://arxiv.org/abs/1606.03809, 2016.
 [4] Moez A. AbdelGawad. Novel uses of category theory in modeling OOP (extended abstract). Accepted at The Nordic Workshop on Programming Theory (NWPT’17), Turku, Finland (Full version preprint available at http://arxiv.org/abs/1709.08056), 2017.
 [5] Moez A. AbdelGawad. Objectoriented theorem proving (OOTP): First thoughts. eprint available at http://arxiv.org/abs/1712.09958, 2017.
 [6] Moez A. AbdelGawad. Towards a Java subtyping operad. Proceedings of FTfJP’17, Barcelona, Spain (Extended version preprint available at http://arxiv.org/abs/1706.00274), 2017.
 [7] Moez A. AbdelGawad. Doubly Fbounded generics. eprint available at http://arxiv.org/abs/1808.06052, 2018.
 [8] Moez A. AbdelGawad. Induction, coinduction, and fixed points in order theory, set theory, type theory, firstorder logic, and category theory: A concise comparative survey. eprint available at http://arxiv.org/abs/1812.10026, 2018.
 [9] Moez A. AbdelGawad. Java subtyping as an infinite selfsimilar partial graph product. eprint available at http://arxiv.org/abs/1805.06893, 2018.
 [10] Moez A. AbdelGawad. Towards taming Java wildcards and extending Java with interval types. eprint available at http://arxiv.org/abs/1805.10931, 2018.
 [11] Moez A. AbdelGawad. Induction, coinduction, and fixed points: Intuitions and tutorial. eprint available at http://arxiv.org/abs/1902.xxxxxx, 2019.
 [12] Samson Abramsky and Achim Jung. Domain theory. In Dov M. Gabbay S. Abramsky and T. S. E. Maibaum, editors, Handbook for Logic in Computer Science, volume 3. Clarendon Press, 1994.
 [13] Davide Ancona and Giovanni Lagorio. Coinductive type systems for objectoriented languages. In Sophia Drossopoulou, editor, ECOOP, 2009.
 [14] Paolo Baldan, Giorgio Ghelli, and Alessandra Raffaeta. Basic theory of Fbounded polymorphism. Information and Computation, 153(1):173–237, 1999.
 [15] Yves Bertot and Pierre Casteran. Interactive Theorem Proving and Program Development Coq’Art: The Calculus of Inductive Constructions. Springer, 2004.
 [16] M. Brandt and F. Henglein. Coinductive axiomatization of recursive type equality and subtyping. Fundamenta Informaticae, 33(4):309–338, 1998.
 [17] Kim Bruce, Luca Cardelli, Giuseppe Castagna, The Hopkins Objects Group, Gary Leavens, and Benjamin C. Pierce. On binary methods. Theory and Practice of Object Systems, 1994.
 [18] Peter S. Canning, William R. Cook, Walter L. Hill, J. Mitchell, and W. Olthoff. Fbounded polymorphism for objectoriented programming. In Proc. of Conf. on Functional Programming Languages and Computer Architecture, 1989.
 [19] Robert Cartwright, Rebecca Parsons, and Moez A. AbdelGawad. Domain Theory: An Introduction. eprint available at http://arxiv.org/abs/1605.05858, 2016.
 [20] William R. Cook. On understanding data abstraction, revisited. volume 44, pages 557–572. ACM, 2009.
 [21] B. A. Davey and H. A. Priestley. Introduction to Lattices and Order. Cambridge University Press, 2nd edition, 2002.
 [22] Vladimir Gapeyev, Michael Y. Levin, and Benjamin C. Pierce. Recursive subtyping revealed. Journal of Functional Programming, 2002.
 [23] G. Gierz, K. H. Hofmann, K. Keimel, J. D. Lawson, M. W. Mislove, and D. S. Scott. Continuous Lattices and Domains, volume 93 of Encyclopedia Of Mathematics And Its Applications. Cambridge University Press, 2003.
 [24] James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Alex Buckley, and Daniel Smith. The Java Language Specification. AddisonWesley, 2018.
 [25] Ben Greenman, Fabian Muehlboeck, and Ross Tate. Getting Fbounded polymorphism into shape. In PLDI ’14: Proceedings of the 2014 ACM SIGPLAN conference on Programming Language Design and Implementation, 2014.
 [26] John Greiner. Programming with inductive and coinductive types. Technical Report CMUCS92109, School of Computer Science, Carnegie Mellon University, Jan 1992.
 [27] C. A. Gunter and Dana S. Scott. Handbook of Theoretical Computer Science, volume B, chapter 12 (Semantic Domains). 1990.
 [28] Egbert Harzheim. Ordered Sets. Springer, 2005.
 [29] John Hughes. Why functional programming matters. Computer Journal, 32(2), 1989.
 [30] Gilles Kahn and Gordon D. Plotkin. Concrete domains, May 1993.

[31]
Andrew J. Kennedy and Benjamin C. Pierce.
On decidability of nominal subtyping with variance.
In International Workshop on Foundations and Developments of ObjectOriented Languages (FOOL/WOOD), 2007.  [32] Dexter Kozen and Alexandra Silva. Practical coinduction. Mathematical Structures in Computer Science, 27(7):1132–1152, 2016.
 [33] David B. MacQueen. Should ML be objectoriented? Formal Aspects of Computing, 13:214–232, 2002.
 [34] David B. MacQueen, Gordon D. Plotkin, and R. Sethi. An ideal model for recursive polymorphic types. Information and Control, 71:95–130, 1986.
 [35] Andrew McLennan. Advanced Fixed Point Theory for Economics. Springer, 2018.
 [36] Martin Odersky. The Scala language specification, v. 2.9. http://www.scalalang.org, 2014.
 [37] Lawrence C. Paulson. ML for the Working Programmer. Cambridge University Press, 1996.
 [38] Roger Penrose. The Road to Reality: A Complete Guide to the Laws of the Universe. Jonathan Cape, 2004.
 [39] Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002.
 [40] Gordon D. Plotkin. Domains. Lecture notes in advanced domain theory, 1983.
 [41] Steven Roman. Lattices and Ordered Sets. Springer, 2008.
 [42] Davide Sangiorgi. Introduction to Bisimulation and Coinduction. 2012.
 [43] Dana S. Scott. Domains for denotational semantics. Technical report, Computer Science Department, Carnegie Mellon University, 1983.
 [44] David Spivak. Category theory for the sciences. MIT Press, 2014.
 [45] Ross Tate, Alan Leung, and Sorin Lerner. Taming wildcards in Java’s type system. PLDI’11, June 4–8, 2011, San Jose, California, USA., 2011.
 [46] Ewan Tempero, Hong Yul Yang, and James Noble. What programmers do with inheritance in Java. In Proceedings of the 27th European Conference on ObjectOriented Programming, ECOOP’13, pages 577–601, Berlin, Heidelberg, 2013. SpringerVerlag.
 [47] Rik van Geldrop and Jaap van der Woude. Inductive sets, the algebraic way, 2009.