You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this specification, we specify and use types in terms of the following _abstract syntax_.
10
-
The abstract syntax does not directly correspond to concrete syntax.
11
-
It abstracts away irrelevant details such as precedence and grouping, and contains shapes of types that cannot be directly expressed using the concrete syntax.
The above grammer describes the concrete syntax of types that can be written in user code.
65
+
Semantic operations on types in the Scala type system are better defined in terms of _internal types_, which are desugared from the concrete type syntax.
66
+
67
+
## Internal Types
68
+
69
+
The following _abstract grammar_ defines the shape of _internal types_.
70
+
In this specification, unless otherwise noted, "types" refer to internal types.
71
+
Internal types abstract away irrelevant details such as precedence and grouping, and contain shapes of types that cannot be directly expressed using the concrete syntax.
72
+
They also contain simplified, decomposed shapes for complex concrete syntax types, such as refined types.
12
73
13
74
```ebnf
14
75
Type ::= ‘AnyKind‘
@@ -84,8 +145,90 @@ TypeAlias ::= ‘=‘ Type
84
145
TypeBounds ::= ‘<:‘ Type ‘>:‘ Type
85
146
```
86
147
148
+
### Translation of Concrete Types into Internal Types
149
+
150
+
Concrete types are recursively translated, or desugared, into internal types.
151
+
Most shapes of concrete types have a one-to-one translation to shapes of internal types.
152
+
We elaborate hereafter on the translation of the other ones.
153
+
154
+
### Infix Types
155
+
156
+
```ebnf
157
+
InfixType ::= CompoundType {id [nl] CompoundType}
158
+
```
159
+
160
+
A concrete _infix type_ ´T_1´ `op` ´T_2´ consists of an infix operator `op` which gets applied to two type operands ´T_1´ and ´T_2´.
161
+
The type is translated to the internal type application `op`´[T_1, T_2]´.
162
+
The infix operator `op` may be an arbitrary identifier.
163
+
164
+
Type operators follow the same [precedence and associativity as term operators](06-expressions.html#prefix-infix-and-postfix-operations).
165
+
For example, `A + B * C` parses as `A + (B * C)` and `A | B & C` parses as `A | (B & C)`.
166
+
Type operators ending in a colon ‘:’ are right-associative; all other operators are left-associative.
167
+
168
+
In a sequence of consecutive type infix operations ´t_0 \, \mathit{op} \, t_1 \, \mathit{op_2} \, ... \, \mathit{op_n} \, t_n´, all operators ´\mathit{op}\_1, ..., \mathit{op}\_n´ must have the same associativity.
169
+
If they are all left-associative, the sequence is interpreted as ´(... (t_0 \mathit{op_1} t_1) \mathit{op_2} ...) \mathit{op_n} t_n´, otherwise it is interpreted as ´t_0 \mathit{op_1} (t_1 \mathit{op_2} ( ... \mathit{op_n} t_n) ...)´.
170
+
171
+
The type operators `|` and `&` are not really special.
172
+
Nevertheless, unless shadowed, they resolve to `scala.|` and `scala.&`, which represent [union and intersection types](#union-and-intersection-types), respectively.
173
+
174
+
### Function Types
175
+
176
+
```ebnf
177
+
Type ::= FunctionArgTypes ‘=>’ Type
178
+
FunctionArgTypes ::= InfixType
179
+
| ‘(’ [ ParamType {‘,’ ParamType } ] ‘)’
180
+
```
181
+
182
+
The concrete type ´(T_1, ..., T_n) \Rightarrow R´ represents the set of function values that take arguments of types ´T_1, ..., Tn´ and yield results of type ´R´.
183
+
The case of exactly one argument type ´T \Rightarrow R´ is a shorthand for ´(T) \Rightarrow R´.
184
+
An argument type of the form ´\Rightarrow T´ represents a [call-by-name parameter](04-basic-declarations-and-definitions.md#by-name-parameters) of type ´T´.
185
+
186
+
Function types associate to the right, e.g. ´S \Rightarrow T \Rightarrow R´ is the same as ´S \Rightarrow (T \Rightarrow R)´.
187
+
188
+
Function types are [covariant](04-basic-declarations-and-definitions.md#variance-annotations) in their result type and [contravariant](04-basic-declarations-and-definitions.md#variance-annotations) in their argument types.
189
+
190
+
Function types translate into internal class types that define an `apply` method.
191
+
Specifically, the ´n´-ary function type ´(T_1, ..., T_n) \Rightarrow R´ translates to the internal class type `scala.Function´_n´[´T_1´, ..., ´T_n´, ´R´]`.
192
+
In particular ´() \Rightarrow R´ is a shorthand for class type `scala.Function´_0´[´R´]`.
193
+
194
+
Such class types behave as if they were instances of the following trait:
195
+
196
+
```scala
197
+
traitFunction´_n´[-´T_1´, ..., -´T_n´, +´R´]:
198
+
defapply(´x_1´: ´T_1´, ..., ´x_n´: ´T_n´): ´R´
199
+
```
200
+
201
+
Their exact supertype and implementation can be consulted in the [function classes section](./12-the-scala-standard-library.md#the-function-classes) of the standard library page in this document.
Most types in the concrete syntax translate one to one to types in the abstract syntax.
1109
-
We elaborate hereafter on the translation of the other ones.
1110
-
1111
-
### Infix Types
1112
-
1113
-
```ebnf
1114
-
InfixType ::= CompoundType {id [nl] CompoundType}
1115
-
```
1116
-
1117
-
An _infix type_ ´T_1´ `op` ´T_2´ consists of an infix operator `op` which gets applied to two type operands ´T_1´ and ´T_2´.
1118
-
The type is equivalent to the type application `op`´[T_1, T_2]´.
1119
-
The infix operator `op` may be an arbitrary identifier.
1120
-
1121
-
Type operators follow the same [precedence and associativity as term operators](06-expressions.html#prefix-infix-and-postfix-operations).
1122
-
For example, `A + B * C` parses as `A + (B * C)` and `A | B & C` parses as `A | (B & C)`.
1123
-
Type operators ending in a colon ‘:’ are right-associative; all other operators are left-associative.
1124
-
1125
-
In a sequence of consecutive type infix operations ´t_0 \, \mathit{op} \, t_1 \, \mathit{op_2} \, ... \, \mathit{op_n} \, t_n´, all operators ´\mathit{op}\_1, ..., \mathit{op}\_n´ must have the same associativity.
1126
-
If they are all left-associative, the sequence is interpreted as ´(... (t_0 \mathit{op_1} t_1) \mathit{op_2} ...) \mathit{op_n} t_n´, otherwise it is interpreted as ´t_0 \mathit{op_1} (t_1 \mathit{op_2} ( ... \mathit{op_n} t_n) ...)´.
1127
-
1128
-
The type operators `|` and `&` are not really special.
1129
-
Nevertheless, unless shadowed, they resolve to `scala.|` and `scala.&`, which represent [union and intersection types](#union-and-intersection-types), respectively.
1130
-
1131
-
### Function Types
1132
-
1133
-
```ebnf
1134
-
Type ::= FunctionArgTypes ‘=>’ Type
1135
-
FunctionArgTypes ::= InfixType
1136
-
| ‘(’ [ ParamType {‘,’ ParamType } ] ‘)’
1137
-
```
1138
-
1139
-
The type ´(T_1, ..., T_n) \Rightarrow R´ represents the set of function values that take arguments of types ´T_1, ..., Tn´ and yield results of type ´R´.
1140
-
The case of exactly one argument type ´T \Rightarrow R´ is a shorthand for ´(T) \Rightarrow R´.
1141
-
An argument type of the form ´\Rightarrow T´ represents a [call-by-name parameter](04-basic-declarations-and-definitions.md#by-name-parameters) of type ´T´.
1142
-
1143
-
Function types associate to the right, e.g. ´S \Rightarrow T \Rightarrow R´ is the same as ´S \Rightarrow (T \Rightarrow R)´.
1144
-
1145
-
Function types are [covariant](04-basic-declarations-and-definitions.md#variance-annotations) in their result type and [contravariant](04-basic-declarations-and-definitions.md#variance-annotations) in their argument types.
1146
-
1147
-
Function types are shorthands for class types that define an `apply` method.
1148
-
Specifically, the ´n´-ary function type ´(T_1, ..., T_n) \Rightarrow R´ is a shorthand for the class type `Function´_n´[´T_1´, ..., ´T_n´, ´R´]`.
1149
-
In particular ´() \Rightarrow R´ is a shorthand for class type `Function´_0´[´R´]`.
1150
-
1151
-
Such class types behave as if they were instances of the following trait:
1152
-
1153
-
```scala
1154
-
traitFunction´_n´[-´T_1´, ..., -´T_n´, +´R´]:
1155
-
defapply(´x_1´: ´T_1´, ..., ´x_n´: ´T_n´): ´R´
1156
-
```
1157
-
1158
-
Their exact supertype and implementation can be consulted in the [function classes section](./12-the-scala-standard-library.md#the-function-classes) of the standard library page in this document.
In the concrete syntax of types, refinements can contain several refined declarations.
1174
-
Moreover, the refined declarations can refer to each other as well as to members of the parent type, i.e., they have access to `this`.
1175
-
1176
-
In the abstract syntax of types, each refinement defines exactly one refined declaration, and references to `this` must be made explicit in a recursive type.
1177
-
1178
-
The conversion from the concrete syntax to the abstract syntax works as follows:
1179
-
1180
-
1. Create a fresh recursive this name ´\alpha´.
1181
-
2. Replace every implicit or explicit reference to `this` in the refinement declarations by ´\alpha´.
1182
-
3. Create nested [refined types](#refined-types), one for every refined declaration.
1183
-
4. Unless ´\alpha´ was never actually used, wrap the result in a [recursive type](#recursive-types)`{ ´\alpha´ => ´...´ }`.
0 commit comments