intersection type

TypeScript supports intersection types, improving expressiveness of the type system and reducing potential class hierarchy size, demonstrated as follows.

The following program code defines the classes {{TS-lang|Chicken}}, {{TS-lang|Cow}}, and {{TS-lang|RandomNumberGenerator}} that each have a method {{TS-lang|produce}} returning an object of either type {{TS-lang|Egg}}, {{TS-lang|Milk}}, or {{TS-lang|number}}.

Additionally, the functions {{TS-lang|eatEgg}} and {{TS-lang|drinkMilk}} require arguments of type {{TS-lang|Egg}} and {{TS-lang|Milk}}, respectively.

class Egg { private kind: "Egg" }

class Milk { private kind: "Milk" }

// produces eggs

class Chicken { produce() { return new Egg(); } }

// produces milk

class Cow { produce() { return new Milk(); } }

// produces a random number

class RandomNumberGenerator { produce() { return Math.random(); } }

// requires an egg

function eatEgg(egg: Egg) {

return "I ate an egg.";

}

// requires milk

function drinkMilk(milk: Milk) {

return "I drank some milk.";

}

The following program code defines the ad hoc polymorphic function {{TS-lang|animalToFood}} that invokes the member function {{TS-lang|produce}} of the given object {{TS-lang|animal}}.

The function {{TS-lang|animalToFood}} has two type annotations, namely {{TS-lang|1=((_: Chicken) => Egg)}} and {{TS-lang|1=((_: Cow) => Milk)}}, connected via the intersection type constructor {{TS-lang|1=&}}.

Specifically, {{TS-lang|animalToFood}} when applied to an argument of type {{TS-lang|Chicken}} returns an object of type {{TS-lang|Egg}}, and when applied to an argument of type {{TS-lang|Cow}} returns an object of type {{TS-lang|Milk}}.

Ideally, {{TS-lang|animalToFood}} should not be applicable to any object having (possibly by chance) a {{TS-lang|produce}} method.

// given a chicken, produces an egg; given a cow, produces milk

let animalToFood: ((_: Chicken) => Egg) & ((_: Cow) => Milk) =

function (animal: any) {

return animal.produce();

};

Finally, the following program code demonstrates type safe use of the above definitions.

var chicken = new Chicken();

var cow = new Cow();

var randomNumberGenerator = new RandomNumberGenerator();

console.log(chicken.produce()); // Egg { }

console.log(cow.produce()); // Milk { }

console.log(randomNumberGenerator.produce()); //0.2626353555444987

console.log(animalToFood(chicken)); // Egg { }

console.log(animalToFood(cow)); // Milk { }

//console.log(animalToFood(randomNumberGenerator)); // ERROR: Argument of type 'RandomNumberGenerator' is not assignable to parameter of type 'Cow'

console.log(eatEgg(animalToFood(chicken))); // I ate an egg.

//console.log(eatEgg(animalToFood(cow))); // ERROR: Argument of type 'Milk' is not assignable to parameter of type 'Egg'

console.log(drinkMilk(animalToFood(cow))); // I drank some milk.

//console.log(drinkMilk(animalToFood(chicken))); // ERROR: Argument of type 'Egg' is not assignable to parameter of type 'Milk'

The above program code has the following properties:

• Lines 1–3 create objects {{TS-lang|chicken}}, {{TS-lang|cow}}, and {{TS-lang|randomNumberGenerator}} of their respective type.
• Lines 5–7 print for the previously created objects the respective results (provided as comments) when invoking {{TS-lang|produce}}.
• Line 9 (resp. 10) demonstrates type safe use of the method {{TS-lang|animalToFood}} applied to {{TS-lang|chicken}} (resp. {{TS-lang|cow}}).
• Line 11, if uncommented, would result in a type error at compile time. Although the implementation of {{TS-lang|animalToFood}} could invoke the {{TS-lang|produce}} method of {{TS-lang|randomNumberGenerator}}, the type annotation of {{TS-lang|animalToFood}} disallows it. This is in accordance with the intended meaning of {{TS-lang|animalToFood}}.
• Line 13 (resp. 15) demonstrates that applying {{TS-lang|animalToFood}} to {{TS-lang|chicken}} (resp. {{TS-lang|cow}}) results in an object of type {{TS-lang|Egg}} (resp. {{TS-lang|Milk}}).
• Line 14 (resp. 16) demonstrates that applying {{TS-lang|animalToFood}} to {{TS-lang|cow}} (resp. {{TS-lang|chicken}}) does not result in an object of type {{TS-lang|Egg}} (resp. {{TS-lang|Milk}}). Therefore, if uncommented, line 14 (resp. 16) would result in a type error at compile time.

