|
| 1 | +--- |
| 2 | +layout: doc-page |
| 3 | +title: "Type Lambdas - More Details" |
| 4 | +--- |
| 5 | + |
| 6 | +## Syntax |
| 7 | + |
| 8 | +``` |
| 9 | +Type ::= ... | HkTypeParamClause ‘=>’ Type |
| 10 | +HkTypeParamClause ::= ‘[’ HkTypeParam {‘,’ HkTypeParam} ‘]’ |
| 11 | +HkTypeParam ::= {Annotation} [‘+’ | ‘-’] (Id[HkTypeParamClause] | ‘_’) TypeBounds |
| 12 | +TypeBounds ::= [‘>:’ Type] [‘<:’ Type] |
| 13 | +``` |
| 14 | + |
| 15 | +### Type Checking |
| 16 | + |
| 17 | +A type lambda such `[X] => F[X]` defines a function from types to types. The parameter(s) may carry bounds and variance annotations. |
| 18 | +If a parameter is is bounded, as in `[X >: L <: H] => F[X]` it is checked that arguments to the parameters conform to the bounds `L` and `H`. |
| 19 | +Only the upper bound `H` can be F-bounded, i.e. `X` can appear in it. |
| 20 | + |
| 21 | +A variance annotation on a parameter indicates a subtyping relationship on type instances. For instance, given |
| 22 | +```scala |
| 23 | +type TL1 = [+A] => F[A] |
| 24 | +type TL2 = [-A] => F[A] |
| 25 | +``` |
| 26 | +and two types `S <: T`, we have |
| 27 | +```scala |
| 28 | +TL1[S] <: TL1[T] |
| 29 | +TL2[T] <: TL2[S] |
| 30 | +``` |
| 31 | +It is checked that variance annotations on parameters of type lambdas are respected by the parameter occurrences on the type lambda's body. |
| 32 | + |
| 33 | +**Note** No requirements hold for the variances of occurrences of type variables in their bounds. It is an open question whether we need to impose additional requirements here |
| 34 | +(`scalac` doesn't check variances in bounds either). |
| 35 | + |
| 36 | +## Subtyping Rules |
| 37 | + |
| 38 | +Assume two type lambdas |
| 39 | +```scala |
| 40 | +type TL1 = [v1 X >: L1 <: U1] => R1 |
| 41 | +type TL2 = [v2 X >: L2 <: U2] => R2 |
| 42 | +``` |
| 43 | +where `v1` and `v2` are optional variance annotations: `+`, `-`, or absent. |
| 44 | +Then `TL1 <: TL2`, if |
| 45 | + |
| 46 | + - the type interval `L2..U2` is contained in the type interval `L1..U1` (i.e. |
| 47 | +`L1 <: L2` and `U2 <: U1`), |
| 48 | + - either `v2` is absent or `v1 = v2` |
| 49 | + - `R1 <: R2` |
| 50 | + |
| 51 | +Here we have relied on alpha renaming to bring match the two bound types `X`. |
| 52 | + |
| 53 | +A partially applied type constructor such as `List` is assumed to be equivalent to |
| 54 | +its eta expansion. I.e, `List = [+X] => List[X]`. This allows type constructors |
| 55 | +to be compared with type lambdas. |
| 56 | + |
| 57 | +## Relationship with Parameterized Type Definitions |
| 58 | + |
| 59 | +A parameterized type definition |
| 60 | +```scala |
| 61 | +type T[X] = R |
| 62 | +``` |
| 63 | +is regarded as a shorthand for an unparameterized definition with a type lambda as right-hand side: |
| 64 | +```scala |
| 65 | +type T = [X] => R |
| 66 | +``` |
| 67 | + |
| 68 | +A parameterized abstract type |
| 69 | +```scala |
| 70 | +type T[X] >: L <: U |
| 71 | +``` |
| 72 | +is regarded as shorthand for an unparameterized abstract type with type lambdas as bounds. |
| 73 | +```scala |
| 74 | +type T >: ([X] => L) <: ([X] => U) |
| 75 | +``` |
| 76 | +However, if `L` is `Nothing` it is not parameterized, since `Nothing` is treated as a bottom type for all kinds. For instance, |
| 77 | +```scala |
| 78 | +type T[-X] <: X => () |
| 79 | +``` |
| 80 | +is expanded to |
| 81 | +```scala |
| 82 | +type T >: Nothing <: ([-X] => X => ()) |
| 83 | +``` |
| 84 | +instead of |
| 85 | +```scala |
| 86 | +type T >: ([X] => Nothing) <: ([-X] => X => ()) |
| 87 | +``` |
| 88 | + |
| 89 | +The same expansions apply to type parameters. E.g. |
| 90 | +```scala |
| 91 | +[F[X] <: Coll[X]] |
| 92 | +``` |
| 93 | +is treated as a shorthand for |
| 94 | +```scala |
| 95 | +[F >: Nothing <: [X] => Coll[X]] |
| 96 | +``` |
| 97 | + |
| 98 | +**Note**: The decision to treat `Nothing` as universal bottom type is provisional, and might be changed afer further discussion. |
| 99 | + |
| 100 | +**Note**: Scala 2 and 3 differ in that Scala 2 also treats `Any` as universal top-type. This is not done in Scala 3. See also the discussion on [kind polymorphism](./kind-polymorphism.html) |
| 101 | + |
| 102 | +## Curried Type Parameters |
| 103 | + |
| 104 | +The body of a type lambda can again be a type lambda. Example: |
| 105 | +```scala |
| 106 | +type TL = [X] => [Y] => (X, Y) |
| 107 | +``` |
| 108 | +Currently, no special provision is made to infer type arguments to such curried type lambdas. This is left for future work. |
| 109 | + |
| 110 | + |
| 111 | + |
0 commit comments