The above minimalist example can be realized using inheritance, for instance by deriving the classes {{TS-lang|Chicken}} and {{TS-lang|Cow}} from a base class {{TS-lang|Animal}}.

However, in a larger setting, this could be disadvantageous.

Introducing new classes into a class hierarchy is not necessarily justified for cross-cutting concerns, or maybe outright impossible, for example when using an external library.

Imaginably, the above example could be extended with the following classes:

• a class {{TS-lang|Horse}} that does not have a {{TS-lang|produce}} method;
• a class {{TS-lang|Sheep}} that has a {{TS-lang|produce}} method returning {{TS-lang|Wool}};
• a class {{TS-lang|Pig}} that has a {{TS-lang|produce}} method, which can be used only once, returning {{TS-lang|Meat}}.

This may require additional classes (or interfaces) specifying whether a produce method is available, whether the produce method returns food, and whether the produce method can be used repeatedly.

Overall, this may pollute the class hierarchy.

The above minimalist example already shows that duck typing is less suited to realize the given scenario.

While the class {{TS-lang|RandomNumberGenerator}} contains a {{TS-lang|produce}} method, the object {{TS-lang|randomNumberGenerator}} should not be a valid argument for {{TS-lang|animalToFood}}.

The above example can be realized using duck typing, for instance by introducing a new field {{TS-lang|argumentForAnimalToFood}} to the classes {{TS-lang|Chicken}} and {{TS-lang|Cow}} signifying that objects of corresponding type are valid arguments for {{TS-lang|animalToFood}}.

However, this would not only increase the size of the respective classes (especially with the introduction of more methods similar to {{TS-lang|animalToFood}}), but is also a non-local approach with respect to {{TS-lang|animalToFood}}.

The above example can be realized using function overloading, for instance by implementing two methods {{TS-lang|animalToFood(animal: Chicken): Egg}} and {{TS-lang|animalToFood(animal: Cow): Milk}}.

In TypeScript, such a solution is almost identical to the provided example.

Other programming languages, such as Java, require distinct implementations of the overloaded method.

This may lead to either code duplication or boilerplate code.

The above example can be realized using the visitor pattern.

It would require each animal class to implement an {{TS-lang|accept}} method accepting an object implementing the interface {{TS-lang|AnimalVisitor}} (adding non-local boilerplate code).

The function {{TS-lang|animalToFood}} would be realized as the {{TS-lang|visit}} method of an implementation of {{TS-lang|AnimalVisitor}}.

Unfortunately, the connection between the input type ({{TS-lang|Chicken}} or {{TS-lang|Cow}}) and the result type ({{TS-lang|Egg}} or {{TS-lang|Milk}}) would be difficult to represent.

On the one hand, intersection types can be used to locally annotate different types to a function without introducing new classes (or interfaces) to the class hierarchy.

On the other hand, this approach requires all possible argument types and result types to be specified explicitly.

If the behavior of a function can be specified precisely by either a unified interface, parametric polymorphism, or duck typing, then the verbose nature of intersection types is unfavorable.

Therefore, intersection types should be considered complementary to existing specification methods.

A dependent intersection type, denoted $(x\; :\; \backslash sigma)\; \backslash cap\; \backslash tau$, is a dependent type in which the type $\backslash tau$ may depend on the term variable $x$.{{cite conference |title=Dependent intersection: A new way of defining records in type theory |last1=Kopylov |first1=Alexei |year=2003 |publisher=IEEE Computer Society |book-title=18th IEEE Symposium on Logic in Computer Science |pages=86–95 |conference=LICS 2003 |doi=10.1109/LICS.2003.1210048 |citeseerx=10.1.1.89.4223 }}

In particular, if a term $M$ has the dependent intersection type $(x\; :\; \backslash sigma)\; \backslash cap\; \backslash tau$, then the term $M$ has both the type $\backslash sigma$ and the type $\backslash tau[x\; :=\; M]$, where $\backslash tau[x\; :=\; M]$ is the type which results from replacing all occurrences of the term variable $x$ in $\backslash tau$ by the term $M$.

Scala supports type declarations {{cite web |url=https://www.scala-lang.org/files/archive/spec/2.12/04-basic-declarations-and-definitions.html#type-declarations-and-type-aliases |title=Type declarations in Scala |access-date=2019-08-15}} as object members. This allows a type of an object member to depend on the value of another member, which is called a path-dependent type.

{{cite book |last1=Amin |first1=Nada |last2=Grütter |first2=Samuel |last3=Odersky |first3=Martin |last4=Rompf |first4=Tiark |last5=Stucki |first5=Sandro |title=A List of Successes That Can Change the World |chapter=The Essence of Dependent Object Types |series=Lecture Notes in Computer Science |volume=9600 |pages=249–272 |year=2016 |publisher=Springer |doi=10.1007/978-3-319-30936-1_14 |isbn=978-3-319-30935-4 |url=https://infoscience.epfl.ch/record/215280/files/paper_1.pdf }}

For example, the following program text defines a Scala trait Witness, which can be used to implement the singleton pattern.{{cite web |url=https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/singletons.scala |title=Singletons in the Scala shapeless library |website=GitHub |access-date=2019-08-15}}

trait Witness {

type T

val value: T {}

}

The above trait Witness declares the member T, which can be assigned a type as its value, and the member value, which can be assigned a value of type T.

The following program text defines an object booleanWitness as instance of the above trait Witness .

The object booleanWitness defines the type T as Boolean and the value value as true.

For example, executing System.out.println(booleanWitness.value) prints true on the console.

object booleanWitness extends Witness {

type T = Boolean

val value = true

}

Let $\backslash langle\; \backslash textsf\{x\}\; :\; \backslash sigma\; \backslash rangle$ be the type (specifically, a record type) of objects having the member $\backslash textsf\{x\}$ of type $\backslash sigma$.

In the above example, the object booleanWitness can be assigned the dependent intersection type $(x\; :\; \backslash langle\; \backslash textsf\{T\}\; :\; \backslash text\{Type\}\; \backslash rangle)\; \backslash cap\; \backslash langle\; \backslash textsf\{value\}\; :\; x.\backslash textsf\{T\}\; \backslash rangle$.

The reasoning is as follows. The object booleanWitness has the member T that is assigned the type Boolean as its value.

Since Boolean is a type, the object booleanWitness has the type $\backslash langle\; \backslash textsf\{T\}\; :\; \backslash text\{Type\}\; \backslash rangle$.

Additionally, the object booleanWitness has the member value that is assigned the value true of type Boolean.

Since the value of booleanWitness.T is Boolean, the object booleanWitness has the type $\backslash langle\; \backslash textsf\{value\}\; :\; \backslash textsf\{booleanWitness.T\}\; \backslash rangle$.

Overall, the object booleanWitness has the intersection type $\backslash langle\; \backslash textsf\{T\}\; :\; \backslash text\{Type\}\; \backslash rangle\; \backslash cap\; \backslash langle\; \backslash textsf\{value\}\; :\; \backslash textsf\{booleanWitness.T\}\; \backslash rangle$.

Therefore, presenting self-reference as dependency, the object booleanWitness has the dependent intersection type $(x\; :\; \backslash langle\; \backslash textsf\{T\}\; :\; \backslash text\{Type\}\; \backslash rangle)\; \backslash cap\; \backslash langle\; \backslash textsf\{value\}\; :\; x.\backslash textsf\{T\}\; \backslash rangle$.

Alternatively, the above minimalistic example can be described using dependent record types.{{cite conference |title=Dependently typed records for representing mathematical structure |last1=Pollack |first1=Robert |publisher=Springer |book-title=Theorem Proving in Higher Order Logics, 13th International Conference |pages=462–479 |conference=TPHOLs 2000 |year=2000 |doi=10.1007/3-540-44659-1_29 }}

In comparison to dependent intersection types, dependent record types constitute a strictly more specialized type theoretic concept.

An intersection of a type family, denoted $\backslash bigcap\_\{x\; :\; \backslash sigma\}\; \backslash tau$, is a dependent type in which the type $\backslash tau$ may depend on the term variable $x$. In particular, if a term $M$ has the type $\backslash bigcap\_\{x\; :\; \backslash sigma\}\; \backslash tau$, then for each term $N$ of type $\backslash sigma$, the term $M$ has the type $\backslash tau[x\; :=\; N]$. This notion is also called implicit Pi type,{{cite journal |last1=Stump |first1=Aaron |year=2018 |title=From realizability to induction via dependent intersection |journal=Annals of Pure and Applied Logic |volume=169 |issue=7 |pages=637–655 |doi=10.1016/j.apal.2018.03.002 |doi-access=free }} observing that the argument $N$ is not kept at term level.

{{RefList}}

{{Data types}}

Category:Type theory

Category:Type systems

Category:Data types

Category:Composite data types

Category:Polymorphism (computer science)

Category:TypeScript