diff --git a/scripts/generate-spec-pdf.bat b/scripts/generate-spec-pdf.bat index 57236f963e2c..67ce5525dc71 100644 --- a/scripts/generate-spec-pdf.bat +++ b/scripts/generate-spec-pdf.bat @@ -10,7 +10,7 @@ SET ROOT_DIR=%THIS_SCRIPT_DIR%.. SET SPEC_SRC_DIR=%ROOT_DIR%\spec SET SPEC_BUILD_DIR=%ROOT_DIR%\build\spec -SET WKHTML_OPTS=--print-media-type --window-status loaded --footer-center [page] --javascript-delay 1000 +SET WKHTML_OPTS=--print-media-type --window-status loaded --footer-center [page] --javascript-delay 1000 --footer-font-name "Luxi Sans" SET WKHTML_TOC=toc --xsl-style-sheet %SPEC_SRC_DIR%\spec-toc.xslt SET HTML_FILES= @@ -20,7 +20,5 @@ FOR /F "tokens=*" %%a IN ('dir %SPEC_BUILD_DIR%\*.html /B /O:N ^| findstr /v /i ECHO Making Spec.pdf with HTML files: ECHO %SPEC_BUILD_DIR%\index.html %HTML_FILES% -echo wkhtmltopdf %WKHTML_OPTS% %SPEC_BUILD_DIR%\index.html %WKHTML_TOC% %HTML_FILES% %SPEC_BUILD_DIR%\Spec.pdf - REM first goes index.html, then TOC, then rest wkhtmltopdf %WKHTML_OPTS% %SPEC_BUILD_DIR%\index.html %WKHTML_TOC% %HTML_FILES% %SPEC_BUILD_DIR%\Spec.pdf diff --git a/scripts/generate-spec-pdf.sh b/scripts/generate-spec-pdf.sh index 34b14770b6c7..38f94ac1b24f 100644 --- a/scripts/generate-spec-pdf.sh +++ b/scripts/generate-spec-pdf.sh @@ -4,11 +4,12 @@ # "toc" -> treated just like another page, its location can be changed # "--window-status loaded" -> when window.status is set to "loaded", wkhtmltopdf knows js is loaded -ROOT_DIR=.. +THIS_SCRIPT_DIR=$(dirname $0) +ROOT_DIR=$THIS_SCRIPT_DIR/.. SPEC_SRC_DIR=$ROOT_DIR/spec SPEC_BUILD_DIR=$ROOT_DIR/build/spec -WKHTML_OPTS="--print-media-type --window-status loaded --footer-center [page]" +WKHTML_OPTS='--print-media-type --window-status loaded --footer-center [page] --javascript-delay 1000 --footer-font-name "Luxi Sans"' WKHTML_TOC="toc --xsl-style-sheet $SPEC_SRC_DIR/spec-toc.xslt" # exclude index.html, prepend SPEC_BUILD_DIR path diff --git a/spec/01-lexical-syntax.md b/spec/01-lexical-syntax.md index 057dace4f981..e240ef372ffa 100644 --- a/spec/01-lexical-syntax.md +++ b/spec/01-lexical-syntax.md @@ -93,8 +93,8 @@ Some examples of constant identifiers are > ⅰ_ⅲ Ⅰ_Ⅲ ↁelerious ǃqhàà ʹthatsaletter > ``` -The ‘\$’ character is reserved for compiler-synthesized identifiers. -User programs should not define identifiers that contain ‘\$’ characters. +The ‘$’ character is reserved for compiler-synthesized identifiers. +User programs should not define identifiers that contain ‘$’ characters. The following names are reserved words instead of being members of the syntactic class `id` of lexical identifiers. @@ -111,7 +111,7 @@ val var while with yield _ : = => <- <: <% >: # @ ``` -The Unicode operators `\u21D2` ‘$\Rightarrow$’ and `\u2190` ‘$\leftarrow$’, which have the ASCII +The Unicode operators `\u21D2` ‘´\Rightarrow´’ and `\u2190` ‘´\leftarrow´’, which have the ASCII equivalents `=>` and `<-`, are also reserved. > Here are examples of identifiers: @@ -357,9 +357,9 @@ is _pt_. The numeric ranges given by these types are: | | | |----------------|--------------------------| -|`Byte` | $-2\^7$ to $2\^7-1$ | -|`Short` | $-2\^{15}$ to $2\^{15}-1$| -|`Char` | $0$ to $2\^{16}-1$ | +|`Byte` | ´-2\^7´ to ´2\^7-1´ | +|`Short` | ´-2\^{15}´ to ´2\^{15}-1´| +|`Char` | ´0´ to ´2\^{16}-1´ | The digits of a numeric literal may be separated by arbitrarily many underscores for purposes of legibility. @@ -503,11 +503,11 @@ not processed, except for Unicode escapes. #### Interpolated string ```ebnf -interpolatedString ::= alphaid ‘"’ {printableChar \ (‘"’ | ‘\$’) | escape} ‘"’ - | alphaid ‘"""’ {[‘"’] [‘"’] char \ (‘"’ | ‘\$’) | escape} {‘"’} ‘"""’ -escape ::= ‘\$\$’ - | ‘\$’ id - | ‘\$’ BlockExpr +interpolatedString ::= alphaid ‘"’ {printableChar \ (‘"’ | ‘$’) | escape} ‘"’ + | alphaid ‘"""’ {[‘"’] [‘"’] char \ (‘"’ | ‘$’) | escape} {‘"’} ‘"""’ +escape ::= ‘$$’ + | ‘$’ id + | ‘$’ BlockExpr alphaid ::= upper idrest | varid @@ -522,24 +522,24 @@ or multi-line (triple quote). Inside a interpolated string none of the usual escape characters are interpreted (except for unicode escapes) no matter whether the string literal is normal (enclosed in single quotes) or multi-line (enclosed in triple quotes). -Instead, there is are two new forms of dollar sign escape. -The most general form encloses an expression in \${ and }, i.e. \${expr}. -The expression enclosed in the braces that follow the leading \$ character is of +Instead, there are two new forms of dollar sign escape. +The most general form encloses an expression in `${` and `}`, i.e. `${expr}`. +The expression enclosed in the braces that follow the leading `$` character is of syntactical category BlockExpr. Hence, it can contain multiple statements, -and newlines are significant. Single ‘\$’-signs are not permitted in isolation -in a interpolated string. A single ‘\$’-sign can still be obtained by doubling the ‘\$’ -character: ‘\$\$’. +and newlines are significant. Single ‘$’-signs are not permitted in isolation +in a interpolated string. A single ‘$’-sign can still be obtained by doubling the ‘$’ +character: ‘$$’. -The simpler form consists of a ‘\$’-sign followed by an identifier starting with +The simpler form consists of a ‘$’-sign followed by an identifier starting with a letter and followed only by letters, digits, and underscore characters, -e.g \$id. The simpler form is expanded by putting braces around the identifier, -e.g \$id is equivalent to \${id}. In the following, unless we explicitly state otherwise, +e.g `$id`. The simpler form is expanded by putting braces around the identifier, +e.g `$id` is equivalent to `${id}`. In the following, unless we explicitly state otherwise, we assume that this expansion has already been performed. -The expanded expression is type checked normally. Usually, StringContext will resolve to +The expanded expression is type checked normally. Usually, `StringContext` will resolve to the default implementation in the scala package, but it could also be user-defined. Note that new interpolators can also be added through -implicit conversion of the built-in scala.StringContext. +implicit conversion of the built-in `scala.StringContext`. One could write an extension ```scala @@ -576,8 +576,8 @@ symbolLiteral ::= ‘'’ plainid ``` A symbol literal `'x` is a shorthand for the expression `scala.Symbol("x")` and -is of the [literal type](03-types.html#literal-types) `'x`. `Symbol` is a [case -class](05-classes-and-objects.html#case-classes), which is defined as follows. +is of the [literal type](03-types.html#literal-types) `'x`. +`Symbol` is a [case class](05-classes-and-objects.html#case-classes), which is defined as follows. ```scala package scala diff --git a/spec/02-identifiers-names-and-scopes.md b/spec/02-identifiers-names-and-scopes.md index 6aa36c4f1991..b8bde8cfd1a9 100644 --- a/spec/02-identifiers-names-and-scopes.md +++ b/spec/02-identifiers-names-and-scopes.md @@ -48,24 +48,24 @@ locally { } ``` -A reference to an unqualified (type- or term-) identifier $x$ is bound +A reference to an unqualified (type- or term-) identifier ´x´ is bound by the unique binding, which -- defines an entity with name $x$ in the same namespace as the identifier, and -- shadows all other bindings that define entities with name $x$ in that +- defines an entity with name ´x´ in the same namespace as the identifier, and +- shadows all other bindings that define entities with name ´x´ in that namespace. -It is an error if no such binding exists. If $x$ is bound by an -import clause, then the simple name $x$ is taken to be equivalent to -the qualified name to which $x$ is mapped by the import clause. If $x$ -is bound by a definition or declaration, then $x$ refers to the entity -introduced by that binding. In that case, the type of $x$ is the type +It is an error if no such binding exists. If ´x´ is bound by an +import clause, then the simple name ´x´ is taken to be equivalent to +the qualified name to which ´x´ is mapped by the import clause. If ´x´ +is bound by a definition or declaration, then ´x´ refers to the entity +introduced by that binding. In that case, the type of ´x´ is the type of the referenced entity. -A reference to a qualified (type- or term-) identifier $e.x$ refers to -the member of the type $T$ of $e$ which has the name $x$ in the same -namespace as the identifier. It is an error if $T$ is not a [value type](03-types.html#value-types). -The type of $e.x$ is the member type of the referenced entity in $T$. +A reference to a qualified (type- or term-) identifier ´e.x´ refers to +the member of the type ´T´ of ´e´ which has the name ´x´ in the same +namespace as the identifier. It is an error if ´T´ is not a [value type](03-types.html#value-types). +The type of ´e.x´ is the member type of the referenced entity in ´T´. Binding precedence implies that the way source is bundled in files affects name resolution. In particular, imported names have higher precedence than names, defined in other files, @@ -160,24 +160,24 @@ precedences between them. package p { // `X' bound by package clause import Console._ // `println' bound by wildcard import object Y { - println(s"L4: \$X") // `X' refers to `p.X' here + println(s"L4: $X") // `X' refers to `p.X' here locally { import q._ // `X' bound by wildcard import - println(s"L7: \$X") // `X' refers to `q.X' here + println(s"L7: $X") // `X' refers to `q.X' here import X._ // `x' and `y' bound by wildcard import - println(s"L9: \$x") // `x' refers to `q.X.x' here + println(s"L9: $x") // `x' refers to `q.X.x' here locally { val x = 3 // `x' bound by local definition - println(s"L12: \$x") // `x' refers to constant `3' here + println(s"L12: $x") // `x' refers to constant `3' here locally { import q.X._ // `x' and `y' bound by wildcard import -// println(s"L15: \$x") // reference to `x' is ambiguous here +// println(s"L15: $x") // reference to `x' is ambiguous here import X.y // `y' bound by explicit import - println(s"L17: \$y") // `y' refers to `q.X.y' here + println(s"L17: $y") // `y' refers to `q.X.y' here locally { val x = "abc" // `x' bound by local definition import p.X._ // `x' and `y' bound by wildcard import -// println(s"L21: \$y") // reference to `y' is ambiguous here - println(s"L22: \$x") // `x' refers to string "abc" here +// println(s"L21: $y") // reference to `y' is ambiguous here + println(s"L22: $x") // `x' refers to string "abc" here }}}}}} ``` diff --git a/spec/03-types.md b/spec/03-types.md index b477f34473ce..2f898d8acb39 100644 --- a/spec/03-types.md +++ b/spec/03-types.md @@ -81,17 +81,17 @@ and in that function form a central role in Scala's type system. A path is one of the following. - The empty path ε (which cannot be written explicitly in user programs). -- $C.$`this`, where $C$ references a class. - The path `this` is taken as a shorthand for $C.$`this` where - $C$ is the name of the class directly enclosing the reference. -- $p.x$ where $p$ is a path and $x$ is a stable member of $p$. +- ´C.´`this`, where ´C´ references a class. + The path `this` is taken as a shorthand for ´C.´`this` where + ´C´ is the name of the class directly enclosing the reference. +- ´p.x´ where ´p´ is a path and ´x´ is a stable member of ´p´. _Stable members_ are packages or members introduced by object definitions or by value definitions of [non-volatile types](#volatile-types). -- $C.$`super`$.x$ or $C.$`super`$[M].x$ - where $C$ references a class and $x$ references a - stable member of the super class or designated parent class $M$ of $C$. - The prefix `super` is taken as a shorthand for $C.$`super` where - $C$ is the name of the class directly enclosing the reference. +- ´C.´`super`´.x´ or ´C.´`super`´[M].x´ + where ´C´ references a class and ´x´ references a + stable member of the super class or designated parent class ´M´ of ´C´. + The prefix `super` is taken as a shorthand for ´C.´`super` where + ´C´ is the name of the class directly enclosing the reference. A _stable identifier_ is a path which ends in an identifier. @@ -106,12 +106,12 @@ forms. SimpleType ::= Path ‘.’ ‘type’ ``` -A _singleton type_ is of the form $p.$`type`. Where $p$ is a path pointing to a +A _singleton type_ is of the form ´p.´`type`. Where ´p´ is a path pointing to a value which [conforms](06-expressions.html#expression-typing) to `scala.AnyRef`, the type denotes the set of values consisting of `null` and the -value denoted by $p$ (i.e., the value $v$ for which `v eq p`). Where the path +value denoted by ´p´ (i.e., the value ´v´ for which `v eq p`). Where the path does not conform to `scala.AnyRef` the type denotes the set consisting of only -the value denoted by $p$. +the value denoted by ´p´. @@ -143,12 +143,12 @@ or a type that is declared to be a subtype of trait `scala.Singleton`. SimpleType ::= SimpleType ‘#’ id ``` -A _type projection_ $T$#$x$ references the type member named -$x$ of type $T$. +A _type projection_ ´T´#´x´ references the type member named +´x´ of type ´T´. @@ -161,11 +161,11 @@ SimpleType ::= StableId A _type designator_ refers to a named value type. It can be simple or qualified. All such type designators are shorthands for type projections. -Specifically, the unqualified type name $t$ where $t$ is bound in some -class, object, or package $C$ is taken as a shorthand for -$C.$`this.type#`$t$. If $t$ is -not bound in a class, object, or package, then $t$ is taken as a -shorthand for ε`.type#`$t$. +Specifically, the unqualified type name ´t´ where ´t´ is bound in some +class, object, or package ´C´ is taken as a shorthand for +´C.´`this.type#`´t´. If ´t´ is +not bound in a class, object, or package, then ´t´ is taken as a +shorthand for ε`.type#`´t´. A qualified type designator has the form `p.t` where `p` is a [path](#paths) and _t_ is a type name. Such a type designator is @@ -174,7 +174,7 @@ equivalent to the type projection `p.type#t`. ###### Example Some type designators and their expansions are listed below. We assume -a local type parameter $t$, a value `maintable` +a local type parameter ´t´, a value `maintable` with a type member `Node` and the standard class `scala.Int`, | Designator | Expansion | @@ -191,16 +191,16 @@ SimpleType ::= SimpleType TypeArgs TypeArgs ::= ‘[’ Types ‘]’ ``` -A _parameterized type_ $T[ T_1 , \ldots , T_n ]$ consists of a type -designator $T$ and type parameters $T_1 , \ldots , T_n$ where -$n \geq 1$. $T$ must refer to a type constructor which takes $n$ type -parameters $a_1 , \ldots , a_n$. +A _parameterized type_ ´T[ T_1 , \ldots , T_n ]´ consists of a type +designator ´T´ and type parameters ´T_1 , \ldots , T_n´ where +´n \geq 1´. ´T´ must refer to a type constructor which takes ´n´ type +parameters ´a_1 , \ldots , a_n´. -Say the type parameters have lower bounds $L_1 , \ldots , L_n$ and -upper bounds $U_1, \ldots, U_n$. The parameterized type is +Say the type parameters have lower bounds ´L_1 , \ldots , L_n´ and +upper bounds ´U_1, \ldots, U_n´. The parameterized type is well-formed if each actual type parameter -_conforms to its bounds_, i.e. $\sigma L_i <: T_i <: \sigma U_i$ where $\sigma$ is the -substitution $[ a_1 := T_1 , \ldots , a_n := T_n ]$. +_conforms to its bounds_, i.e. ´\sigma L_i <: T_i <: \sigma U_i´ where ´\sigma´ is the +substitution ´[ a_1 := T_1 , \ldots , a_n := T_n ]´. ###### Example Parameterized Types @@ -251,8 +251,8 @@ G[S, Int] // illegal: S constrains its parameter to SimpleType ::= ‘(’ Types ‘)’ ``` -A _tuple type_ $(T_1 , \ldots , T_n)$ is an alias for the -class `scala.Tuple$n$[$T_1$, … , $T_n$]`, where $n \geq 2$. +A _tuple type_ ´(T_1 , \ldots , T_n)´ is an alias for the +class `scala.Tuple´n´[´T_1´, … , ´T_n´]`, where ´n \geq 2´. Tuple classes are case classes whose fields can be accessed using selectors `_1` , … , `_n`. Their functionality is @@ -262,14 +262,14 @@ standard Scala library (they might also add other methods and implement other traits). ```scala -case class Tuple$n$[+$T_1$, … , +$T_n$](_1: $T_1$, … , _n: $T_n$) -extends Product_n[$T_1$, … , $T_n$] +case class Tuple´_n´[+´T_1´, … , +´T_n´](_1: ´T_1´, … , _n: ´T_n´) +extends Product´_n´[´T_1´, … , ´T_n´] -trait Product_n[+$T_1$, … , +$T_n$] { - override def productArity = $n$ - def _1: $T_1$ +trait Product´_n´[+´T_1´, … , +´T_n´] { + override def productArity = ´n´ + def _1: ´T_1´ … - def _n: $T_n$ + def _n: ´T_n´ } ``` @@ -279,9 +279,9 @@ trait Product_n[+$T_1$, … , +$T_n$] { AnnotType ::= SimpleType {Annotation} ``` -An _annotated type_ $T$ $a_1, \ldots, a_n$ +An _annotated type_ ´T´ ´a_1, \ldots, a_n´ attaches [annotations](11-annotations.html#user-defined-annotations) -$a_1 , \ldots , a_n$ to the type $T$. +´a_1 , \ldots , a_n´ to the type ´T´. ###### Example @@ -302,12 +302,12 @@ RefineStat ::= Dcl | ``` -A _compound type_ $T_1$ `with` … `with` $T_n \\{ R \\}$ +A _compound type_ ´T_1´ `with` … `with` ´T_n \\{ R \\}´ represents objects with members as given in the component types -$T_1 , \ldots , T_n$ and the refinement $\\{ R \\}$. A refinement -$\\{ R \\}$ contains declarations and type definitions. +´T_1 , \ldots , T_n´ and the refinement ´\\{ R \\}´. A refinement +´\\{ R \\}´ contains declarations and type definitions. If a declaration or definition overrides a declaration or definition in -one of the component types $T_1 , \ldots , T_n$, the usual rules for +one of the component types ´T_1 , \ldots , T_n´, the usual rules for [overriding](05-classes-and-objects.html#overriding) apply; otherwise the declaration or definition is said to be “structural” [^2]. @@ -323,11 +323,11 @@ definition within the refinement. This restriction does not apply to the method's result type. If no refinement is given, the empty refinement is implicitly added, -i.e. $T_1$ `with` … `with` $T_n$ is a shorthand for $T_1$ `with` … `with` $T_n \\{\\}$. +i.e. ´T_1´ `with` … `with` ´T_n´ is a shorthand for ´T_1´ `with` … `with` ´T_n \\{\\}´. A compound type may also consist of just a refinement -$\\{ R \\}$ with no preceding component types. Such a type is -equivalent to `AnyRef` $\\{ R \\}$. +´\\{ R \\}´ with no preceding component types. Such a type is +equivalent to `AnyRef` ´\\{ R \\}´. ###### Example @@ -367,10 +367,10 @@ a value `callsign` and a `fly` method. InfixType ::= CompoundType {id [nl] CompoundType} ``` -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$. The type is equivalent to the type application -`op`$[T_1, T_2]$. The infix operator `op` may be an +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´. The type is equivalent to the type application +`op`´[T_1, T_2]´. The infix operator `op` may be an arbitrary identifier. All type infix operators have the same precedence; parentheses have to @@ -380,13 +380,13 @@ ending in a colon ‘:’ are right-associative; all other operators are left-associative. In a sequence of consecutive type infix operations -$t_0 \, \mathit{op} \, t_1 \, \mathit{op_2} \, \ldots \, \mathit{op_n} \, t_n$, -all operators $\mathit{op}\_1 , \ldots , \mathit{op}\_n$ must have the same +´t_0 \, \mathit{op} \, t_1 \, \mathit{op_2} \, \ldots \, \mathit{op_n} \, t_n´, +all operators ´\mathit{op}\_1 , \ldots , \mathit{op}\_n´ must have the same associativity. If they are all left-associative, the sequence is interpreted as -$(\ldots (t_0 \mathit{op_1} t_1) \mathit{op_2} \ldots) \mathit{op_n} t_n$, +´(\ldots (t_0 \mathit{op_1} t_1) \mathit{op_2} \ldots) \mathit{op_n} t_n´, otherwise it is interpreted as -$t_0 \mathit{op_1} (t_1 \mathit{op_2} ( \ldots \mathit{op_n} t_n) \ldots)$. +´t_0 \mathit{op_1} (t_1 \mathit{op_2} ( \ldots \mathit{op_n} t_n) \ldots)´. ### Function Types @@ -396,27 +396,27 @@ FunctionArgs ::= InfixType | ‘(’ [ ParamType {‘,’ ParamType } ] ‘)’ ``` -The type $(T_1 , \ldots , T_n) \Rightarrow U$ represents the set of function -values that take arguments of types $T1 , \ldots , Tn$ and yield -results of type $U$. In the case of exactly one argument type -$T \Rightarrow U$ is a shorthand for $(T) \Rightarrow U$. -An argument type of the form $\Rightarrow T$ -represents a [call-by-name parameter](04-basic-declarations-and-definitions.html#by-name-parameters) of type $T$. +The type ´(T_1 , \ldots , T_n) \Rightarrow U´ represents the set of function +values that take arguments of types ´T_1 , \ldots , Tn´ and yield +results of type ´U´. In the case of exactly one argument type +´T \Rightarrow U´ is a shorthand for ´(T) \Rightarrow U´. +An argument type of the form ´\Rightarrow T´ +represents a [call-by-name parameter](04-basic-declarations-and-definitions.html#by-name-parameters) of type ´T´. Function types associate to the right, e.g. -$S \Rightarrow T \Rightarrow U$ is the same as -$S \Rightarrow (T \Rightarrow U)$. +´S \Rightarrow T \Rightarrow U´ is the same as +´S \Rightarrow (T \Rightarrow U)´. Function types are shorthands for class types that define `apply` -functions. Specifically, the $n$-ary function type -$(T_1 , \ldots , T_n) \Rightarrow U$ is a shorthand for the class type -`Function$_n$[T1 , … , $T_n$, U]`. Such class -types are defined in the Scala library for $n$ between 0 and 22 as follows. +functions. Specifically, the ´n´-ary function type +´(T_1 , \ldots , T_n) \Rightarrow U´ is a shorthand for the class type +`Function´_n´[´T_1´ , … , ´T_n´, ´U´]`. Such class +types are defined in the Scala library for ´n´ between 0 and 22 as follows. ```scala package scala -trait Function_n[-T1 , … , -T$_n$, +R] { - def apply(x1: T1 , … , x$_n$: T$_n$): R +trait Function´_n´[-´T_1´ , … , -´T_n´, +´U´] { + def apply(´x_1´: ´T_1´ , … , ´x_n´: ´T_n´): ´U´ override def toString = "" } ``` @@ -434,63 +434,63 @@ ExistentialDcl ::= ‘type’ TypeDcl | ‘val’ ValDcl ``` -An _existential type_ has the form `$T$ forSome { $Q$ }` -where $Q$ is a sequence of +An _existential type_ has the form `´T´ forSome { ´Q´ }` +where ´Q´ is a sequence of [type declarations](04-basic-declarations-and-definitions.html#type-declarations-and-type-aliases). Let -$t_1[\mathit{tps}\_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}\_n] >: L_n <: U_n$ -be the types declared in $Q$ (any of the -type parameter sections `[ $\mathit{tps}_i$ ]` might be missing). -The scope of each type $t_i$ includes the type $T$ and the existential clause -$Q$. -The type variables $t_i$ are said to be _bound_ in the type -`$T$ forSome { $Q$ }`. -Type variables which occur in a type $T$ but which are not bound in $T$ are said -to be _free_ in $T$. - -A _type instance_ of `$T$ forSome { $Q$ }` -is a type $\sigma T$ where $\sigma$ is a substitution over $t_1 , \ldots , t_n$ -such that, for each $i$, $\sigma L_i <: \sigma t_i <: \sigma U_i$. -The set of values denoted by the existential type `$T$ forSome {$\,Q\,$}` +´t_1[\mathit{tps}\_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}\_n] >: L_n <: U_n´ +be the types declared in ´Q´ (any of the +type parameter sections `[ ´\mathit{tps}_i´ ]` might be missing). +The scope of each type ´t_i´ includes the type ´T´ and the existential clause +´Q´. +The type variables ´t_i´ are said to be _bound_ in the type +`´T´ forSome { ´Q´ }`. +Type variables which occur in a type ´T´ but which are not bound in ´T´ are said +to be _free_ in ´T´. + +A _type instance_ of `´T´ forSome { ´Q´ }` +is a type ´\sigma T´ where ´\sigma´ is a substitution over ´t_1 , \ldots , t_n´ +such that, for each ´i´, ´\sigma L_i <: \sigma t_i <: \sigma U_i´. +The set of values denoted by the existential type `´T´ forSome {´\,Q\,´}` is the union of the set of values of all its type instances. -A _skolemization_ of `$T$ forSome { $Q$ }` is -a type instance $\sigma T$, where $\sigma$ is the substitution -$[t_1'/t_1 , \ldots , t_n'/t_n]$ and each $t_i'$ is a fresh abstract type -with lower bound $\sigma L_i$ and upper bound $\sigma U_i$. +A _skolemization_ of `´T´ forSome { ´Q´ }` is +a type instance ´\sigma T´, where ´\sigma´ is the substitution +´[t_1'/t_1 , \ldots , t_n'/t_n]´ and each ´t_i'´ is a fresh abstract type +with lower bound ´\sigma L_i´ and upper bound ´\sigma U_i´. #### Simplification Rules Existential types obey the following four equivalences: 1. Multiple for-clauses in an existential type can be merged. E.g., -`$T$ forSome { $Q$ } forSome { $Q'$ }` +`´T´ forSome { ´Q´ } forSome { ´Q'´ }` is equivalent to -`$T$ forSome { $Q$ ; $Q'$}`. +`´T´ forSome { ´Q´ ; ´Q'´}`. 1. Unused quantifications can be dropped. E.g., -`$T$ forSome { $Q$ ; $Q'$}` -where none of the types defined in $Q'$ are referred to by $T$ or $Q$, +`´T´ forSome { ´Q´ ; ´Q'´}` +where none of the types defined in ´Q'´ are referred to by ´T´ or ´Q´, is equivalent to -`$T$ forSome {$ Q $}`. +`´T´ forSome {´ Q ´}`. 1. An empty quantification can be dropped. E.g., -`$T$ forSome { }` is equivalent to $T$. -1. An existential type `$T$ forSome { $Q$ }` where $Q$ contains -a clause `type $t[\mathit{tps}] >: L <: U$` is equivalent -to the type `$T'$ forSome { $Q$ }` where $T'$ results from $T$ by replacing -every [covariant occurrence](04-basic-declarations-and-definitions.html#variance-annotations) of $t$ in $T$ by $U$ and by -replacing every contravariant occurrence of $t$ in $T$ by $L$. +`´T´ forSome { }` is equivalent to ´T´. +1. An existential type `´T´ forSome { ´Q´ }` where ´Q´ contains +a clause `type ´t[\mathit{tps}] >: L <: U´` is equivalent +to the type `´T'´ forSome { ´Q´ }` where ´T'´ results from ´T´ by replacing +every [covariant occurrence](04-basic-declarations-and-definitions.html#variance-annotations) of ´t´ in ´T´ by ´U´ and by +replacing every contravariant occurrence of ´t´ in ´T´ by ´L´. #### Existential Quantification over Values As a syntactic convenience, the bindings clause in an existential type may also contain -value declarations `val $x$: $T$`. -An existential type `$T$ forSome { $Q$; val $x$: $S\,$;$\,Q'$ }` +value declarations `val ´x´: ´T´`. +An existential type `´T´ forSome { ´Q´; val ´x´: ´S\,´;´\,Q'´ }` is treated as a shorthand for the type -`$T'$ forSome { $Q$; type $t$ <: $S$ with Singleton; $Q'$ }`, where $t$ is a -fresh type name and $T'$ results from $T$ by replacing every occurrence of -`$x$.type` with $t$. +`´T'´ forSome { ´Q´; type ´t´ <: ´S´ with Singleton; ´Q'´ }`, where ´t´ is a +fresh type name and ´T'´ results from ´T´ by replacing every occurrence of +`´x´.type` with ´t´. #### Placeholder Syntax for Existential Types @@ -499,26 +499,26 @@ WildcardType ::= ‘_’ TypeBounds ``` Scala supports a placeholder syntax for existential types. -A _wildcard type_ is of the form `_$\;$>:$\,L\,$<:$\,U$`. Both bound -clauses may be omitted. If a lower bound clause `>:$\,L$` is missing, -`>:$\,$scala.Nothing` -is assumed. If an upper bound clause `<:$\,U$` is missing, -`<:$\,$scala.Any` is assumed. A wildcard type is a shorthand for an +A _wildcard type_ is of the form `_´\;´>:´\,L\,´<:´\,U´`. Both bound +clauses may be omitted. If a lower bound clause `>:´\,L´` is missing, +`>:´\,´scala.Nothing` +is assumed. If an upper bound clause `<:´\,U´` is missing, +`<:´\,´scala.Any` is assumed. A wildcard type is a shorthand for an existentially quantified type variable, where the existential quantification is implicit. A wildcard type must appear as a type argument of a parameterized type. -Let $T = p.c[\mathit{targs},T,\mathit{targs}']$ be a parameterized type where -$\mathit{targs}, \mathit{targs}'$ may be empty and -$T$ is a wildcard type `_$\;$>:$\,L\,$<:$\,U$`. Then $T$ is equivalent to the +Let ´T = p.c[\mathit{targs},T,\mathit{targs}']´ be a parameterized type where +´\mathit{targs}, \mathit{targs}'´ may be empty and +´T´ is a wildcard type `_´\;´>:´\,L\,´<:´\,U´`. Then ´T´ is equivalent to the existential type ```scala -$p.c[\mathit{targs},t,\mathit{targs}']$ forSome { type $t$ >: $L$ <: $U$ } +´p.c[\mathit{targs},t,\mathit{targs}']´ forSome { type ´t´ >: ´L´ <: ´U´ } ``` -where $t$ is some fresh type variable. +where ´t´ is some fresh type variable. Wildcard types may also appear as parts of [infix types](#infix-types) , [function types](#function-types), or [tuple types](#tuple-types). @@ -588,15 +588,15 @@ report as the internal types of defined identifiers. ### Method Types -A _method type_ is denoted internally as $(\mathit{Ps})U$, where $(\mathit{Ps})$ -is a sequence of parameter names and types $(p_1:T_1 , \ldots , p_n:T_n)$ -for some $n \geq 0$ and $U$ is a (value or method) type. This type -represents named methods that take arguments named $p_1 , \ldots , p_n$ -of types $T_1 , \ldots , T_n$ -and that return a result of type $U$. +A _method type_ is denoted internally as ´(\mathit{Ps})U´, where ´(\mathit{Ps})´ +is a sequence of parameter names and types ´(p_1:T_1 , \ldots , p_n:T_n)´ +for some ´n \geq 0´ and ´U´ is a (value or method) type. This type +represents named methods that take arguments named ´p_1 , \ldots , p_n´ +of types ´T_1 , \ldots , T_n´ +and that return a result of type ´U´. -Method types associate to the right: $(\mathit{Ps}\_1)(\mathit{Ps}\_2)U$ is -treated as $(\mathit{Ps}\_1)((\mathit{Ps}\_2)U)$. +Method types associate to the right: ´(\mathit{Ps}\_1)(\mathit{Ps}\_2)U´ is +treated as ´(\mathit{Ps}\_1)((\mathit{Ps}\_2)U)´. A special case are types of methods without any parameters. They are written here `=> T`. Parameterless methods name expressions @@ -627,15 +627,15 @@ c: (Int) (String, String) String ### Polymorphic Method Types -A polymorphic method type is denoted internally as `[$\mathit{tps}\,$]$T$` where -`[$\mathit{tps}\,$]` is a type parameter section -`[$a_1$ >: $L_1$ <: $U_1 , \ldots , a_n$ >: $L_n$ <: $U_n$]` -for some $n \geq 0$ and $T$ is a +A polymorphic method type is denoted internally as `[´\mathit{tps}\,´]´T´` where +`[´\mathit{tps}\,´]` is a type parameter section +`[´a_1´ >: ´L_1´ <: ´U_1 , \ldots , a_n´ >: ´L_n´ <: ´U_n´]` +for some ´n \geq 0´ and ´T´ is a (value or method) type. This type represents named methods that -take type arguments `$S_1 , \ldots , S_n$` which +take type arguments `´S_1 , \ldots , S_n´` which [conform](#parameterized-types) to the lower bounds -`$L_1 , \ldots , L_n$` and the upper bounds -`$U_1 , \ldots , U_n$` and that yield results of type $T$. +`´L_1 , \ldots , L_n´` and the upper bounds +`´U_1 , \ldots , U_n´` and that yield results of type ´T´. ###### Example @@ -656,7 +656,7 @@ union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A] ### Type Constructors A _type constructor_ is represented internally much like a polymorphic method type. -`[$\pm$ $a_1$ >: $L_1$ <: $U_1 , \ldots , \pm a_n$ >: $L_n$ <: $U_n$] $T$` +`[´\pm´ ´a_1´ >: ´L_1´ <: ´U_1 , \ldots , \pm a_n´ >: ´L_n´ <: ´U_n´] ´T´` represents a type that is expected by a [type constructor parameter](04-basic-declarations-and-definitions.html#type-parameters) or an [abstract type constructor binding](04-basic-declarations-and-definitions.html#type-declarations-and-type-aliases) with @@ -681,124 +681,124 @@ anonymous type `[+X] Iterable[X]`, which may be passed to the More than one values or methods are defined in the same scope with the same name, we model -An overloaded type consisting of type alternatives $T_1 \commadots T_n (n \geq 2)$ is denoted internally $T_1 \overload \ldots \overload T_n$. +An overloaded type consisting of type alternatives ´T_1 \commadots T_n (n \geq 2)´ is denoted internally ´T_1 \overload \ldots \overload T_n´. ###### Example ```scala def println(): Unit -def println(s: String): Unit = $\ldots$ -def println(x: Float): Unit = $\ldots$ -def println(x: Float, width: Int): Unit = $\ldots$ -def println[A](x: A)(tostring: A => String): Unit = $\ldots$ +def println(s: String): Unit = ´\ldots´ +def println(x: Float): Unit = ´\ldots´ +def println(x: Float, width: Int): Unit = ´\ldots´ +def println[A](x: A)(tostring: A => String): Unit = ´\ldots´ ``` define a single function `println` which has an overloaded type. ``` -println: () Unit $\overload$ - (String) Unit $\overload$ - (Float) Unit $\overload$ - (Float, Int) Unit $\overload$ +println: () Unit ´\overload´ + (String) Unit ´\overload´ + (Float) Unit ´\overload´ + (Float, Int) Unit ´\overload´ [A] (A) (A => String) Unit ``` ###### Example ```scala -def f(x: T): T = $\ldots$ +def f(x: T): T = ´\ldots´ val f = 0 ``` -define a function `f} which has type `(x: T)T $\overload$ Int`. +define a function `f} which has type `(x: T)T ´\overload´ Int`. --> ## Base Types and Member Definitions Types of class members depend on the way the members are referenced. Central here are three notions, namely: -1. the notion of the set of base types of a type $T$, -1. the notion of a type $T$ in some class $C$ seen from some - prefix type $S$, -1. the notion of the set of member bindings of some type $T$. +1. the notion of the set of base types of a type ´T´, +1. the notion of a type ´T´ in some class ´C´ seen from some + prefix type ´S´, +1. the notion of the set of member bindings of some type ´T´. These notions are defined mutually recursively as follows. 1. The set of _base types_ of a type is a set of class types, given as follows. - - The base types of a class type $C$ with parents $T_1 , \ldots , T_n$ are - $C$ itself, as well as the base types of the compound type - `$T_1$ with … with $T_n$ { $R$ }`. + - The base types of a class type ´C´ with parents ´T_1 , \ldots , T_n´ are + ´C´ itself, as well as the base types of the compound type + `´T_1´ with … with ´T_n´ { ´R´ }`. - The base types of an aliased type are the base types of its alias. - The base types of an abstract type are the base types of its upper bound. - The base types of a parameterized type - `$C$[$T_1 , \ldots , T_n$]` are the base types - of type $C$, where every occurrence of a type parameter $a_i$ - of $C$ has been replaced by the corresponding parameter type $T_i$. - - The base types of a singleton type `$p$.type` are the base types of - the type of $p$. + `´C´[´T_1 , \ldots , T_n´]` are the base types + of type ´C´, where every occurrence of a type parameter ´a_i´ + of ´C´ has been replaced by the corresponding parameter type ´T_i´. + - The base types of a singleton type `´p´.type` are the base types of + the type of ´p´. - The base types of a compound type - `$T_1$ with $\ldots$ with $T_n$ { $R$ }` + `´T_1´ with ´\ldots´ with ´T_n´ { ´R´ }` are the _reduced union_ of the base - classes of all $T_i$'s. This means: - Let the multi-set $\mathscr{S}$ be the multi-set-union of the - base types of all $T_i$'s. - If $\mathscr{S}$ contains several type instances of the same class, say - `$S^i$#$C$[$T^i_1 , \ldots , T^i_n$]` $(i \in I)$, then + classes of all ´T_i´'s. This means: + Let the multi-set ´\mathscr{S}´ be the multi-set-union of the + base types of all ´T_i´'s. + If ´\mathscr{S}´ contains several type instances of the same class, say + `´S^i´#´C´[´T^i_1 , \ldots , T^i_n´]` ´(i \in I)´, then all those instances are replaced by one of them which conforms to all others. It is an error if no such instance exists. It follows that the reduced union, if it exists, produces a set of class types, where different types are instances of different classes. - - The base types of a type selection `$S$#$T$` are - determined as follows. If $T$ is an alias or abstract type, the - previous clauses apply. Otherwise, $T$ must be a (possibly - parameterized) class type, which is defined in some class $B$. Then - the base types of `$S$#$T$` are the base types of $T$ - in $B$ seen from the prefix type $S$. - - The base types of an existential type `$T$ forSome { $Q$ }` are - all types `$S$ forSome { $Q$ }` where $S$ is a base type of $T$. - -1. The notion of a type $T$ _in class $C$ seen from some prefix type $S$_ - makes sense only if the prefix type $S$ - has a type instance of class $C$ as a base type, say - `$S'$#$C$[$T_1 , \ldots , T_n$]`. Then we define as follows. - - If `$S$ = $\epsilon$.type`, then $T$ in $C$ seen from $S$ is - $T$ itself. - - Otherwise, if $S$ is an existential type `$S'$ forSome { $Q$ }`, and - $T$ in $C$ seen from $S'$ is $T'$, - then $T$ in $C$ seen from $S$ is `$T'$ forSome {$\,Q\,$}`. - - Otherwise, if $T$ is the $i$'th type parameter of some class $D$, then - - If $S$ has a base type `$D$[$U_1 , \ldots , U_n$]`, for some type - parameters `[$U_1 , \ldots , U_n$]`, then $T$ in $C$ seen from $S$ - is $U_i$. - - Otherwise, if $C$ is defined in a class $C'$, then - $T$ in $C$ seen from $S$ is the same as $T$ in $C'$ seen from $S'$. - - Otherwise, if $C$ is not defined in another class, then - $T$ in $C$ seen from $S$ is $T$ itself. - - Otherwise, if $T$ is the singleton type `$D$.this.type` for some class $D$ + - The base types of a type selection `´S´#´T´` are + determined as follows. If ´T´ is an alias or abstract type, the + previous clauses apply. Otherwise, ´T´ must be a (possibly + parameterized) class type, which is defined in some class ´B´. Then + the base types of `´S´#´T´` are the base types of ´T´ + in ´B´ seen from the prefix type ´S´. + - The base types of an existential type `´T´ forSome { ´Q´ }` are + all types `´S´ forSome { ´Q´ }` where ´S´ is a base type of ´T´. + +1. The notion of a type ´T´ _in class ´C´ seen from some prefix type ´S´_ + makes sense only if the prefix type ´S´ + has a type instance of class ´C´ as a base type, say + `´S'´#´C´[´T_1 , \ldots , T_n´]`. Then we define as follows. + - If `´S´ = ´\epsilon´.type`, then ´T´ in ´C´ seen from ´S´ is + ´T´ itself. + - Otherwise, if ´S´ is an existential type `´S'´ forSome { ´Q´ }`, and + ´T´ in ´C´ seen from ´S'´ is ´T'´, + then ´T´ in ´C´ seen from ´S´ is `´T'´ forSome {´\,Q\,´}`. + - Otherwise, if ´T´ is the ´i´'th type parameter of some class ´D´, then + - If ´S´ has a base type `´D´[´U_1 , \ldots , U_n´]`, for some type + parameters `[´U_1 , \ldots , U_n´]`, then ´T´ in ´C´ seen from ´S´ + is ´U_i´. + - Otherwise, if ´C´ is defined in a class ´C'´, then + ´T´ in ´C´ seen from ´S´ is the same as ´T´ in ´C'´ seen from ´S'´. + - Otherwise, if ´C´ is not defined in another class, then + ´T´ in ´C´ seen from ´S´ is ´T´ itself. + - Otherwise, if ´T´ is the singleton type `´D´.this.type` for some class ´D´ then - - If $D$ is a subclass of $C$ and $S$ has a type instance of class $D$ - among its base types, then $T$ in $C$ seen from $S$ is $S$. - - Otherwise, if $C$ is defined in a class $C'$, then - $T$ in $C$ seen from $S$ is the same as $T$ in $C'$ seen from $S'$. - - Otherwise, if $C$ is not defined in another class, then - $T$ in $C$ seen from $S$ is $T$ itself. - - If $T$ is some other type, then the described mapping is performed + - If ´D´ is a subclass of ´C´ and ´S´ has a type instance of class ´D´ + among its base types, then ´T´ in ´C´ seen from ´S´ is ´S´. + - Otherwise, if ´C´ is defined in a class ´C'´, then + ´T´ in ´C´ seen from ´S´ is the same as ´T´ in ´C'´ seen from ´S'´. + - Otherwise, if ´C´ is not defined in another class, then + ´T´ in ´C´ seen from ´S´ is ´T´ itself. + - If ´T´ is some other type, then the described mapping is performed to all its type components. - If $T$ is a possibly parameterized class type, where $T$'s class - is defined in some other class $D$, and $S$ is some prefix type, - then we use "$T$ seen from $S$" as a shorthand for - "$T$ in $D$ seen from $S$". + If ´T´ is a possibly parameterized class type, where ´T´'s class + is defined in some other class ´D´, and ´S´ is some prefix type, + then we use "´T´ seen from ´S´" as a shorthand for + "´T´ in ´D´ seen from ´S´". -1. The _member bindings_ of a type $T$ are - 1. all bindings $d$ such that there exists a type instance of some class $C$ among the base types of $T$ - and there exists a definition or declaration $d'$ in $C$ - such that $d$ results from $d'$ by replacing every - type $T'$ in $d'$ by $T'$ in $C$ seen from $T$, and +1. The _member bindings_ of a type ´T´ are + 1. all bindings ´d´ such that there exists a type instance of some class ´C´ among the base types of ´T´ + and there exists a definition or declaration ´d'´ in ´C´ + such that ´d´ results from ´d'´ by replacing every + type ´T'´ in ´d'´ by ´T'´ in ´C´ seen from ´T´, and 2. all bindings of the type's [refinement](#compound-types), if it has one. The _definition_ of a type projection `S#T` is the member - binding $d_T$ of the type `T` in `S`. In that case, we also say - that `S#T` _is defined by_ $d_T$. + binding ´d_T´ of the type `T` in `S`. In that case, we also say + that `S#T` _is defined by_ ´d_T´. ## Relations between types @@ -806,18 +806,18 @@ We define the following relations between types. | Name | Symbolically | Interpretation | |------------------|----------------|----------------------------------------------------| -| Equivalence | $T \equiv U$ | $T$ and $U$ are interchangeable in all contexts. | -| Conformance | $T <: U$ | Type $T$ conforms to ("is a subtype of") type $U$. | -| Weak Conformance | $T <:_w U$ | Augments conformance for primitive numeric types. | -| Compatibility | | Type $T$ conforms to type $U$ after conversions. | +| Equivalence | ´T \equiv U´ | ´T´ and ´U´ are interchangeable in all contexts. | +| Conformance | ´T <: U´ | Type ´T´ conforms to ("is a subtype of") type ´U´. | +| Weak Conformance | ´T <:_w U´ | Augments conformance for primitive numeric types. | +| Compatibility | | Type ´T´ conforms to type ´U´ after conversions. | ### Equivalence -Equivalence $(\equiv)$ between types is the smallest congruence [^congruence] such that the following holds: +Equivalence ´(\equiv)´ between types is the smallest congruence [^congruence] such that the following holds: -- If $t$ is defined by a type alias `type $t$ = $T$`, then $t$ is equivalent to $T$. -- If a path $p$ has a singleton type `$q$.type`, then `$p$.type $\equiv q$.type`. -- If $O$ is defined by an object definition, and $p$ is a path consisting only of package or object selectors and ending in $O$, then `$O$.this.type $\equiv p$.type`. +- If ´t´ is defined by a type alias `type ´t´ = ´T´`, then ´t´ is equivalent to ´T´. +- If a path ´p´ has a singleton type `´q´.type`, then `´p´.type ´\equiv q´.type`. +- If ´O´ is defined by an object definition, and ´p´ is a path consisting only of package or object selectors and ending in ´O´, then `´O´.this.type ´\equiv p´.type`. - Two [compound types](#compound-types) are equivalent if the sequences of their component are pairwise equivalent, and occur in the same order, and their refinements are equivalent. Two refinements are equivalent if they @@ -848,91 +848,92 @@ Equivalence $(\equiv)$ between types is the smallest congruence [^congruence] su ### Conformance -The conformance relation $(<:)$ is the smallest transitive relation that satisfies the following conditions. +The conformance relation ´(<:)´ is the smallest transitive relation that satisfies the following conditions. -- Conformance includes equivalence. If $T \equiv U$ then $T <: U$. -- For every value type $T$, `scala.Nothing <: $T$ <: scala.Any`. -- For every type constructor $T$ (with any number of type parameters), `scala.Nothing <: $T$ <: scala.Any`. -- For every value type $T$, `scala.Null <: $T$` unless `$T$ <: scala.AnyVal`. -- A type variable or abstract type $t$ conforms to its upper bound and - its lower bound conforms to $t$. + +- Conformance includes equivalence. If `T \equiv U` then `T <: U`. +- For every value type `T`, `scala.Nothing <: ´T´ <: scala.Any`. +- For every type constructor ´T´ (with any number of type parameters), `scala.Nothing <: ´T´ <: scala.Any`. +- For every value type ´T´, `scala.Null <: ´T´` unless `´T´ <: scala.AnyVal`. +- A type variable or abstract type ´t´ conforms to its upper bound and + its lower bound conforms to ´t´. - A class type or parameterized type conforms to any of its base-types. -- A singleton type `$p$.type` conforms to the type of the path $p$. -- A singleton type `$p$.type` conforms to the type `scala.Singleton`. -- A type projection `$T$#$t$` conforms to `$U$#$t$` if $T$ conforms to $U$. -- A parameterized type `$T$[$T_1$ , … , $T_n$]` conforms to - `$T$[$U_1$ , … , $U_n$]` if - the following three conditions hold for $i \in \{ 1 , \ldots , n \}$: - 1. If the $i$'th type parameter of $T$ is declared covariant, then - $T_i <: U_i$. - 1. If the $i$'th type parameter of $T$ is declared contravariant, then - $U_i <: T_i$. - 1. If the $i$'th type parameter of $T$ is declared neither covariant - nor contravariant, then $U_i \equiv T_i$. -- A compound type `$T_1$ with $\ldots$ with $T_n$ {$R\,$}` conforms to - each of its component types $T_i$. -- If $T <: U_i$ for $i \in \{ 1 , \ldots , n \}$ and for every - binding $d$ of a type or value $x$ in $R$ there exists a member - binding of $x$ in $T$ which subsumes $d$, then $T$ conforms to the - compound type `$U_1$ with $\ldots$ with $U_n$ {$R\,$}`. -- The existential type `$T$ forSome {$\,Q\,$}` conforms to - $U$ if its [skolemization](#existential-types) - conforms to $U$. -- The type $T$ conforms to the existential type `$U$ forSome {$\,Q\,$}` - if $T$ conforms to one of the [type instances](#existential-types) - of `$U$ forSome {$\,Q\,$}`. +- A singleton type `´p´.type` conforms to the type of the path ´p´. +- A singleton type `´p´.type` conforms to the type `scala.Singleton`. +- A type projection `´T´#´t´` conforms to `´U´#´t´` if ´T´ conforms to ´U´. +- A parameterized type `´T´[´T_1´ , … , ´T_n´]` conforms to + `´T´[´U_1´ , … , ´U_n´]` if + the following three conditions hold for ´i \in \{ 1 , \ldots , n \}´: + 1. If the ´i´'th type parameter of ´T´ is declared covariant, then + ´T_i <: U_i´. + 1. If the ´i´'th type parameter of ´T´ is declared contravariant, then + ´U_i <: T_i´. + 1. If the ´i´'th type parameter of ´T´ is declared neither covariant + nor contravariant, then ´U_i \equiv T_i´. +- A compound type `´T_1´ with ´\ldots´ with ´T_n´ {´R\,´}` conforms to + each of its component types ´T_i´. +- If ´T <: U_i´ for ´i \in \{ 1 , \ldots , n \}´ and for every + binding ´d´ of a type or value ´x´ in ´R´ there exists a member + binding of ´x´ in ´T´ which subsumes ´d´, then ´T´ conforms to the + compound type `´U_1´ with ´\ldots´ with ´U_n´ {´R\,´}`. +- The existential type `´T´ forSome {´\,Q\,´}` conforms to + ´U´ if its [skolemization](#existential-types) + conforms to ´U´. +- The type ´T´ conforms to the existential type `´U´ forSome {´\,Q\,´}` + if ´T´ conforms to one of the [type instances](#existential-types) + of `´U´ forSome {´\,Q\,´}`. - If - $T_i \equiv T_i'$ for $i \in \{ 1 , \ldots , n\}$ and $U$ conforms to $U'$ - then the method type $(p_1:T_1 , \ldots , p_n:T_n) U$ conforms to - $(p_1':T_1' , \ldots , p_n':T_n') U'$. + ´T_i \equiv T_i'´ for ´i \in \{ 1 , \ldots , n\}´ and ´U´ conforms to ´U'´ + then the method type ´(p_1:T_1 , \ldots , p_n:T_n) U´ conforms to + ´(p_1':T_1' , \ldots , p_n':T_n') U'´. - The polymorphic type - $[a_1 >: L_1 <: U_1 , \ldots , a_n >: L_n <: U_n] T$ conforms to the + ´[a_1 >: L_1 <: U_1 , \ldots , a_n >: L_n <: U_n] T´ conforms to the polymorphic type - $[a_1 >: L_1' <: U_1' , \ldots , a_n >: L_n' <: U_n'] T'$ if, assuming - $L_1' <: a_1 <: U_1' , \ldots , L_n' <: a_n <: U_n'$ - one has $T <: T'$ and $L_i <: L_i'$ and $U_i' <: U_i$ - for $i \in \{ 1 , \ldots , n \}$. -- Type constructors $T$ and $T'$ follow a similar discipline. We characterize - $T$ and $T'$ by their type parameter clauses - $[a_1 , \ldots , a_n]$ and - $[a_1' , \ldots , a_n']$, where an $a_i$ or $a_i'$ may include a variance - annotation, a higher-order type parameter clause, and bounds. Then, $T$ - conforms to $T'$ if any list $[t_1 , \ldots , t_n]$ -- with declared + ´[a_1 >: L_1' <: U_1' , \ldots , a_n >: L_n' <: U_n'] T'´ if, assuming + ´L_1' <: a_1 <: U_1' , \ldots , L_n' <: a_n <: U_n'´ + one has ´T <: T'´ and ´L_i <: L_i'´ and ´U_i' <: U_i´ + for ´i \in \{ 1 , \ldots , n \}´. +- Type constructors ´T´ and ´T'´ follow a similar discipline. We characterize + ´T´ and ´T'´ by their type parameter clauses + ´[a_1 , \ldots , a_n]´ and + ´[a_1' , \ldots , a_n']´, where an ´a_i´ or ´a_i'´ may include a variance + annotation, a higher-order type parameter clause, and bounds. Then, ´T´ + conforms to ´T'´ if any list ´[t_1 , \ldots , t_n]´ -- with declared variances, bounds and higher-order type parameter clauses -- of valid type - arguments for $T'$ is also a valid list of type arguments for $T$ and - $T[t_1 , \ldots , t_n] <: T'[t_1 , \ldots , t_n]$. Note that this entails + arguments for ´T'´ is also a valid list of type arguments for ´T´ and + ´T[t_1 , \ldots , t_n] <: T'[t_1 , \ldots , t_n]´. Note that this entails that: - - The bounds on $a_i$ must be weaker than the corresponding bounds declared - for $a'_i$. - - The variance of $a_i$ must match the variance of $a'_i$, where covariance + - The bounds on ´a_i´ must be weaker than the corresponding bounds declared + for ´a'_i´. + - The variance of ´a_i´ must match the variance of ´a'_i´, where covariance matches covariance, contravariance matches contravariance and any variance matches invariance. - Recursively, these restrictions apply to the corresponding higher-order - type parameter clauses of $a_i$ and $a'_i$. + type parameter clauses of ´a_i´ and ´a'_i´. -A declaration or definition in some compound type of class type $C$ +A declaration or definition in some compound type of class type ´C´ _subsumes_ another declaration of the same name in some compound type or class -type $C'$, if one of the following holds. - -- A value declaration or definition that defines a name $x$ with type $T$ - subsumes a value or method declaration that defines $x$ with type $T'$, provided - $T <: T'$. -- A method declaration or definition that defines a name $x$ with type $T$ - subsumes a method declaration that defines $x$ with type $T'$, provided - $T <: T'$. +type ´C'´, if one of the following holds. + +- A value declaration or definition that defines a name ´x´ with type ´T´ + subsumes a value or method declaration that defines ´x´ with type ´T'´, provided + ´T <: T'´. +- A method declaration or definition that defines a name ´x´ with type ´T´ + subsumes a method declaration that defines ´x´ with type ´T'´, provided + ´T <: T'´. - A type alias - `type $t$[$T_1$ , … , $T_n$] = $T$` subsumes a type alias - `type $t$[$T_1$ , … , $T_n$] = $T'$` if $T \equiv T'$. -- A type declaration `type $t$[$T_1$ , … , $T_n$] >: $L$ <: $U$` subsumes - a type declaration `type $t$[$T_1$ , … , $T_n$] >: $L'$ <: $U'$` if - $L' <: L$ and $U <: U'$. -- A type or class definition that binds a type name $t$ subsumes an abstract - type declaration `type t[$T_1$ , … , $T_n$] >: L <: U` if - $L <: t <: U$. + `type ´t´[´T_1´ , … , ´T_n´] = ´T´` subsumes a type alias + `type ´t´[´T_1´ , … , ´T_n´] = ´T'´` if ´T \equiv T'´. +- A type declaration `type ´t´[´T_1´ , … , ´T_n´] >: ´L´ <: ´U´` subsumes + a type declaration `type ´t´[´T_1´ , … , ´T_n´] >: ´L'´ <: ´U'´` if + ´L' <: L´ and ´U <: U'´. +- A type or class definition that binds a type name ´t´ subsumes an abstract + type declaration `type t[´T_1´ , … , ´T_n´] >: L <: U` if + ´L <: t <: U´. #### Least upper bounds and greatest lower bounds -The $(<:)$ relation forms pre-order between types, i.e. it is transitive and reflexive. +The ´(<:)´ relation forms pre-order between types, i.e. it is transitive and reflexive. This allows us to define _least upper bounds_ and _greatest lower bounds_ of a set of types in terms of that order. The least upper bound or greatest lower bound of a set of types does not always exist. For instance, consider the class definitions: @@ -965,26 +966,26 @@ free to pick any one of them. ### Weak Conformance In some situations Scala uses a more general conformance relation. -A type $S$ _weakly conforms_ to a type $T$, written $S <:_w T$, -if $S <: T$ or both $S$ and $T$ are primitive number types and $S$ precedes $T$ in the following ordering. +A type ´S´ _weakly conforms_ to a type ´T´, written ´S <:_w T´, +if ´S <: T´ or both ´S´ and ´T´ are primitive number types and ´S´ precedes ´T´ in the following ordering. ```scala -Byte $<:_w$ Short -Short $<:_w$ Int -Char $<:_w$ Int -Int $<:_w$ Long -Long $<:_w$ Float -Float $<:_w$ Double +Byte ´<:_w´ Short +Short ´<:_w´ Int +Char ´<:_w´ Int +Int ´<:_w´ Long +Long ´<:_w´ Float +Float ´<:_w´ Double ``` A _weak least upper bound_ is a least upper bound with respect to weak conformance. ### Compatibility -A type $T$ is _compatible_ to a type $U$ if $T$ (or its corresponding function type) [weakly conforms](#weak-conformance) to $U$ -after applying [eta-expansion](06-expressions.html#eta-expansion). If $T$ is a method type, it's converted to the corresponding function type. If the types do not weakly conform, the following alternatives are checked in order: - - [view application](07-implicits.html#views): there's an implicit view from $T$ to $U$; - - dropping by-name modifiers: if $U$ is of the shape `$=> U'$` (and $T$ is not), `$T <:_w U'$`; - - SAM conversion: if $T$ corresponds to a function type, and $U$ declares a single abstract method whose type [corresponds](06-expressions.html#sam-conversion) to the function type $U'$, `$T <:_w U'$`. +A type ´T´ is _compatible_ to a type ´U´ if ´T´ (or its corresponding function type) [weakly conforms](#weak-conformance) to ´U´ +after applying [eta-expansion](06-expressions.html#eta-expansion). If ´T´ is a method type, it's converted to the corresponding function type. If the types do not weakly conform, the following alternatives are checked in order: + - [view application](07-implicits.html#views): there's an implicit view from ´T´ to ´U´; + - dropping by-name modifiers: if ´U´ is of the shape `´=> U'´` (and ´T´ is not), `´T <:_w U'´`; + - SAM conversion: if ´T´ corresponds to a function type, and ´U´ declares a single abstract method whose type [corresponds](06-expressions.html#sam-conversion) to the function type ´U'´, `´T <:_w U'´`. @@ -514,14 +514,14 @@ abstract class P[+A, +B] { ``` With this variance annotation, type instances -of $P$ subtype covariantly with respect to their arguments. +of ´P´ subtype covariantly with respect to their arguments. For instance, ```scala P[IOException, String] <: P[Throwable, AnyRef] ``` -If the members of $P$ are mutable variables, +If the members of ´P´ are mutable variables, the same variance annotation becomes illegal. ```scala @@ -543,7 +543,7 @@ abstract class R[+A, +B](x: A, y: B) { ###### Example -The following variance annotation is illegal, since $a$ appears +The following variance annotation is illegal, since ´a´ appears in contravariant position in the parameter of `append`: ```scala @@ -595,14 +595,14 @@ ParamType ::= Type | Type ‘*’ ``` -A _function declaration_ has the form `def $f\,\mathit{psig}$: $T$`, where -$f$ is the function's name, $\mathit{psig}$ is its parameter -signature and $T$ is its result type. A _function definition_ -`def $f\,\mathit{psig}$: $T$ = $e$` also includes a _function body_ $e$, +A _function declaration_ has the form `def ´f\,\mathit{psig}´: ´T´`, where +´f´ is the function's name, ´\mathit{psig}´ is its parameter +signature and ´T´ is its result type. A _function definition_ +`def ´f\,\mathit{psig}´: ´T´ = ´e´` also includes a _function body_ ´e´, i.e. an expression which defines the function's result. A parameter -signature consists of an optional type parameter clause `[$\mathit{tps}\,$]`, +signature consists of an optional type parameter clause `[´\mathit{tps}\,´]`, followed by zero or more value parameter clauses -`($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$)`. Such a declaration or definition +`(´\mathit{ps}_1´)´\ldots´(´\mathit{ps}_n´)`. Such a declaration or definition introduces a value with a (possibly polymorphic) method type whose parameter types and result type are as given. @@ -612,31 +612,31 @@ result type, if one is given. If the function definition is not recursive, the result type may be omitted, in which case it is determined from the packed type of the function body. -A _type parameter clause_ $\mathit{tps}$ consists of one or more +A _type parameter clause_ ´\mathit{tps}´ consists of one or more [type declarations](#type-declarations-and-type-aliases), which introduce type parameters, possibly with bounds. The scope of a type parameter includes the whole signature, including any of the type parameter bounds as well as the function body, if it is present. -A _value parameter clause_ $\mathit{ps}$ consists of zero or more formal -parameter bindings such as `$x$: $T$` or `$x: T = e$`, which bind value +A _value parameter clause_ ´\mathit{ps}´ consists of zero or more formal +parameter bindings such as `´x´: ´T´` or `´x: T = e´`, which bind value parameters and associate them with their types. ### Default Arguments Each value parameter declaration may optionally define a default argument. The default argument -expression $e$ is type-checked with an expected type $T'$ obtained -by replacing all occurrences of the function's type parameters in $T$ by +expression ´e´ is type-checked with an expected type ´T'´ obtained +by replacing all occurrences of the function's type parameters in ´T´ by the undefined type. -For every parameter $p_{i,j}$ with a default argument a method named -`$f\$$default$\$$n` is generated which computes the default argument -expression. Here, $n$ denotes the parameter's position in the method +For every parameter ´p_{i,j}´ with a default argument a method named +`´f\$´default´\$´n` is generated which computes the default argument +expression. Here, ´n´ denotes the parameter's position in the method declaration. These methods are parametrized by the type parameter clause -`[$\mathit{tps}\,$]` and all value parameter clauses -`($\mathit{ps}_1$)$\ldots$($\mathit{ps}_{i-1}$)` preceding $p_{i,j}$. -The `$f\$$default$\$$n` methods are inaccessible for user programs. +`[´\mathit{tps}\,´]` and all value parameter clauses +`(´\mathit{ps}_1´)´\ldots´(´\mathit{ps}_{i-1}´)` preceding ´p_{i,j}´. +The `´f\$´default´\$´n` methods are inaccessible for user programs. ###### Example In the method @@ -651,11 +651,11 @@ and `T` is instantiated to `Int`. The methods computing the default arguments have the form: ```scala -def compare$\$$default$\$$1[T]: Int = 0 -def compare$\$$default$\$$2[T](a: T): T = a +def compare´\$´default´\$´1[T]: Int = 0 +def compare´\$´default´\$´2[T](a: T): T = a ``` -The scope of a formal value parameter name $x$ comprises all subsequent +The scope of a formal value parameter name ´x´ comprises all subsequent parameter clauses, as well as the method return type and the function body, if they are given. Both type parameter names and value parameter names must be pairwise distinct. @@ -685,8 +685,8 @@ ParamType ::= ‘=>’ Type ``` The type of a value parameter may be prefixed by `=>`, e.g. -`$x$: => $T$`. The type of such a parameter is then the -parameterless method type `=> $T$`. This indicates that the +`´x´: => ´T´`. The type of such a parameter is then the +parameterless method type `=> ´T´`. This indicates that the corresponding argument is not evaluated at the point of function application, but instead is evaluated at each use within the function. That is, the argument is evaluated using _call-by-name_. @@ -712,22 +712,22 @@ ParamType ::= Type ‘*’ ``` The last value parameter of a parameter section may be suffixed by -`'*'`, e.g. `(..., $x$:$T$*)`. The type of such a +`'*'`, e.g. `(..., ´x´:´T´*)`. The type of such a _repeated_ parameter inside the method is then the sequence type -`scala.Seq[$T$]`. Methods with repeated parameters -`$T$*` take a variable number of arguments of type $T$. -That is, if a method $m$ with type -`($p_1:T_1 , \ldots , p_n:T_n, p_s:S$*)$U$` is applied to arguments -$(e_1 , \ldots , e_k)$ where $k \geq n$, then $m$ is taken in that application -to have type $(p_1:T_1 , \ldots , p_n:T_n, p_s:S , \ldots , p_{s'}S)U$, with -$k - n$ occurrences of type -$S$ where any parameter names beyond $p_s$ are fresh. The only exception to +`scala.Seq[´T´]`. Methods with repeated parameters +`´T´*` take a variable number of arguments of type ´T´. +That is, if a method ´m´ with type +`(´p_1:T_1 , \ldots , p_n:T_n, p_s:S´*)´U´` is applied to arguments +´(e_1 , \ldots , e_k)´ where ´k \geq n´, then ´m´ is taken in that application +to have type ´(p_1:T_1 , \ldots , p_n:T_n, p_s:S , \ldots , p_{s'}S)U´, with +´k - n´ occurrences of type +´S´ where any parameter names beyond ´p_s´ are fresh. The only exception to this rule is if the last argument is marked to be a _sequence argument_ via a `_*` type -annotation. If $m$ above is applied to arguments -`($e_1 , \ldots , e_n, e'$: _*)`, then the type of $m$ in +annotation. If ´m´ above is applied to arguments +`(´e_1 , \ldots , e_n, e'´: _*)`, then the type of ´m´ in that application is taken to be -`($p_1:T_1, \ldots , p_n:T_n,p_{s}:$scala.Seq[$S$])`. +`(´p_1:T_1, \ldots , p_n:T_n,p_{s}:´scala.Seq[´S´])`. It is not allowed to define any default arguments in a parameter section with a repeated parameter. @@ -783,13 +783,13 @@ Special syntax exists for procedures, i.e. functions that return the `Unit` value `()`. A _procedure declaration_ is a function declaration where the result type is omitted. The result type is then implicitly completed to the -`Unit` type. E.g., `def $f$($\mathit{ps}$)` is equivalent to -`def $f$($\mathit{ps}$): Unit`. +`Unit` type. E.g., `def ´f´(´\mathit{ps}´)` is equivalent to +`def ´f´(´\mathit{ps}´): Unit`. A _procedure definition_ is a function definition where the result type and the equals sign are omitted; its defining expression must be a block. -E.g., `def $f$($\mathit{ps}$) {$\mathit{stats}$}` is equivalent to -`def $f$($\mathit{ps}$): Unit = {$\mathit{stats}$}`. +E.g., `def ´f´(´\mathit{ps}´) {´\mathit{stats}´}` is equivalent to +`def ´f´(´\mathit{ps}´): Unit = {´\mathit{stats}´}`. ###### Example Here is a declaration and a definition of a procedure named `write`: @@ -816,14 +816,14 @@ object Terminal extends Writer { ### Method Return Type Inference -A class member definition $m$ that overrides some other function $m'$ -in a base class of $C$ may leave out the return type, even if it is -recursive. In this case, the return type $R'$ of the overridden -function $m'$, seen as a member of $C$, is taken as the return type of -$m$ for each recursive invocation of $m$. That way, a type $R$ for the -right-hand side of $m$ can be determined, which is then taken as the -return type of $m$. Note that $R$ may be different from $R'$, as long -as $R$ conforms to $R'$. +A class member definition ´m´ that overrides some other function ´m'´ +in a base class of ´C´ may leave out the return type, even if it is +recursive. In this case, the return type ´R'´ of the overridden +function ´m'´, seen as a member of ´C´, is taken as the return type of +´m´ for each recursive invocation of ´m´. That way, a type ´R´ for the +right-hand side of ´m´ can be determined, which is then taken as the +return type of ´m´. Note that ´R´ may be different from ´R'´, as long +as ´R´ conforms to ´R'´. ###### Example Assume the following definitions: @@ -844,14 +844,14 @@ in `C`, even though the method is recursive. \label{sec:overloaded-defs} \todo{change} -An overloaded definition is a set of $n > 1$ value or function +An overloaded definition is a set of ´n > 1´ value or function definitions in the same statement sequence that define the same name, -binding it to types `$T_1 \commadots T_n$`, respectively. +binding it to types `´T_1 \commadots T_n´`, respectively. The individual definitions are called _alternatives_. Overloaded definitions may only appear in the statement sequence of a template. Alternatives always need to specify the type of the defined entity -completely. It is an error if the types of two alternatives $T_i$ and -$T_j$ have the same erasure (\sref{sec:erasure}). +completely. It is an error if the types of two alternatives ´T_i´ and +´T_j´ have the same erasure (\sref{sec:erasure}). \todo{Say something about bridge methods.} %This must be a well-formed @@ -867,36 +867,36 @@ ImportSelectors ::= ‘{’ {ImportSelector ‘,’} ImportSelector ::= id [‘=>’ id | ‘=>’ ‘_’] ``` -An import clause has the form `import $p$.$I$` where $p$ is a -[stable identifier](03-types.html#paths) and $I$ is an import expression. -The import expression determines a set of names of importable members of $p$ -which are made available without qualification. A member $m$ of $p$ is +An import clause has the form `import ´p´.´I´` where ´p´ is a +[stable identifier](03-types.html#paths) and ´I´ is an import expression. +The import expression determines a set of names of importable members of ´p´ +which are made available without qualification. A member ´m´ of ´p´ is _importable_ if it is [accessible](05-classes-and-objects.html#modifiers). The most general form of an import expression is a list of _import selectors_ ```scala -{ $x_1$ => $y_1 , \ldots , x_n$ => $y_n$, _ } +{ ´x_1´ => ´y_1 , \ldots , x_n´ => ´y_n´, _ } ``` -for $n \geq 0$, where the final wildcard `‘_’` may be absent. It -makes available each importable member `$p$.$x_i$` under the unqualified name -$y_i$. I.e. every import selector `$x_i$ => $y_i$` renames -`$p$.$x_i$` to -$y_i$. If a final wildcard is present, all importable members $z$ of -$p$ other than `$x_1 , \ldots , x_n,y_1 , \ldots , y_n$` are also made available +for ´n \geq 0´, where the final wildcard `‘_’` may be absent. It +makes available each importable member `´p´.´x_i´` under the unqualified name +´y_i´. I.e. every import selector `´x_i´ => ´y_i´` renames +`´p´.´x_i´` to +´y_i´. If a final wildcard is present, all importable members ´z´ of +´p´ other than `´x_1 , \ldots , x_n,y_1 , \ldots , y_n´` are also made available under their own unqualified names. Import selectors work in the same way for type and term members. For -instance, an import clause `import $p$.{$x$ => $y\,$}` renames the term -name `$p$.$x$` to the term name $y$ and the type name `$p$.$x$` -to the type name $y$. At least one of these two names must -reference an importable member of $p$. +instance, an import clause `import ´p´.{´x´ => ´y\,´}` renames the term +name `´p´.´x´` to the term name ´y´ and the type name `´p´.´x´` +to the type name ´y´. At least one of these two names must +reference an importable member of ´p´. If the target in an import selector is a wildcard, the import selector hides access to the source member. For instance, the import selector -`$x$ => _` “renames” $x$ to the wildcard symbol (which is +`´x´ => _` “renames” ´x´ to the wildcard symbol (which is unaccessible as a name in user programs), and thereby effectively -prevents unqualified access to $x$. This is useful if there is a +prevents unqualified access to ´x´. This is useful if there is a final wildcard in the same import selector list, which imports all members not mentioned in previous import selectors. @@ -906,21 +906,21 @@ enclosing block, template, package clause, or compilation unit, whichever comes first. Several shorthands exist. An import selector may be just a simple name -$x$. In this case, $x$ is imported without renaming, so the -import selector is equivalent to `$x$ => $x$`. Furthermore, it is +´x´. In this case, ´x´ is imported without renaming, so the +import selector is equivalent to `´x´ => ´x´`. Furthermore, it is possible to replace the whole import selector list by a single -identifier or wildcard. The import clause `import $p$.$x$` is -equivalent to `import $p$.{$x\,$}`, i.e. it makes available without -qualification the member $x$ of $p$. The import clause -`import $p$._` is equivalent to -`import $p$.{_}`, -i.e. it makes available without qualification all members of $p$ -(this is analogous to `import $p$.*` in Java). +identifier or wildcard. The import clause `import ´p´.´x´` is +equivalent to `import ´p´.{´x\,´}`, i.e. it makes available without +qualification the member ´x´ of ´p´. The import clause +`import ´p´._` is equivalent to +`import ´p´.{_}`, +i.e. it makes available without qualification all members of ´p´ +(this is analogous to `import ´p´.*` in Java). An import clause with multiple import expressions -`import $p_1$.$I_1 , \ldots , p_n$.$I_n$` is interpreted as a +`import ´p_1´.´I_1 , \ldots , p_n´.´I_n´` is interpreted as a sequence of import clauses -`import $p_1$.$I_1$; $\ldots$; import $p_n$.$I_n$`. +`import ´p_1´.´I_1´; ´\ldots´; import ´p_n´.´I_n´`. ###### Example Consider the object definition: diff --git a/spec/05-classes-and-objects.md b/spec/05-classes-and-objects.md index eced678cdce1..f05e2699447b 100644 --- a/spec/05-classes-and-objects.md +++ b/spec/05-classes-and-objects.md @@ -31,20 +31,20 @@ A _template_ defines the type signature, behavior and initial state of a trait or class of objects or of a single object. Templates form part of instance creation expressions, class definitions, and object definitions. A template -`$sc$ with $mt_1$ with $\ldots$ with $mt_n$ { $\mathit{stats}$ }` -consists of a constructor invocation $sc$ +`´sc´ with ´mt_1´ with ´\ldots´ with ´mt_n´ { ´\mathit{stats}´ }` +consists of a constructor invocation ´sc´ which defines the template's _superclass_, trait references -`$mt_1 , \ldots , mt_n$` $(n \geq 0)$, which define the -template's _traits_, and a statement sequence $\mathit{stats}$ which +`´mt_1 , \ldots , mt_n´` ´(n \geq 0)´, which define the +template's _traits_, and a statement sequence ´\mathit{stats}´ which contains initialization code and additional member definitions for the template. -Each trait reference $mt_i$ must denote a [trait](#traits). -By contrast, the superclass constructor $sc$ normally refers to a +Each trait reference ´mt_i´ must denote a [trait](#traits). +By contrast, the superclass constructor ´sc´ normally refers to a class which is not a trait. It is possible to write a list of parents that starts with a trait reference, e.g. -`$mt_1$ with $\ldots$ with $mt_n$`. In that case the list -of parents is implicitly extended to include the supertype of $mt_1$ +`´mt_1´ with ´\ldots´ with ´mt_n´`. In that case the list +of parents is implicitly extended to include the supertype of ´mt_1´ as the first parent type. The new supertype must have at least one constructor that does not take parameters. In the following, we will always assume that this implicit extension has been performed, so that @@ -52,8 +52,8 @@ the first parent class of a template is a regular superclass constructor, not a trait reference. The list of parents of a template must be well-formed. This means that -the class denoted by the superclass constructor $sc$ must be a -subclass of the superclasses of all the traits $mt_1 , \ldots , mt_n$. +the class denoted by the superclass constructor ´sc´ must be a +subclass of the superclasses of all the traits ´mt_1 , \ldots , mt_n´. In other words, the non-trait classes inherited by a template form a chain in the inheritance hierarchy which starts with the template's superclass. @@ -62,35 +62,34 @@ The _least proper supertype_ of a template is the class type or [compound type](03-types.html#compound-types) consisting of all its parent class types. -The statement sequence $\mathit{stats}$ contains member definitions that -define new members or override members in the parent classes. If the -template forms part of an abstract class or trait definition, then -$\mathit{stats}$ may also contain declarations of abstract members. -If the template forms part of a concrete class definition, -$\mathit{stats}$ may still contain declarations of abstract type members, but -not of abstract term members. Furthermore, $\mathit{stats}$ may in any case -also contain strictly evaluated expressions: these are executed in the order they are -given as part of the initialization of a template, even if they appear in -the definition of overridden members. +The statement sequence ´\mathit{stats}´ contains member definitions that +define new members or overwrite members in the parent classes. If the +template forms part of an abstract class or trait definition, the +statement part ´\mathit{stats}´ may also contain declarations of abstract +members. If the template forms part of a concrete class definition, +´\mathit{stats}´ may still contain declarations of abstract type members, but +not of abstract term members. Furthermore, ´\mathit{stats}´ may in any case +also contain expressions; these are executed in the order they are +given as part of the initialization of a template. The sequence of template statements may be prefixed with a formal -parameter definition and an arrow, e.g. `$x$ =>`, or -`$x$:$T$ =>`. If a formal parameter is given, it can be +parameter definition and an arrow, e.g. `´x´ =>`, or +`´x´:´T´ =>`. If a formal parameter is given, it can be used as an alias for the reference `this` throughout the body of the template. -If the formal parameter comes with a type $T$, this definition affects -the _self type_ $S$ of the underlying class or object as follows: Let $C$ be the type +If the formal parameter comes with a type ´T´, this definition affects +the _self type_ ´S´ of the underlying class or object as follows: Let ´C´ be the type of the class or trait or object defining the template. -If a type $T$ is given for the formal self parameter, $S$ -is the greatest lower bound of $T$ and $C$. -If no type $T$ is given, $S$ is just $C$. -Inside the template, the type of `this` is assumed to be $S$. +If a type ´T´ is given for the formal self parameter, ´S´ +is the greatest lower bound of ´T´ and ´C´. +If no type ´T´ is given, ´S´ is just ´C´. +Inside the template, the type of `this` is assumed to be ´S´. The self type of a class or object must conform to the self types of -all classes which are inherited by the template $t$. +all classes which are inherited by the template ´t´. A second form of self type annotation reads just -`this: $S$ =>`. It prescribes the type $S$ for `this` +`this: ´S´ =>`. It prescribes the type ´S´ for `this` without introducing an alias name for it. ###### Example @@ -116,21 +115,21 @@ A template may have a Java class as its superclass and Java interfaces as its mi **Template Evaluation** -Consider a template `$sc$ with $mt_1$ with $mt_n$ { $\mathit{stats}$ }`. +Consider a template `´sc´ with ´mt_1´ with ´mt_n´ { ´\mathit{stats}´ }`. If this is the template of a [trait](#traits) then its _mixin-evaluation_ -consists of an evaluation of the statement sequence $\mathit{stats}$. +consists of an evaluation of the statement sequence ´\mathit{stats}´. If this is not a template of a trait, then its _evaluation_ consists of the following steps. -- First, the superclass constructor $sc$ is +- First, the superclass constructor ´sc´ is [evaluated](#constructor-invocations). - Then, all base classes in the template's [linearization](#class-linearization) - up to the template's superclass denoted by $sc$ are + up to the template's superclass denoted by ´sc´ are mixin-evaluated. Mixin-evaluation happens in reverse order of occurrence in the linearization. -- Finally, the statement sequence $\mathit{stats}\,$ is evaluated. +- Finally, the statement sequence ´\mathit{stats}\,´ is evaluated. ###### Delayed Initialization This statement sequence constitutes the initialization code for an object @@ -157,46 +156,47 @@ Constructor invocations define the type, members, and initial state of objects created by an instance creation expression, or of parts of an object's definition which are inherited by a class or object definition. A constructor invocation is a function application -`$x$.$c$[$\mathit{targs}$]($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)`, where $x$ is a -[stable identifier](03-types.html#paths), $c$ is a type name which either designates a -class or defines an alias type for one, $\mathit{targs}$ is a type argument -list, $\mathit{args}_1 , \ldots , \mathit{args}_n$ are argument lists, and there is a +`´x´.´c´[´\mathit{targs}´](´\mathit{args}_1´)´\ldots´(´\mathit{args}_n´)`, where ´x´ is a +[stable identifier](03-types.html#paths), ´c´ is a type name which either designates a +class or defines an alias type for one, ´\mathit{targs}´ is a type argument +list, ´\mathit{args}_1 , \ldots , \mathit{args}_n´ are argument lists, and there is a constructor of that class which is [applicable](06-expressions.html#function-applications) to the given arguments. If the constructor invocation uses named or default arguments, it is transformed into a block expression using the same transformation as described [here](sec:named-default). -The prefix `$x$.` can be omitted. A type argument list -can be given only if the class $c$ takes type parameters. Even then +The prefix `´x´.` can be omitted. A type argument list +can be given only if the class ´c´ takes type parameters. Even then it can be omitted, in which case a type argument list is synthesized using [local type inference](06-expressions.html#local-type-inference). If no explicit arguments are given, an empty list `()` is implicitly supplied. An evaluation of a constructor invocation -`$x$.$c$[$\mathit{targs}$]($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)` +`´x´.´c´[´\mathit{targs}´](´\mathit{args}_1´)´\ldots´(´\mathit{args}_n´)` consists of the following steps: -- First, the prefix $x$ is evaluated. -- Then, the arguments $\mathit{args}_1 , \ldots , \mathit{args}_n$ are evaluated from +- First, the prefix ´x´ is evaluated. +- Then, the arguments ´\mathit{args}_1 , \ldots , \mathit{args}_n´ are evaluated from left to right. - Finally, the class being constructed is initialized by evaluating the - template of the class referred to by $c$. + template of the class referred to by ´c´. ### Class Linearization The classes reachable through transitive closure of the direct -inheritance relation from a class $C$ are called the _base classes_ of $C$. Because of mixins, the inheritance relationship +inheritance relation from a class ´C´ are called the _base classes_ of ´C´. Because of mixins, the inheritance relationship on base classes forms in general a directed acyclic graph. A linearization of this graph is defined as follows. ###### Definition: linearization -Let $C$ be a class with template -`$C_1$ with ... with $C_n$ { $\mathit{stats}$ }`. -The _linearization_ of $C$, $\mathcal{L}(C)$ is defined as follows: - -$$\mathcal{L}(C) = C, \mathcal{L}(C_n) \; \vec{+} \; \ldots \; \vec{+} \; \mathcal{L}(C_1)$$ +Let ´C´ be a class with template +´C_1´ with ... with ´C_n´ { ´\mathit{stats}´ }`. +The _linearization_ of ´C´, ´\mathcal{L}(C)´ is defined as follows: +$$ +\mathcal{L}(C) = C, \mathcal{L}(C_n) \; \vec{+} \; \ldots \; \vec{+} \; \mathcal{L}(C_1) +$$ -Here $\vec{+}$ denotes concatenation where elements of the right operand +Here ´\vec{+}´ denotes concatenation where elements of the right operand replace identical elements of the left operand: $$ @@ -223,8 +223,8 @@ Then the linearization of class `Iter` is ``` Note that the linearization of a class refines the inheritance -relation: if $C$ is a subclass of $D$, then $C$ precedes $D$ in any -linearization where both $C$ and $D$ occur. +relation: if ´C´ is a subclass of ´D´, then ´C´ precedes ´D´ in any +linearization where both ´C´ and ´D´ occur. [Linearization](#definition:-linearization) also satisfies the property that a linearization of a class always contains the linearization of its direct superclass as a suffix. @@ -246,57 +246,57 @@ which is not a suffix of the linearization of `Iter`. ### Class Members -A class $C$ defined by a template `$C_1$ with $\ldots$ with $C_n$ { $\mathit{stats}$ }` +A class ´C´ defined by a template `´C_1´ with ´\ldots´ with ´C_n´ { ´\mathit{stats}´ }` can define members in its statement sequence -$\mathit{stats}$ and can inherit members from all parent classes. Scala +´\mathit{stats}´ and can inherit members from all parent classes. Scala adopts Java and C\#'s conventions for static overloading of methods. It is thus possible that a class defines and/or inherits several methods with the same name. To decide whether a defined -member of a class $C$ overrides a member of a parent class, or whether -the two co-exist as overloaded variants in $C$, Scala uses the +member of a class ´C´ overrides a member of a parent class, or whether +the two co-exist as overloaded variants in ´C´, Scala uses the following definition of _matching_ on members: ###### Definition: matching -A member definition $M$ _matches_ a member definition $M'$, if $M$ -and $M'$ bind the same name, and one of following holds. +A member definition ´M´ _matches_ a member definition ´M'´, if ´M´ +and ´M'´ bind the same name, and one of following holds. -1. Neither $M$ nor $M'$ is a method definition. -2. $M$ and $M'$ define both monomorphic methods with equivalent argument types. -3. $M$ defines a parameterless method and $M'$ defines a method +1. Neither ´M´ nor ´M'´ is a method definition. +2. ´M´ and ´M'´ define both monomorphic methods with equivalent argument types. +3. ´M´ defines a parameterless method and ´M'´ defines a method with an empty parameter list `()` or _vice versa_. -4. $M$ and $M'$ define both polymorphic methods with - equal number of argument types $\overline T$, $\overline T'$ +4. ´M´ and ´M'´ define both polymorphic methods with + equal number of argument types ´\overline T´, ´\overline T'´ and equal numbers of type parameters - $\overline t$, $\overline t'$, say, and $\overline T' = [\overline t'/\overline t]\overline T$. + ´\overline t´, ´\overline t'´, say, and ´\overline T' = [\overline t'/\overline t]\overline T´. Member definitions fall into two categories: concrete and abstract. -Members of class $C$ are either _directly defined_ (i.e. they appear in -$C$'s statement sequence $\mathit{stats}$) or they are _inherited_. There are two rules +Members of class ´C´ are either _directly defined_ (i.e. they appear in +´C´'s statement sequence ´\mathit{stats}´) or they are _inherited_. There are two rules that determine the set of members of a class, one for each category: -A _concrete member_ of a class $C$ is any concrete definition $M$ in -some class $C_i \in \mathcal{L}(C)$, except if there is a preceding class -$C_j \in \mathcal{L}(C)$ where $j < i$ which directly defines a concrete -member $M'$ matching $M$. +A _concrete member_ of a class ´C´ is any concrete definition ´M´ in +some class ´C_i \in \mathcal{L}(C)´, except if there is a preceding class +´C_j \in \mathcal{L}(C)´ where ´j < i´ which directly defines a concrete +member ´M'´ matching ´M´. -An _abstract member_ of a class $C$ is any abstract definition $M$ -in some class $C_i \in \mathcal{L}(C)$, except if $C$ contains already a -concrete member $M'$ matching $M$, or if there is a preceding class -$C_j \in \mathcal{L}(C)$ where $j < i$ which directly defines an abstract -member $M'$ matching $M$. +An _abstract member_ of a class ´C´ is any abstract definition ´M´ +in some class ´C_i \in \mathcal{L}(C)´, except if ´C´ contains already a +concrete member ´M'´ matching ´M´, or if there is a preceding class +´C_j \in \mathcal{L}(C)´ where ´j < i´ which directly defines an abstract +member ´M'´ matching ´M´. This definition also determines the [overriding](#overriding) relationships -between matching members of a class $C$ and its parents. +between matching members of a class ´C´ and its parents. First, a concrete definition always overrides an abstract definition. -Second, for definitions $M$ and $M$' which are both concrete or both abstract, -$M$ overrides $M'$ if $M$ appears in a class that precedes (in the -linearization of $C$) the class in which $M'$ is defined. +Second, for definitions ´M´ and ´M´' which are both concrete or both abstract, +´M´ overrides ´M'´ if ´M´ appears in a class that precedes (in the +linearization of ´C´) the class in which ´M'´ is defined. It is an error if a template directly defines two matching members. It is also an error if a template contains two members (directly defined @@ -322,31 +322,31 @@ trait `B`. -A member $M$ of class $C$ that [matches](#class-members) -a non-private member $M'$ of a -base class of $C$ is said to _override_ that member. In this case -the binding of the overriding member $M$ must [subsume](03-types.html#conformance) -the binding of the overridden member $M'$. -Furthermore, the following restrictions on modifiers apply to $M$ and -$M'$: +A member ´M´ of class ´C´ that [matches](#class-members) +a non-private member ´M'´ of a +base class of ´C´ is said to _override_ that member. In this case +the binding of the overriding member ´M´ must [subsume](03-types.html#conformance) +the binding of the overridden member ´M'´. +Furthermore, the following restrictions on modifiers apply to ´M´ and +´M'´: -- $M'$ must not be labeled `final`. -- $M$ must not be [`private`](#modifiers). -- If $M$ is labeled `private[$C$]` for some enclosing class or package $C$, - then $M'$ must be labeled `private[$C'$]` for some class or package $C'$ where - $C'$ equals $C$ or $C'$ is contained in $C$. +- ´M'´ must not be labeled `final`. +- ´M´ must not be [`private`](#modifiers). +- If ´M´ is labeled `private[´C´]` for some enclosing class or package ´C´, + then ´M'´ must be labeled `private[´C'´]` for some class or package ´C'´ where + ´C'´ equals ´C´ or ´C'´ is contained in ´C´. -- If $M$ is labeled `protected`, then $M'$ must also be +- If ´M´ is labeled `protected`, then ´M'´ must also be labeled `protected`. -- If $M'$ is not an abstract member, then $M$ must be labeled `override`. +- If ´M'´ is not an abstract member, then ´M´ must be labeled `override`. Furthermore, one of two possibilities must hold: - - either $M$ is defined in a subclass of the class where is $M'$ is defined, - - or both $M$ and $M'$ override a third member $M''$ which is defined - in a base class of both the classes containing $M$ and $M'$ -- If $M'$ is [incomplete](#modifiers) in $C$ then $M$ must be + - either ´M´ is defined in a subclass of the class where is ´M'´ is defined, + - or both ´M´ and ´M'´ override a third member ´M''´ which is defined + in a base class of both the classes containing ´M´ and ´M'´ +- If ´M'´ is [incomplete](#modifiers) in ´C´ then ´M´ must be labeled `abstract override`. -- If $M$ and $M'$ are both concrete value definitions, then either none +- If ´M´ and ´M'´ are both concrete value definitions, then either none of them is marked `lazy` or both must be marked `lazy`. - A stable member can only be overridden by a stable member. @@ -363,8 +363,8 @@ bound may not override an abstract type member which does not have a volatile upper bound. A special rule concerns parameterless methods. If a parameterless -method defined as `def $f$: $T$ = ...` or `def $f$ = ...` overrides a method of -type $()T'$ which has an empty parameter list, then $f$ is also +method defined as `def ´f´: ´T´ = ...` or `def ´f´ = ...` overrides a method of +type ´()T'´ which has an empty parameter list, then ´f´ is also assumed to have an empty parameter list. An overriding method inherits all default arguments from the definition @@ -397,14 +397,14 @@ class C extends A with B { type T <: C } ### Inheritance Closure -Let $C$ be a class type. The _inheritance closure_ of $C$ is the -smallest set $\mathscr{S}$ of types such that +Let ´C´ be a class type. The _inheritance closure_ of ´C´ is the +smallest set ´\mathscr{S}´ of types such that -- $C$ is in $\mathscr{S}$. -- If $T$ is in $\mathscr{S}$, then every type $T'$ which forms syntactically - a part of $T$ is also in $\mathscr{S}$. -- If $T$ is a class type in $\mathscr{S}$, then all [parents](#templates) - of $T$ are also in $\mathscr{S}$. +- ´C´ is in ´\mathscr{S}´. +- If ´T´ is in ´\mathscr{S}´, then every type ´T'´ which forms syntactically + a part of ´T´ is also in ´\mathscr{S}´. +- If ´T´ is a class type in ´\mathscr{S}´, then all [parents](#templates) + of ´T´ are also in ´\mathscr{S}´. It is a static error if the inheritance closure of a class type consists of an infinite number of types. (This restriction is @@ -424,13 +424,13 @@ which serves to define certain field values before the supertype constructor is called. In a template ```scala -{ val $p_1$: $T_1$ = $e_1$ +{ val ´p_1´: ´T_1´ = ´e_1´ ... - val $p_n$: $T_n$ = $e_n$ -} with $sc$ with $mt_1$ with $mt_n$ { $\mathit{stats}$ } + val ´p_n´: ´T_n´ = ´e_n´ +} with ´sc´ with ´mt_1´ with ´mt_n´ { ´\mathit{stats}´ } ``` -The initial pattern definitions of $p_1 , \ldots , p_n$ are called +The initial pattern definitions of ´p_1 , \ldots , p_n´ are called _early definitions_. They define fields which form part of the template. Every early definition must define at least one variable. @@ -507,24 +507,24 @@ declaration in a template. Such members can be accessed only from within the directly enclosing template and its companion module or [companion class](#object-definitions). -A `private` modifier can be _qualified_ with an identifier $C$ (e.g. -`private[$C$]`) that must denote a class or package enclosing the definition. +A `private` modifier can be _qualified_ with an identifier ´C´ (e.g. +`private[´C´]`) that must denote a class or package enclosing the definition. Members labeled with such a modifier are accessible respectively only from code -inside the package $C$ or only from code inside the class $C$ and its +inside the package ´C´ or only from code inside the class ´C´ and its [companion module](#object-definitions). A different form of qualification is `private[this]`. A member -$M$ marked with this modifier is called _object-protected_; it can be accessed only from within -the object in which it is defined. That is, a selection $p.M$ is only -legal if the prefix is `this` or `$O$.this`, for some -class $O$ enclosing the reference. In addition, the restrictions for +´M´ marked with this modifier is called _object-protected_; it can be accessed only from within +the object in which it is defined. That is, a selection ´p.M´ is only +legal if the prefix is `this` or `´O´.this`, for some +class ´O´ enclosing the reference. In addition, the restrictions for unqualified `private` apply. Members marked private without a qualifier are called _class-private_, whereas members labeled with `private[this]` are called _object-private_. A member _is private_ if it is either class-private or object-private, but not if it is marked -`private[$C$]` where $C$ is an identifier; in the latter +`private[´C´]` where ´C´ is an identifier; in the latter case the member is called _qualified private_. Class-private or object-private members may not be abstract, and may @@ -538,27 +538,27 @@ Protected members of a class can be accessed from within - all templates that have the defining class as a base class, - the companion module of any of those classes. -A `protected` modifier can be qualified with an identifier $C$ (e.g. -`protected[$C$]`) that must denote a class or package enclosing the definition. +A `protected` modifier can be qualified with an identifier ´C´ (e.g. +`protected[´C´]`) that must denote a class or package enclosing the definition. Members labeled with such a modifier are also accessible respectively from all -code inside the package $C$ or from all code inside the class $C$ and its +code inside the package ´C´ or from all code inside the class ´C´ and its [companion module](#object-definitions). -A protected identifier $x$ may be used as a member name in a selection -`$r$.$x$` only if one of the following applies: +A protected identifier ´x´ may be used as a member name in a selection +`´r´.´x´` only if one of the following applies: - The access is within the template defining the member, or, if - a qualification $C$ is given, inside the package $C$, - or the class $C$, or its companion module, or - - $r$ is one of the reserved words `this` and + a qualification ´C´ is given, inside the package ´C´, + or the class ´C´, or its companion module, or + - ´r´ is one of the reserved words `this` and `super`, or - - $r$'s type conforms to a type-instance of the + - ´r´'s type conforms to a type-instance of the class which contains the access. A different form of qualification is `protected[this]`. A member -$M$ marked with this modifier is called _object-protected_; it can be accessed only from within -the object in which it is defined. That is, a selection $p.M$ is only -legal if the prefix is `this` or `$O$.this`, for some -class $O$ enclosing the reference. In addition, the restrictions for +´M´ marked with this modifier is called _object-protected_; it can be accessed only from within +the object in which it is defined. That is, a selection ´p.M´ is only +legal if the prefix is `this` or `´O´.this`, for some +class ´O´ enclosing the reference. In addition, the restrictions for unqualified `protected` apply. ### `override` @@ -573,10 +573,10 @@ The `override` modifier has an additional significance when combined with the `abstract` modifier. That modifier combination is only allowed for value members of traits. -We call a member $M$ of a template _incomplete_ if it is either +We call a member ´M´ of a template _incomplete_ if it is either abstract (i.e. defined by a declaration), or it is labeled `abstract` and `override` and -every member overridden by $M$ is again incomplete. +every member overridden by ´M´ is again incomplete. Note that the `abstract override` modifier combination does not influence the concept whether a member is concrete or abstract. A @@ -691,64 +691,64 @@ ClassTemplateOpt ::= ‘extends’ ClassTemplate | [[‘extends’] TemplateBo The most general form of class definition is ```scala -class $c$[$\mathit{tps}\,$] $as$ $m$($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$) extends $t$ $\quad(n \geq 0)$. +class ´c´[´\mathit{tps}\,´] ´as´ ´m´(´\mathit{ps}_1´)´\ldots´(´\mathit{ps}_n´) extends ´t´ ´\quad(n \geq 0)´. ``` Here, - - $c$ is the name of the class to be defined. - - $\mathit{tps}$ is a non-empty list of type parameters of the class + - ´c´ is the name of the class to be defined. + - ´\mathit{tps}´ is a non-empty list of type parameters of the class being defined. The scope of a type parameter is the whole class definition including the type parameter section itself. It is illegal to define two type parameters with the same name. The type - parameter section `[$\mathit{tps}\,$]` may be omitted. A class with a type + parameter section `[´\mathit{tps}\,´]` may be omitted. A class with a type parameter section is called _polymorphic_, otherwise it is called _monomorphic_. - - $as$ is a possibly empty sequence of + - ´as´ is a possibly empty sequence of [annotations](11-annotations.html#user-defined-annotations). If any annotations are given, they apply to the primary constructor of the class. - - $m$ is an [access modifier](#modifiers) such as + - ´m´ is an [access modifier](#modifiers) such as `private` or `protected`, possibly with a qualification. If such an access modifier is given it applies to the primary constructor of the class. - - $(\mathit{ps}\_1)\ldots(\mathit{ps}\_n)$ are formal value parameter clauses for + - ´(\mathit{ps}\_1)\ldots(\mathit{ps}\_n)´ are formal value parameter clauses for the _primary constructor_ of the class. The scope of a formal value parameter includes - all subsequent parameter sections and the template $t$. However, a formal - value parameter may not form part of the types of any of the parent classes or members of the class template $t$. + all subsequent parameter sections and the template ´t´. However, a formal + value parameter may not form part of the types of any of the parent classes or members of the class template ´t´. It is illegal to define two formal value parameters with the same name. If a class has no formal parameter section that is not implicit, an empty parameter section `()` is assumed. - If a formal parameter declaration $x: T$ is preceded by a `val` + If a formal parameter declaration ´x: T´ is preceded by a `val` or `var` keyword, an accessor (getter) [definition](04-basic-declarations-and-definitions.html#variable-declarations-and-definitions) for this parameter is implicitly added to the class. - The getter introduces a value member $x$ of class $c$ that is defined as an alias of the parameter. - If the introducing keyword is `var`, a setter accessor [`$x$_=`](04-basic-declarations-and-definitions.html#variable-declarations-and-definitions) is also implicitly added to the class. - In invocation of that setter `$x$_=($e$)` changes the value of the parameter to the result of evaluating $e$. + The getter introduces a value member ´x´ of class ´c´ that is defined as an alias of the parameter. + If the introducing keyword is `var`, a setter accessor [`´x´_=`](04-basic-declarations-and-definitions.html#variable-declarations-and-definitions) is also implicitly added to the class. + In invocation of that setter `´x´_=(´e´)` changes the value of the parameter to the result of evaluating ´e´. The formal parameter declaration may contain modifiers, which then carry over to the accessor definition(s). When access modifiers are given for a parameter, but no `val` or `var` keyword, `val` is assumed. A formal parameter prefixed by `val` or `var` may not at the same time be a [call-by-name parameter](04-basic-declarations-and-definitions.html#by-name-parameters). - - $t$ is a [template](#templates) of the form + - ´t´ is a [template](#templates) of the form ```scala - $sc$ with $mt_1$ with $\ldots$ with $mt_m$ { $\mathit{stats}$ } // $m \geq 0$ + ´sc´ with ´mt_1´ with ´\ldots´ with ´mt_m´ { ´\mathit{stats}´ } // ´m \geq 0´ ``` which defines the base classes, behavior and initial state of objects of the class. The extends clause - `extends $sc$ with $mt_1$ with $\ldots$ with $mt_m$` + `extends ´sc´ with ´mt_1´ with ´\ldots´ with ´mt_m´` can be omitted, in which case `extends scala.AnyRef` is assumed. The class body - `{ $\mathit{stats}$ }` may also be omitted, in which case the empty body + `{ ´\mathit{stats}´ }` may also be omitted, in which case the empty body `{}` is assumed. -This class definition defines a type `$c$[$\mathit{tps}\,$]` and a constructor -which when applied to parameters conforming to types $\mathit{ps}$ -initializes instances of type `$c$[$\mathit{tps}\,$]` by evaluating the template -$t$. +This class definition defines a type `´c´[´\mathit{tps}\,´]` and a constructor +which when applied to parameters conforming to types ´\mathit{ps}´ +initializes instances of type `´c´[´\mathit{tps}\,´]` by evaluating the template +´t´. ###### Example – `val` and `var` parameters The following example illustrates `val` and `var` parameters of a class `C`: @@ -786,19 +786,19 @@ SelfInvocation ::= ‘this’ ArgumentExprs {ArgumentExprs} A class may have additional constructors besides the primary constructor. These are defined by constructor definitions of the form -`def this($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$) = $e$`. Such a +`def this(´\mathit{ps}_1´)´\ldots´(´\mathit{ps}_n´) = ´e´`. Such a definition introduces an additional constructor for the enclosing -class, with parameters as given in the formal parameter lists $\mathit{ps}_1 -, \ldots , \mathit{ps}_n$, and whose evaluation is defined by the constructor -expression $e$. The scope of each formal parameter is the subsequent +class, with parameters as given in the formal parameter lists ´\mathit{ps}_1 +, \ldots , \mathit{ps}_n´, and whose evaluation is defined by the constructor +expression ´e´. The scope of each formal parameter is the subsequent parameter sections and the constructor -expression $e$. A constructor expression is either a self constructor -invocation `this($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)` or a block +expression ´e´. A constructor expression is either a self constructor +invocation `this(´\mathit{args}_1´)´\ldots´(´\mathit{args}_n´)` or a block which begins with a self constructor invocation. The self constructor invocation must construct a generic instance of the class. I.e. if the -class in question has name $C$ and type parameters -`[$\mathit{tps}\,$]`, then a self constructor invocation must -generate an instance of `$C$[$\mathit{tps}\,$]`; it is not permitted +class in question has name ´C´ and type parameters +`[´\mathit{tps}\,´]`, then a self constructor invocation must +generate an instance of `´C´[´\mathit{tps}\,´]`; it is not permitted to instantiate formal type parameters. The signature and the self constructor invocation of a constructor @@ -810,12 +810,12 @@ The rest of the constructor expression is type-checked and evaluated as a function body in the current class. -If there are auxiliary constructors of a class $C$, they form together -with $C$'s primary [constructor](#class-definitions) +If there are auxiliary constructors of a class ´C´, they form together +with ´C´'s primary [constructor](#class-definitions) an overloaded constructor definition. The usual rules for [overloading resolution](06-expressions.html#overloading-resolution) -apply for constructor invocations of $C$, +apply for constructor invocations of ´C´, including for the self constructor invocations in the constructor expressions themselves. However, unlike other methods, constructors are never inherited. To prevent infinite cycles of constructor @@ -858,43 +858,43 @@ implicitly added to such a parameter, unless the parameter already carries a `val` or `var` modifier. Hence, an accessor definition for the parameter is [generated](#class-definitions). -A case class definition of `$c$[$\mathit{tps}\,$]($\mathit{ps}_1\,$)$\ldots$($\mathit{ps}_n$)` with type -parameters $\mathit{tps}$ and value parameters $\mathit{ps}$ implies +A case class definition of `´c´[´\mathit{tps}\,´](´\mathit{ps}_1\,´)´\ldots´(´\mathit{ps}_n´)` with type +parameters ´\mathit{tps}´ and value parameters ´\mathit{ps}´ implies the definition of a companion object, which serves as an [extractor object](08-pattern-matching.html#extractor-patterns). It has the following shape: ```scala -object $c$ { - def apply[$\mathit{tps}\,$]($\mathit{ps}_1\,$)$\ldots$($\mathit{ps}_n$): $c$[$\mathit{tps}\,$] = new $c$[$\mathit{Ts}\,$]($\mathit{xs}_1\,$)$\ldots$($\mathit{xs}_n$) - def unapply[$\mathit{tps}\,$]($x$: $c$[$\mathit{tps}\,$]) = +object ´c´ { + def apply[´\mathit{tps}\,´](´\mathit{ps}_1\,´)´\ldots´(´\mathit{ps}_n´): ´c´[´\mathit{tps}\,´] = new ´c´[´\mathit{Ts}\,´](´\mathit{xs}_1\,´)´\ldots´(´\mathit{xs}_n´) + def unapply[´\mathit{tps}\,´](´x´: ´c´[´\mathit{tps}\,´]) = if (x eq null) scala.None - else scala.Some($x.\mathit{xs}_{11}, \ldots , x.\mathit{xs}_{1k}$) + else scala.Some(´x.\mathit{xs}_{11}, \ldots , x.\mathit{xs}_{1k}´) } ``` -Here, $\mathit{Ts}$ stands for the vector of types defined in the type -parameter section $\mathit{tps}$, -each $\mathit{xs}\_i$ denotes the parameter names of the parameter -section $\mathit{ps}\_i$, and -$\mathit{xs}\_{11}, \ldots , \mathit{xs}\_{1k}$ denote the names of all parameters -in the first parameter section $\mathit{xs}\_1$. +Here, ´\mathit{Ts}´ stands for the vector of types defined in the type +parameter section ´\mathit{tps}´, +each ´\mathit{xs}\_i´ denotes the parameter names of the parameter +section ´\mathit{ps}\_i´, and +´\mathit{xs}\_{11}, \ldots , \mathit{xs}\_{1k}´ denote the names of all parameters +in the first parameter section ´\mathit{xs}\_1´. If a type parameter section is missing in the class, it is also missing in the `apply` and `unapply` methods. -If the companion object $c$ is already defined, +If the companion object ´c´ is already defined, the `apply` and `unapply` methods are added to the existing object. -If the object $c$ already has a [matching](#definition-matching) +If the object ´c´ already has a [matching](#definition-matching) `apply` (or `unapply`) member, no new definition is added. -The definition of `apply` is omitted if class $c$ is `abstract`. +The definition of `apply` is omitted if class ´c´ is `abstract`. If the case class definition contains an empty value parameter list, the `unapply` method returns a `Boolean` instead of an `Option` type and is defined as follows: ```scala -def unapply[$\mathit{tps}\,$]($x$: $c$[$\mathit{tps}\,$]) = x ne null +def unapply[´\mathit{tps}\,´](´x´: ´c´[´\mathit{tps}\,´]) = x ne null ``` The name of the `unapply` method is changed to `unapplySeq` if the first -parameter section $\mathit{ps}_1$ of $c$ ends in a +parameter section ´\mathit{ps}_1´ of ´c´ ends in a [repeated parameter](04-basic-declarations-and-definitions.html#repeated-parameters). A method named `copy` is implicitly added to every case class unless the @@ -902,15 +902,15 @@ class already has a member (directly defined or inherited) with that name, or th class has a repeated parameter. The method is defined as follows: ```scala -def copy[$\mathit{tps}\,$]($\mathit{ps}'_1\,$)$\ldots$($\mathit{ps}'_n$): $c$[$\mathit{tps}\,$] = new $c$[$\mathit{Ts}\,$]($\mathit{xs}_1\,$)$\ldots$($\mathit{xs}_n$) +def copy[´\mathit{tps}\,´](´\mathit{ps}'_1\,´)´\ldots´(´\mathit{ps}'_n´): ´c´[´\mathit{tps}\,´] = new ´c´[´\mathit{Ts}\,´](´\mathit{xs}_1\,´)´\ldots´(´\mathit{xs}_n´) ``` -Again, `$\mathit{Ts}$` stands for the vector of types defined in the type parameter section `$\mathit{tps}$` -and each `$xs_i$` denotes the parameter names of the parameter section `$ps'_i$`. The value -parameters `$ps'_{1,j}$` of first parameter list have the form `$x_{1,j}$:$T_{1,j}$=this.$x_{1,j}$`, -the other parameters `$ps'_{i,j}$` of the `copy` method are defined as `$x_{i,j}$:$T_{i,j}$`. -In all cases `$x_{i,j}$` and `$T_{i,j}$` refer to the name and type of the corresponding class parameter -`$\mathit{ps}_{i,j}$`. +Again, `´\mathit{Ts}´` stands for the vector of types defined in the type parameter section `´\mathit{tps}´` +and each `´xs_i´` denotes the parameter names of the parameter section `´ps'_i´`. The value +parameters `´ps'_{1,j}´` of first parameter list have the form `´x_{1,j}´:´T_{1,j}´=this.´x_{1,j}´`, +the other parameters `´ps'_{i,j}´` of the `copy` method are defined as `´x_{i,j}´:´T_{i,j}´`. +In all cases `´x_{i,j}´` and `´T_{i,j}´` refer to the name and type of the corresponding class parameter +`´\mathit{ps}_{i,j}´`. Every case class implicitly overrides some method definitions of class [`scala.AnyRef`](12-the-scala-standard-library.html#root-classes) unless a definition of the same @@ -984,14 +984,14 @@ constructor parameters. Furthermore, no constructor arguments are passed to the superclass of the trait. This is not necessary as traits are initialized after the superclass is initialized. -Assume a trait $D$ defines some aspect of an instance $x$ of type $C$ (i.e. $D$ is a base class of $C$). -Then the _actual supertype_ of $D$ in $x$ is the compound type consisting of all the -base classes in $\mathcal{L}(C)$ that succeed $D$. The actual supertype gives +Assume a trait ´D´ defines some aspect of an instance ´x´ of type ´C´ (i.e. ´D´ is a base class of ´C´). +Then the _actual supertype_ of ´D´ in ´x´ is the compound type consisting of all the +base classes in ´\mathcal{L}(C)´ that succeed ´D´. The actual supertype gives the context for resolving a [`super` reference](06-expressions.html#this-and-super) in a trait. Note that the actual supertype depends on the type to which the trait is added in a mixin composition; it is not statically known at the time the trait is defined. -If $D$ is not a trait, then its actual supertype is simply its +If ´D´ is not a trait, then its actual supertype is simply its least proper supertype (which is statically known). ###### Example @@ -1082,37 +1082,37 @@ ObjectDef ::= id ClassTemplate An _object definition_ defines a single object of a new class. Its most general form is -`object $m$ extends $t$`. Here, -$m$ is the name of the object to be defined, and -$t$ is a [template](#templates) of the form +`object ´m´ extends ´t´`. Here, +´m´ is the name of the object to be defined, and +´t´ is a [template](#templates) of the form ```scala -$sc$ with $mt_1$ with $\ldots$ with $mt_n$ { $\mathit{stats}$ } +´sc´ with ´mt_1´ with ´\ldots´ with ´mt_n´ { ´\mathit{stats}´ } ``` -which defines the base classes, behavior and initial state of $m$. -The extends clause `extends $sc$ with $mt_1$ with $\ldots$ with $mt_n$` +which defines the base classes, behavior and initial state of ´m´. +The extends clause `extends ´sc´ with ´mt_1´ with ´\ldots´ with ´mt_n´` can be omitted, in which case `extends scala.AnyRef` is assumed. The class body -`{ $\mathit{stats}$ }` may also be omitted, in which case the empty body +`{ ´\mathit{stats}´ }` may also be omitted, in which case the empty body `{}` is assumed. The object definition defines a single object (or: _module_) -conforming to the template $t$. It is roughly equivalent to the +conforming to the template ´t´. It is roughly equivalent to the following definition of a lazy value: ```scala -lazy val $m$ = new $sc$ with $mt_1$ with $\ldots$ with $mt_n$ { this: $m.type$ => $\mathit{stats}$ } +lazy val ´m´ = new ´sc´ with ´mt_1´ with ´\ldots´ with ´mt_n´ { this: ´m.type´ => ´\mathit{stats}´ } ``` Note that the value defined by an object definition is instantiated -lazily. The `new $m$\$cls` constructor is evaluated +lazily. The `new ´m´$cls` constructor is evaluated not at the point of the object definition, but is instead evaluated -the first time $m$ is dereferenced during execution of the program -(which might be never at all). An attempt to dereference $m$ again +the first time ´m´ is dereferenced during execution of the program +(which might be never at all). An attempt to dereference ´m´ again during evaluation of the constructor will lead to an infinite loop or run-time error. -Other threads trying to dereference $m$ while the +Other threads trying to dereference ´m´ while the constructor is being evaluated block until evaluation is complete. The expansion given above is not accurate for top-level objects. It @@ -1143,9 +1143,9 @@ name `Point` in the type name space, whereas the object definition defines a name in the term namespace. This technique is applied by the Scala compiler when interpreting a -Java class with static members. Such a class $C$ is conceptually seen -as a pair of a Scala class that contains all instance members of $C$ -and a Scala object that contains all static members of $C$. +Java class with static members. Such a class ´C´ is conceptually seen +as a pair of a Scala class that contains all instance members of ´C´ +and a Scala object that contains all static members of ´C´. Generally, a _companion module_ of a class is an object which has the same name as the class and is defined in the same scope and diff --git a/spec/06-expressions.md b/spec/06-expressions.md index 5176d7b02007..905fa5bf4925 100644 --- a/spec/06-expressions.md +++ b/spec/06-expressions.md @@ -52,22 +52,22 @@ discussed subsequently in decreasing order of precedence. ## Expression Typing -The typing of expressions is often relative to some _expected type_ (which might be undefined). When we write "expression $e$ is expected to conform to type $T$", we mean: - 1. the expected type of $e$ is $T$, and - 2. the type of expression $e$ must conform to $T$. +The typing of expressions is often relative to some _expected type_ (which might be undefined). When we write "expression ´e´ is expected to conform to type ´T´", we mean: + 1. the expected type of ´e´ is ´T´, and + 2. the type of expression ´e´ must conform to ´T´. The following skolemization rule is applied universally for every expression: If the type of an expression would be an existential type -$T$, then the type of the expression is assumed instead to be a -[skolemization](03-types.html#existential-types) of $T$. +´T´, then the type of the expression is assumed instead to be a +[skolemization](03-types.html#existential-types) of ´T´. -Skolemization is reversed by type packing. Assume an expression $e$ of -type $T$ and let $t_1[\mathit{tps}\_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}\_n] >: L_n <: U_n$ be -all the type variables created by skolemization of some part of $e$ which are free in $T$. -Then the _packed type_ of $e$ is +Skolemization is reversed by type packing. Assume an expression ´e´ of +type ´T´ and let ´t_1[\mathit{tps}\_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}\_n] >: L_n <: U_n´ be +all the type variables created by skolemization of some part of ´e´ which are free in ´T´. +Then the _packed type_ of ´e´ is ```scala -$T$ forSome { type $t_1[\mathit{tps}\_1] >: L_1 <: U_1$; $\ldots$; type $t_n[\mathit{tps}\_n] >: L_n <: U_n$ }. +´T´ forSome { type ´t_1[\mathit{tps}\_1] >: L_1 <: U_1´; ´\ldots´; type ´t_n[\mathit{tps}\_n] >: L_n <: U_n´ }. ``` ## Literals @@ -85,12 +85,12 @@ The `null` value is of type `scala.Null`, and thus conforms to every reference t It denotes a reference value which refers to a special `null` object. This object implements methods in class `scala.AnyRef` as follows: -- `eq($x\,$)` and `==($x\,$)` return `true` iff the - argument $x$ is also the "null" object. -- `ne($x\,$)` and `!=($x\,$)` return true iff the +- `eq(´x\,´)` and `==(´x\,´)` return `true` iff the + argument ´x´ is also the "null" object. +- `ne(´x\,´)` and `!=(´x\,´)` return true iff the argument x is not also the "null" object. -- `isInstanceOf[$T\,$]` always returns `false`. -- `asInstanceOf[$T\,$]` returns the [default value](04-basic-declarations-and-definitions.html#value-declarations-and-definitions) of type $T$. +- `isInstanceOf[´T\,´]` always returns `false`. +- `asInstanceOf[´T\,´]` returns the [default value](04-basic-declarations-and-definitions.html#value-declarations-and-definitions) of type ´T´. - `##` returns ``0``. A reference to any other member of the "null" object causes a @@ -106,47 +106,47 @@ SimpleExpr ::= Path A designator refers to a named term. It can be a _simple name_ or a _selection_. -A simple name $x$ refers to a value as specified +A simple name ´x´ refers to a value as specified [here](02-identifiers-names-and-scopes.html#identifiers,-names-and-scopes). -If $x$ is bound by a definition or declaration in an enclosing class -or object $C$, it is taken to be equivalent to the selection -`$C$.this.$x$` where $C$ is taken to refer to the class containing $x$ -even if the type name $C$ is [shadowed](02-identifiers-names-and-scopes.html#identifiers,-names-and-scopes) at the -occurrence of $x$. +If ´x´ is bound by a definition or declaration in an enclosing class +or object ´C´, it is taken to be equivalent to the selection +`´C´.this.´x´` where ´C´ is taken to refer to the class containing ´x´ +even if the type name ´C´ is [shadowed](02-identifiers-names-and-scopes.html#identifiers,-names-and-scopes) at the +occurrence of ´x´. -If $r$ is a [stable identifier](03-types.html#paths) of type $T$, the selection $r.x$ refers -statically to a term member $m$ of $r$ that is identified in $T$ by -the name $x$. +If ´r´ is a [stable identifier](03-types.html#paths) of type ´T´, the selection ´r.x´ refers +statically to a term member ´m´ of ´r´ that is identified in ´T´ by +the name ´x´. -For other expressions $e$, $e.x$ is typed as -if it was `{ val $y$ = $e$; $y$.$x$ }`, for some fresh name -$y$. +For other expressions ´e´, ´e.x´ is typed as +if it was `{ val ´y´ = ´e´; ´y´.´x´ }`, for some fresh name +´y´. The expected type of a designator's prefix is always undefined. The -type of a designator is the type $T$ of the entity it refers to, with -the following exception: The type of a [path](03-types.html#paths) $p$ +type of a designator is the type ´T´ of the entity it refers to, with +the following exception: The type of a [path](03-types.html#paths) ´p´ which occurs in a context where a [stable type](03-types.html#singleton-types) -is required is the singleton type `$p$.type`. +is required is the singleton type `´p´.type`. The contexts where a stable type is required are those that satisfy one of the following conditions: -1. The path $p$ occurs as the prefix of a selection and it does not +1. The path ´p´ occurs as the prefix of a selection and it does not designate a constant, or -1. The expected type $\mathit{pt}$ is a stable type, or -1. The expected type $\mathit{pt}$ is an abstract type with a stable type as lower - bound, and the type $T$ of the entity referred to by $p$ does not - conform to $\mathit{pt}$, or -1. The path $p$ designates a module. +1. The expected type ´\mathit{pt}´ is a stable type, or +1. The expected type ´\mathit{pt}´ is an abstract type with a stable type as lower + bound, and the type ´T´ of the entity referred to by ´p´ does not + conform to ´\mathit{pt}´, or +1. The path ´p´ designates a module. -The selection $e.x$ is evaluated by first evaluating the qualifier -expression $e$, which yields an object $r$, say. The selection's -result is then the member of $r$ that is either defined by $m$ or defined -by a definition overriding $m$. +The selection ´e.x´ is evaluated by first evaluating the qualifier +expression ´e´, which yields an object ´r´, say. The selection's +result is then the member of ´r´ that is either defined by ´m´ or defined +by a definition overriding ´m´. ## This and Super @@ -160,46 +160,46 @@ template or compound type. It stands for the object being defined by the innermost template or compound type enclosing the reference. If this is a compound type, the type of `this` is that compound type. If it is a template of a -class or object definition with simple name $C$, the type of this -is the same as the type of `$C$.this`. +class or object definition with simple name ´C´, the type of this +is the same as the type of `´C´.this`. -The expression `$C$.this` is legal in the statement part of an -enclosing class or object definition with simple name $C$. It +The expression `´C´.this` is legal in the statement part of an +enclosing class or object definition with simple name ´C´. It stands for the object being defined by the innermost such definition. If the expression's expected type is a stable type, or -`$C$.this` occurs as the prefix of a selection, its type is -`$C$.this.type`, otherwise it is the self type of class $C$. +`´C´.this` occurs as the prefix of a selection, its type is +`´C´.this.type`, otherwise it is the self type of class ´C´. -A reference `super.$m$` refers statically to a method or type $m$ +A reference `super.´m´` refers statically to a method or type ´m´ in the least proper supertype of the innermost template containing the -reference. It evaluates to the member $m'$ in the actual supertype of -that template which is equal to $m$ or which overrides $m$. The -statically referenced member $m$ must be a type or a +reference. It evaluates to the member ´m'´ in the actual supertype of +that template which is equal to ´m´ or which overrides ´m´. The +statically referenced member ´m´ must be a type or a method. If it is a method, it must be concrete, or the template -containing the reference must have a member $m'$ which overrides $m$ +containing the reference must have a member ´m'´ which overrides ´m´ and which is labeled `abstract override`. -A reference `$C$.super.$m$` refers statically to a method -or type $m$ in the least proper supertype of the innermost enclosing class or -object definition named $C$ which encloses the reference. It evaluates -to the member $m'$ in the actual supertype of that class or object -which is equal to $m$ or which overrides $m$. The -statically referenced member $m$ must be a type or a +A reference `´C´.super.´m´` refers statically to a method +or type ´m´ in the least proper supertype of the innermost enclosing class or +object definition named ´C´ which encloses the reference. It evaluates +to the member ´m'´ in the actual supertype of that class or object +which is equal to ´m´ or which overrides ´m´. The +statically referenced member ´m´ must be a type or a method. If the statically -referenced member $m$ is a method, it must be concrete, or the innermost enclosing -class or object definition named $C$ must have a member $m'$ which -overrides $m$ and which is labeled `abstract override`. +referenced member ´m´ is a method, it must be concrete, or the innermost enclosing +class or object definition named ´C´ must have a member ´m'´ which +overrides ´m´ and which is labeled `abstract override`. The `super` prefix may be followed by a trait qualifier -`[$T\,$]`, as in `$C$.super[$T\,$].$x$`. This is +`[´T\,´]`, as in `´C´.super[´T\,´].´x´`. This is called a _static super reference_. In this case, the reference is -to the type or method of $x$ in the parent trait of $C$ whose simple -name is $T$. That member must be uniquely defined. If it is a method, +to the type or method of ´x´ in the parent trait of ´C´ whose simple +name is ´T´. That member must be uniquely defined. If it is a method, it must be concrete. ###### Example @@ -245,24 +245,24 @@ ArgumentExprs ::= ‘(’ [Exprs] ‘)’ Exprs ::= Expr {‘,’ Expr} ``` -An application `$f(e_1 , \ldots , e_m)$` applies the function `$f$` to the argument expressions `$e_1, \ldots , e_m$`. For this expression to be well-typed, the function must be *applicable* to its arguments, which is defined next by case analysis on $f$'s type. +An application `´f(e_1 , \ldots , e_m)´` applies the function `´f´` to the argument expressions `´e_1, \ldots , e_m´`. For this expression to be well-typed, the function must be *applicable* to its arguments, which is defined next by case analysis on ´f´'s type. -If $f$ has a method type `($p_1$:$T_1 , \ldots , p_n$:$T_n$)$U$`, each argument expression $e_i$ is typed with the corresponding parameter type $T_i$ as expected type. Let $S_i$ be the type of argument $e_i$ $(i = 1 , \ldots , m)$. The method $f$ must be _applicable_ to its arguments $e_1, \ldots , e_n$ of types $S_1 , \ldots , S_n$. We say that an argument expression $e_i$ is a _named_ argument if it has the form `$x_i=e'_i$` and `$x_i$` is one of the parameter names `$p_1, \ldots, p_n$`. +If ´f´ has a method type `(´p_1´:´T_1 , \ldots , p_n´:´T_n´)´U´`, each argument expression ´e_i´ is typed with the corresponding parameter type ´T_i´ as expected type. Let ´S_i´ be the type of argument ´e_i´ ´(i = 1 , \ldots , m)´. The method ´f´ must be _applicable_ to its arguments ´e_1, \ldots , e_n´ of types ´S_1 , \ldots , S_n´. We say that an argument expression ´e_i´ is a _named_ argument if it has the form `´x_i=e'_i´` and `´x_i´` is one of the parameter names `´p_1, \ldots, p_n´`. -Once the types $S_i$ have been determined, the method $f$ of the above method type is said to be applicable if all of the following conditions hold: - - for every named argument $p_j=e_i'$ the type $S_i$ is [compatible](03-types.html#compatibility) with the parameter type $T_j$; - - for every positional argument $e_i$ the type $S_i$ is [compatible](03-types.html#compatibility) with $T_i$; - - if the expected type is defined, the result type $U$ is [compatible](03-types.html#compatibility) to it. +Once the types ´S_i´ have been determined, the method ´f´ of the above method type is said to be applicable if all of the following conditions hold: + - for every named argument ´p_j=e_i'´ the type ´S_i´ is [compatible](03-types.html#compatibility) with the parameter type ´T_j´; + - for every positional argument ´e_i´ the type ´S_i´ is [compatible](03-types.html#compatibility) with ´T_i´; + - if the expected type is defined, the result type ´U´ is [compatible](03-types.html#compatibility) to it. -If $f$ is a polymorphic method, [local type inference](#local-type-inference) is used to instantiate $f$'s type parameters. +If ´f´ is a polymorphic method, [local type inference](#local-type-inference) is used to instantiate ´f´'s type parameters. The polymorphic method is applicable if type inference can determine type arguments so that the instantiated method is applicable. -If $f$ has some value type, the application is taken to be equivalent to `$f$.apply($e_1 , \ldots , e_m$)`, -i.e. the application of an `apply` method defined by $f$. The value `$f$` is applicable to the given arguments if `$f$.apply` is applicable. +If ´f´ has some value type, the application is taken to be equivalent to `´f´.apply(´e_1 , \ldots , e_m´)`, +i.e. the application of an `apply` method defined by ´f´. The value `´f´` is applicable to the given arguments if `´f´.apply` is applicable. -Evaluation of `$f$($e_1 , \ldots , e_n$)` usually entails evaluation of -$f$ and $e_1 , \ldots , e_n$ in that order. Each argument expression +Evaluation of `´f´(´e_1 , \ldots , e_n´)` usually entails evaluation of +´f´ and ´e_1 , \ldots , e_n´ in that order. Each argument expression is converted to the type of its corresponding formal parameter. After that, the application is rewritten to the function's right hand side, with actual arguments substituted for formal parameters. The result @@ -270,29 +270,29 @@ of evaluating the rewritten right-hand side is finally converted to the function's declared result type, if one is given. The case of a formal parameter with a parameterless -method type `=> $T$` is treated specially. In this case, the -corresponding actual argument expression $e$ is not evaluated before the +method type `=> ´T´` is treated specially. In this case, the +corresponding actual argument expression ´e´ is not evaluated before the application. Instead, every use of the formal parameter on the -right-hand side of the rewrite rule entails a re-evaluation of $e$. +right-hand side of the rewrite rule entails a re-evaluation of ´e´. In other words, the evaluation order for `=>`-parameters is _call-by-name_ whereas the evaluation order for normal parameters is _call-by-value_. -Furthermore, it is required that $e$'s [packed type](#expression-typing) -conforms to the parameter type $T$. +Furthermore, it is required that ´e´'s [packed type](#expression-typing) +conforms to the parameter type ´T´. The behavior of by-name parameters is preserved if the application is transformed into a block due to named or default arguments. In this case, -the local value for that parameter has the form `val $y_i$ = () => $e$` -and the argument passed to the function is `$y_i$()`. +the local value for that parameter has the form `val ´y_i´ = () => ´e´` +and the argument passed to the function is `´y_i´()`. The last argument in an application may be marked as a sequence -argument, e.g. `$e$: _*`. Such an argument must correspond +argument, e.g. `´e´: _*`. Such an argument must correspond to a [repeated parameter](04-basic-declarations-and-definitions.html#repeated-parameters) of type -`$S$*` and it must be the only argument matching this +`´S´*` and it must be the only argument matching this parameter (i.e. the number of formal parameters and actual arguments -must be the same). Furthermore, the type of $e$ must conform to -`scala.Seq[$T$]`, for some type $T$ which conforms to -$S$. In this case, the argument list is transformed by replacing the -sequence $e$ with its elements. When the application uses named +must be the same). Furthermore, the type of ´e´ must conform to +`scala.Seq[´T´]`, for some type ´T´ which conforms to +´S´. In this case, the argument list is transformed by replacing the +sequence ´e´ with its elements. When the application uses named arguments, the vararg parameter has to be specified exactly once. A function application usually allocates a new frame on the program's @@ -325,83 +325,83 @@ would not typecheck. ### Named and Default Arguments -If an application is to use named arguments $p = e$ or default +If an application is to use named arguments ´p = e´ or default arguments, the following conditions must hold. -- For every named argument $p_i = e_i$ which appears left of a positional argument - in the argument list $e_1 \ldots e_m$, the argument position $i$ coincides with - the position of parameter $p_i$ in the parameter list of the applied method. -- The names $x_i$ of all named arguments are pairwise distinct and no named +- For every named argument ´p_i = e_i´ which appears left of a positional argument + in the argument list ´e_1 \ldots e_m´, the argument position ´i´ coincides with + the position of parameter ´p_i´ in the parameter list of the applied method. +- The names ´x_i´ of all named arguments are pairwise distinct and no named argument defines a parameter which is already specified by a positional argument. -- Every formal parameter $p_j:T_j$ which is not specified by either a positional +- Every formal parameter ´p_j:T_j´ which is not specified by either a positional or named argument has a default argument. If the application uses named or default arguments the following transformation is applied to convert it into an application without named or default arguments. -If the method $f$ -has the form `$p.m$[$\mathit{targs}$]` it is transformed into the +If the method ´f´ +has the form `´p.m´[´\mathit{targs}´]` it is transformed into the block ```scala -{ val q = $p$ - q.$m$[$\mathit{targs}$] +{ val q = ´p´ + q.´m´[´\mathit{targs}´] } ``` -If the method $f$ is itself an application expression the transformation -is applied recursively on $f$. The result of transforming $f$ is a block of +If the method ´f´ is itself an application expression the transformation +is applied recursively on ´f´. The result of transforming ´f´ is a block of the form ```scala -{ val q = $p$ - val $x_1$ = expr$_1$ - $\ldots$ - val $x_k$ = expr$_k$ - q.$m$[$\mathit{targs}$]($\mathit{args}_1$)$, \ldots ,$($\mathit{args}_l$) +{ val q = ´p´ + val ´x_1´ = expr´_1´ + ´\ldots´ + val ´x_k´ = expr´_k´ + q.´m´[´\mathit{targs}´](´\mathit{args}_1´)´, \ldots ,´(´\mathit{args}_l´) } ``` -where every argument in $(\mathit{args}\_1) , \ldots , (\mathit{args}\_l)$ is a reference to -one of the values $x_1 , \ldots , x_k$. To integrate the current application -into the block, first a value definition using a fresh name $y_i$ is created -for every argument in $e_1 , \ldots , e_m$, which is initialised to $e_i$ for -positional arguments and to $e'_i$ for named arguments of the form -`$x_i=e'_i$`. Then, for every parameter which is not specified -by the argument list, a value definition using a fresh name $z_i$ is created, +where every argument in ´(\mathit{args}\_1) , \ldots , (\mathit{args}\_l)´ is a reference to +one of the values ´x_1 , \ldots , x_k´. To integrate the current application +into the block, first a value definition using a fresh name ´y_i´ is created +for every argument in ´e_1 , \ldots , e_m´, which is initialised to ´e_i´ for +positional arguments and to ´e'_i´ for named arguments of the form +`´x_i=e'_i´`. Then, for every parameter which is not specified +by the argument list, a value definition using a fresh name ´z_i´ is created, which is initialized using the method computing the [default argument](04-basic-declarations-and-definitions.html#function-declarations-and-definitions) of this parameter. -Let $\mathit{args}$ be a permutation of the generated names $y_i$ and $z_i$ such such +Let ´\mathit{args}´ be a permutation of the generated names ´y_i´ and ´z_i´ such such that the position of each name matches the position of its corresponding -parameter in the method type `($p_1:T_1 , \ldots , p_n:T_n$)$U$`. +parameter in the method type `(´p_1:T_1 , \ldots , p_n:T_n´)´U´`. The final result of the transformation is a block of the form ```scala -{ val q = $p$ - val $x_1$ = expr$_1$ - $\ldots$ - val $x_l$ = expr$_k$ - val $y_1$ = $e_1$ - $\ldots$ - val $y_m$ = $e_m$ - val $z_1$ = $q.m\$default\$i[\mathit{targs}](\mathit{args}_1), \ldots ,(\mathit{args}_l)$ - $\ldots$ - val $z_d$ = $q.m\$default\$j[\mathit{targs}](\mathit{args}_1), \ldots ,(\mathit{args}_l)$ - q.$m$[$\mathit{targs}$]($\mathit{args}_1$)$, \ldots ,$($\mathit{args}_l$)($\mathit{args}$) +{ val q = ´p´ + val ´x_1´ = expr´_1´ + ´\ldots´ + val ´x_l´ = expr´_k´ + val ´y_1´ = ´e_1´ + ´\ldots´ + val ´y_m´ = ´e_m´ + val ´z_1´ = ´q.m\$default\$i[\mathit{targs}](\mathit{args}_1), \ldots ,(\mathit{args}_l)´ + ´\ldots´ + val ´z_d´ = ´q.m\$default\$j[\mathit{targs}](\mathit{args}_1), \ldots ,(\mathit{args}_l)´ + q.´m´[´\mathit{targs}´](´\mathit{args}_1´)´, \ldots ,´(´\mathit{args}_l´)(´\mathit{args}´) } ``` ### Signature Polymorphic Methods -For invocations of signature polymorphic methods of the target platform `$f$($e_1 , \ldots , e_m$)`, -the invoked method has a different method type `($p_1$:$T_1 , \ldots , p_n$:$T_n$)$U$` at each call -site. The parameter types `$T_ , \ldots , T_n$` are the types of the argument expressions -`$e_1 , \ldots , e_m$` and `$U$` is the expected type at the call site. If the expected type is -undefined then `$U$` is `scala.AnyRef`. The parameter names `$p_1 , \ldots , p_n$` are fresh. +For invocations of signature polymorphic methods of the target platform `´f´(´e_1 , \ldots , e_m´)`, +the invoked method has a different method type `(´p_1´:´T_1 , \ldots , p_n´:´T_n´)´U´` at each call +site. The parameter types `´T_ , \ldots , T_n´` are the types of the argument expressions +`´e_1 , \ldots , e_m´` and `´U´` is the expected type at the call site. If the expected type is +undefined then `´U´` is `scala.AnyRef`. The parameter names `´p_1 , \ldots , p_n´` are fresh. ###### Note @@ -414,13 +414,13 @@ On the Java platform version 7 and later, the methods `invoke` and `invokeExact` SimpleExpr ::= SimpleExpr1 ‘_’ ``` -The expression `$e$ _` is well-formed if $e$ is of method -type or if $e$ is a call-by-name parameter. If $e$ is a method with -parameters, `$e$ _` represents $e$ converted to a function -type by [eta expansion](#eta-expansion-section). If $e$ is a +The expression `´e´ _` is well-formed if ´e´ is of method +type or if ´e´ is a call-by-name parameter. If ´e´ is a method with +parameters, `´e´ _` represents ´e´ converted to a function +type by [eta expansion](#eta-expansion-section). If ´e´ is a parameterless method or call-by-name parameter of type -`=> $T$`, `$e$ _` represents the function of type -`() => $T$`, which evaluates $e$ when it is applied to the empty +`=> ´T´`, `´e´ _` represents the function of type +`() => ´T´`, which evaluates ´e´ when it is applied to the empty parameter list `()`. ###### Example @@ -443,20 +443,20 @@ because otherwise the underscore would be considered part of the name. SimpleExpr ::= SimpleExpr TypeArgs ``` -A _type application_ `$e$[$T_1 , \ldots , T_n$]` instantiates -a polymorphic value $e$ of type -`[$a_1$ >: $L_1$ <: $U_1, \ldots , a_n$ >: $L_n$ <: $U_n$]$S$` +A _type application_ `´e´[´T_1 , \ldots , T_n´]` instantiates +a polymorphic value ´e´ of type +`[´a_1´ >: ´L_1´ <: ´U_1, \ldots , a_n´ >: ´L_n´ <: ´U_n´]´S´` with argument types -`$T_1 , \ldots , T_n$`. Every argument type $T_i$ must obey -the corresponding bounds $L_i$ and $U_i$. That is, for each $i = 1 -, \ldots , n$, we must have $\sigma L_i <: T_i <: \sigma -U_i$, where $\sigma$ is the substitution $[a_1 := T_1 , \ldots , a_n -:= T_n]$. The type of the application is $\sigma S$. +`´T_1 , \ldots , T_n´`. Every argument type ´T_i´ must obey +the corresponding bounds ´L_i´ and ´U_i´. That is, for each ´i = 1 +, \ldots , n´, we must have ´\sigma L_i <: T_i <: \sigma +U_i´, where ´\sigma´ is the substitution ´[a_1 := T_1 , \ldots , a_n +:= T_n]´. The type of the application is ´\sigma S´. -If the function part $e$ is of some value type, the type application +If the function part ´e´ is of some value type, the type application is taken to be equivalent to -`$e$.apply[$T_1 , \ldots ,$ T$_n$]`, i.e. the application of an `apply` method defined by -$e$. +`´e´.apply[´T_1 , \ldots ,´ T´_n´]`, i.e. the application of an `apply` method defined by +´e´. Type applications can be omitted if [local type inference](#local-type-inference) can infer best type parameters @@ -469,9 +469,9 @@ and the expected result type. SimpleExpr ::= ‘(’ [Exprs] ‘)’ ``` -A _tuple expression_ `($e_1 , \ldots , e_n$)` is an alias +A _tuple expression_ `(´e_1 , \ldots , e_n´)` is an alias for the class instance creation -`scala.Tuple$n$($e_1 , \ldots , e_n$)`, where $n \geq 2$. +`scala.Tuple´n´(´e_1 , \ldots , e_n´)`, where ´n \geq 2´. The empty tuple `()` is the unique value of type `scala.Unit`. @@ -482,43 +482,43 @@ SimpleExpr ::= ‘new’ (ClassTemplate | TemplateBody) ``` A _simple instance creation expression_ is of the form -`new $c$` -where $c$ is a [constructor invocation](05-classes-and-objects.html#constructor-invocations). Let $T$ be -the type of $c$. Then $T$ must +`new ´c´` +where ´c´ is a [constructor invocation](05-classes-and-objects.html#constructor-invocations). Let ´T´ be +the type of ´c´. Then ´T´ must denote a (a type instance of) a non-abstract subclass of `scala.AnyRef`. Furthermore, the _concrete self type_ of the expression must conform to the [self type](05-classes-and-objects.html#templates) of the class denoted by -$T$. The concrete self type is normally -$T$, except if the expression `new $c$` appears as the +´T´. The concrete self type is normally +´T´, except if the expression `new ´c´` appears as the right hand side of a value definition ```scala -val $x$: $S$ = new $c$ +val ´x´: ´S´ = new ´c´ ``` -(where the type annotation `: $S$` may be missing). +(where the type annotation `: ´S´` may be missing). In the latter case, the concrete self type of the expression is the -compound type `$T$ with $x$.type`. +compound type `´T´ with ´x´.type`. The expression is evaluated by creating a fresh -object of type $T$ which is initialized by evaluating $c$. The -type of the expression is $T$. +object of type ´T´ which is initialized by evaluating ´c´. The +type of the expression is ´T´. A _general instance creation expression_ is of the form -`new $t$` for some [class template](05-classes-and-objects.html#templates) $t$. +`new ´t´` for some [class template](05-classes-and-objects.html#templates) ´t´. Such an expression is equivalent to the block ```scala -{ class $a$ extends $t$; new $a$ } +{ class ´a´ extends ´t´; new ´a´ } ``` -where $a$ is a fresh name of an _anonymous class_ which is +where ´a´ is a fresh name of an _anonymous class_ which is inaccessible to user programs. There is also a shorthand form for creating values of structural -types: If `{$D$}` is a class body, then -`new {$D$}` is equivalent to the general instance creation expression -`new AnyRef{$D$}`. +types: If `{´D´}` is a class body, then +`new {´D´}` is equivalent to the general instance creation expression +`new AnyRef{´D´}`. ###### Example Consider the following structural instance creation expression: @@ -536,10 +536,10 @@ new AnyRef{ def getName() = "aaron" } The latter is in turn a shorthand for the block ```scala -{ class anon\$X extends AnyRef{ def getName() = "aaron" }; new anon\$X } +{ class anon$X extends AnyRef{ def getName() = "aaron" }; new anon$X } ``` -where `anon\$X` is some freshly created name. +where `anon$X` is some freshly created name. ## Blocks @@ -549,55 +549,55 @@ BlockExpr ::= ‘{’ CaseClauses ‘}’ Block ::= BlockStat {semi BlockStat} [ResultExpr] ``` -A _block expression_ `{$s_1$; $\ldots$; $s_n$; $e\,$}` is -constructed from a sequence of block statements $s_1 , \ldots , s_n$ -and a final expression $e$. The statement sequence may not contain +A _block expression_ `{´s_1´; ´\ldots´; ´s_n´; ´e\,´}` is +constructed from a sequence of block statements ´s_1 , \ldots , s_n´ +and a final expression ´e´. The statement sequence may not contain two definitions or declarations that bind the same name in the same namespace. The final expression can be omitted, in which case the unit value `()` is assumed. -The expected type of the final expression $e$ is the expected +The expected type of the final expression ´e´ is the expected type of the block. The expected type of all preceding statements is undefined. -The type of a block `$s_1$; $\ldots$; $s_n$; $e$` is -`$T$ forSome {$\,Q\,$}`, where $T$ is the type of $e$ and $Q$ +The type of a block `´s_1´; ´\ldots´; ´s_n´; ´e´` is +`´T´ forSome {´\,Q\,´}`, where ´T´ is the type of ´e´ and ´Q´ contains [existential clauses](03-types.html#existential-types) -for every value or type name which is free in $T$ -and which is defined locally in one of the statements $s_1 , \ldots , s_n$. +for every value or type name which is free in ´T´ +and which is defined locally in one of the statements ´s_1 , \ldots , s_n´. We say the existential clause _binds_ the occurrence of the value or type name. Specifically, -- A locally defined type definition `type$\;t = T$` - is bound by the existential clause `type$\;t >: T <: T$`. - It is an error if $t$ carries type parameters. -- A locally defined value definition `val$\;x: T = e$` is - bound by the existential clause `val$\;x: T$`. -- A locally defined class definition `class$\;c$ extends$\;t$` - is bound by the existential clause `type$\;c <: T$` where - $T$ is the least class type or refinement type which is a proper - supertype of the type $c$. It is an error if $c$ carries type parameters. -- A locally defined object definition `object$\;x\;$extends$\;t$` - is bound by the existential clause `val$\;x: T$` where - $T$ is the least class type or refinement type which is a proper supertype of the type - `$x$.type`. +- A locally defined type definition `type´\;t = T´` + is bound by the existential clause `type´\;t >: T <: T´`. + It is an error if ´t´ carries type parameters. +- A locally defined value definition `val´\;x: T = e´` is + bound by the existential clause `val´\;x: T´`. +- A locally defined class definition `class´\;c´ extends´\;t´` + is bound by the existential clause `type´\;c <: T´` where + ´T´ is the least class type or refinement type which is a proper + supertype of the type ´c´. It is an error if ´c´ carries type parameters. +- A locally defined object definition `object´\;x\;´extends´\;t´` + is bound by the existential clause `val´\;x: T´` where + ´T´ is the least class type or refinement type which is a proper supertype of the type + `´x´.type`. Evaluation of the block entails evaluation of its statement sequence, followed by an evaluation of the final expression -$e$, which defines the result of the block. +´e´, which defines the result of the block. ###### Example Assuming a class `Ref[T](x: T)`, the block ```scala -{ class C extends B {$\ldots$} ; new Ref(new C) } +{ class C extends B {´\ldots´} ; new Ref(new C) } ``` has the type `Ref[_1] forSome { type _1 <: B }`. The block ```scala -{ class C extends B {$\ldots$} ; new C } +{ class C extends B {´\ldots´} ; new C } ``` simply has type `B`, because with the rules [here](03-types.html#simplification-rules) @@ -617,11 +617,11 @@ Expressions can be constructed from operands and operators. ### Prefix Operations -A prefix operation $\mathit{op};e$ consists of a prefix operator $\mathit{op}$, which +A prefix operation ´\mathit{op};e´ consists of a prefix operator ´\mathit{op}´, which must be one of the identifiers ‘`+`’, ‘`-`’, -‘`!`’ or ‘`~`’. The expression $\mathit{op};e$ is +‘`!`’ or ‘`~`’. The expression ´\mathit{op};e´ is equivalent to the postfix method application -`e.unary_$\mathit{op}$`. +`e.unary_´\mathit{op}´`. @@ -635,7 +635,7 @@ application of the infix operator `sin` to the operands ### Postfix Operations A postfix operator can be an arbitrary identifier. The postfix -operation $e;\mathit{op}$ is interpreted as $e.\mathit{op}$. +operation ´e;\mathit{op}´ is interpreted as ´e.\mathit{op}´. ### Infix Operations @@ -679,28 +679,28 @@ parts of an expression as follows. expression, then operators with higher precedence bind more closely than operators with lower precedence. - If there are consecutive infix - operations $e_0; \mathit{op}\_1; e_1; \mathit{op}\_2 \ldots \mathit{op}\_n; e_n$ - with operators $\mathit{op}\_1 , \ldots , \mathit{op}\_n$ of the same precedence, + operations ´e_0; \mathit{op}\_1; e_1; \mathit{op}\_2 \ldots \mathit{op}\_n; e_n´ + with operators ´\mathit{op}\_1 , \ldots , \mathit{op}\_n´ of the same precedence, then all these operators must have the same associativity. If all operators are left-associative, the sequence is interpreted as - $(\ldots(e_0;\mathit{op}\_1;e_1);\mathit{op}\_2\ldots);\mathit{op}\_n;e_n$. + ´(\ldots(e_0;\mathit{op}\_1;e_1);\mathit{op}\_2\ldots);\mathit{op}\_n;e_n´. Otherwise, if all operators are right-associative, the sequence is interpreted as - $e_0;\mathit{op}\_1;(e_1;\mathit{op}\_2;(\ldots \mathit{op}\_n;e_n)\ldots)$. + ´e_0;\mathit{op}\_1;(e_1;\mathit{op}\_2;(\ldots \mathit{op}\_n;e_n)\ldots)´. - Postfix operators always have lower precedence than infix - operators. E.g. $e_1;\mathit{op}\_1;e_2;\mathit{op}\_2$ is always equivalent to - $(e_1;\mathit{op}\_1;e_2);\mathit{op}\_2$. + operators. E.g. ´e_1;\mathit{op}\_1;e_2;\mathit{op}\_2´ is always equivalent to + ´(e_1;\mathit{op}\_1;e_2);\mathit{op}\_2´. The right-hand operand of a left-associative operator may consist of -several arguments enclosed in parentheses, e.g. $e;\mathit{op};(e_1,\ldots,e_n)$. -This expression is then interpreted as $e.\mathit{op}(e_1,\ldots,e_n)$. +several arguments enclosed in parentheses, e.g. ´e;\mathit{op};(e_1,\ldots,e_n)´. +This expression is then interpreted as ´e.\mathit{op}(e_1,\ldots,e_n)´. A left-associative binary -operation $e_1;\mathit{op};e_2$ is interpreted as $e_1.\mathit{op}(e_2)$. If $\mathit{op}$ is +operation ´e_1;\mathit{op};e_2´ is interpreted as ´e_1.\mathit{op}(e_2)´. If ´\mathit{op}´ is right-associative and its parameter is passed by name, the same operation is interpreted as -$e_2.\mathit{op}(e_1)$. If $\mathit{op}$ is right-associative and its parameter is passed by value, -it is interpreted as `{ val $x$=$e_1$; $e_2$.$\mathit{op}$($x\,$) }`, where $x$ is a fresh name. +´e_2.\mathit{op}(e_1)´. If ´\mathit{op}´ is right-associative and its parameter is passed by value, +it is interpreted as `{ val ´x´=´e_1´; ´e_2´.´\mathit{op}´(´x\,´) }`, where ´x´ is a fresh name. ### Assignment Operators @@ -715,24 +715,24 @@ Assignment operators are treated specially in that they can be expanded to assignments if no other interpretation is valid. Let's consider an assignment operator such as `+=` in an infix -operation `$l$ += $r$`, where $l$, $r$ are expressions. +operation `´l´ += ´r´`, where ´l´, ´r´ are expressions. This operation can be re-interpreted as an operation which corresponds to the assignment ```scala -$l$ = $l$ + $r$ +´l´ = ´l´ + ´r´ ``` -except that the operation's left-hand-side $l$ is evaluated only once. +except that the operation's left-hand-side ´l´ is evaluated only once. The re-interpretation occurs if the following two conditions are fulfilled. -1. The left-hand-side $l$ does not have a member named +1. The left-hand-side ´l´ does not have a member named `+=`, and also cannot be converted by an [implicit conversion](#implicit-conversions) to a value with a member named `+=`. -1. The assignment `$l$ = $l$ + $r$` is type-correct. - In particular this implies that $l$ refers to a variable or object +1. The assignment `´l´ = ´l´ + ´r´` is type-correct. + In particular this implies that ´l´ refers to a variable or object that can be assigned to, and that is convertible to a value with a member named `+`. @@ -742,9 +742,9 @@ The re-interpretation occurs if the following two conditions are fulfilled. Expr1 ::= PostfixExpr ‘:’ CompoundType ``` -The _typed expression_ $e: T$ has type $T$. The type of -expression $e$ is expected to conform to $T$. The result of -the expression is the value of $e$ converted to type $T$. +The _typed expression_ ´e: T´ has type ´T´. The type of +expression ´e´ is expected to conform to ´T´. The result of +the expression is the value of ´e´ converted to type ´T´. ###### Example Here are examples of well-typed and ill-typed expressions. @@ -761,9 +761,9 @@ Here are examples of well-typed and ill-typed expressions. Expr1 ::= PostfixExpr ‘:’ Annotation {Annotation} ``` -An _annotated expression_ `$e$: @$a_1$ $\ldots$ @$a_n$` -attaches [annotations](11-annotations.html#user-defined-annotations) $a_1 , \ldots , a_n$ to the -expression $e$. +An _annotated expression_ `´e´: @´a_1´ ´\ldots´ @´a_n´` +attaches [annotations](11-annotations.html#user-defined-annotations) ´a_1 , \ldots , a_n´ to the +expression ´e´. ## Assignments @@ -772,22 +772,22 @@ Expr1 ::= [SimpleExpr ‘.’] id ‘=’ Expr | SimpleExpr1 ArgumentExprs ‘=’ Expr ``` -The interpretation of an assignment to a simple variable `$x$ = $e$` -depends on the definition of $x$. If $x$ denotes a mutable -variable, then the assignment changes the current value of $x$ to be -the result of evaluating the expression $e$. The type of $e$ is -expected to conform to the type of $x$. If $x$ is a parameterless +The interpretation of an assignment to a simple variable `´x´ = ´e´` +depends on the definition of ´x´. If ´x´ denotes a mutable +variable, then the assignment changes the current value of ´x´ to be +the result of evaluating the expression ´e´. The type of ´e´ is +expected to conform to the type of ´x´. If ´x´ is a parameterless method defined in some template, and the same template contains a -setter method `$x$_=` as member, then the assignment -`$x$ = $e$` is interpreted as the invocation -`$x$_=($e\,$)` of that setter method. Analogously, an -assignment `$f.x$ = $e$` to a parameterless method $x$ -is interpreted as the invocation `$f.x$_=($e\,$)`. +setter method `´x´_=` as member, then the assignment +`´x´ = ´e´` is interpreted as the invocation +`´x´_=(´e\,´)` of that setter method. Analogously, an +assignment `´f.x´ = ´e´` to a parameterless method ´x´ +is interpreted as the invocation `´f.x´_=(´e\,´)`. -An assignment `$f$($\mathit{args}\,$) = $e$` with a method application to the +An assignment `´f´(´\mathit{args}\,´) = ´e´` with a method application to the left of the ‘`=`’ operator is interpreted as -`$f.$update($\mathit{args}$, $e\,$)`, i.e. -the invocation of an `update` method defined by $f$. +`´f.´update(´\mathit{args}´, ´e\,´)`, i.e. +the invocation of an `update` method defined by ´f´. ###### Example Here are some assignment expressions and their equivalent expansions. @@ -856,25 +856,25 @@ def matmul(xss: Array[Array[Double]], yss: Array[Array[Double]]) = { Expr1 ::= ‘if’ ‘(’ Expr ‘)’ {nl} Expr [[semi] ‘else’ Expr] ``` -The _conditional expression_ `if ($e_1$) $e_2$ else $e_3$` chooses -one of the values of $e_2$ and $e_3$, depending on the -value of $e_1$. The condition $e_1$ is expected to -conform to type `Boolean`. The then-part $e_2$ and the -else-part $e_3$ are both expected to conform to the expected +The _conditional expression_ `if (´e_1´) ´e_2´ else ´e_3´` chooses +one of the values of ´e_2´ and ´e_3´, depending on the +value of ´e_1´. The condition ´e_1´ is expected to +conform to type `Boolean`. The then-part ´e_2´ and the +else-part ´e_3´ are both expected to conform to the expected type of the conditional expression. The type of the conditional expression is the [weak least upper bound](03-types.html#weak-conformance) -of the types of $e_2$ and -$e_3$. A semicolon preceding the `else` symbol of a +of the types of ´e_2´ and +´e_3´. A semicolon preceding the `else` symbol of a conditional expression is ignored. The conditional expression is evaluated by evaluating first -$e_1$. If this evaluates to `true`, the result of -evaluating $e_2$ is returned, otherwise the result of -evaluating $e_3$ is returned. +´e_1´. If this evaluates to `true`, the result of +evaluating ´e_2´ is returned, otherwise the result of +evaluating ´e_3´ is returned. A short form of the conditional expression eliminates the -else-part. The conditional expression `if ($e_1$) $e_2$` is -evaluated as if it was `if ($e_1$) $e_2$ else ()`. +else-part. The conditional expression `if (´e_1´) ´e_2´` is +evaluated as if it was `if (´e_1´) ´e_2´ else ()`. ## While Loop Expressions @@ -882,8 +882,8 @@ evaluated as if it was `if ($e_1$) $e_2$ else ()`. Expr1 ::= ‘while’ ‘(’ Expr ‘)’ {nl} Expr ``` -The _while loop expression_ `while ($e_1$) $e_2$` is typed and -evaluated as if it was an application of `whileLoop ($e_1$) ($e_2$)` where +The _while loop expression_ `while (´e_1´) ´e_2´` is typed and +evaluated as if it was an application of `whileLoop (´e_1´) (´e_2´)` where the hypothetical method `whileLoop` is defined as follows. ```scala @@ -897,8 +897,8 @@ def whileLoop(cond: => Boolean)(body: => Unit): Unit = Expr1 ::= ‘do’ Expr [semi] ‘while’ ‘(’ Expr ‘)’ ``` -The _do loop expression_ `do $e_1$ while ($e_2$)` is typed and -evaluated as if it was the expression `($e_1$ ; while ($e_2$) $e_1$)`. +The _do loop expression_ `do ´e_1´ while (´e_2´)` is typed and +evaluated as if it was the expression `(´e_1´ ; while (´e_2´) ´e_1´)`. A semicolon preceding the `while` symbol of a do loop expression is ignored. ## For Comprehensions and For Loops @@ -911,86 +911,85 @@ Generator ::= Pattern1 ‘<-’ Expr {[semi] Guard | semi Pattern1 ‘=’ Guard ::= ‘if’ PostfixExpr ``` -A _for loop_ `for ($\mathit{enums}\,$) $e$` executes expression $e$ -for each binding generated by the enumerators $\mathit{enums}$. -A _for comprehension_ `for ($\mathit{enums}\,$) yield $e$` evaluates -expression $e$ for each binding generated by the enumerators $\mathit{enums}$ +A _for loop_ `for (´\mathit{enums}\,´) ´e´` executes expression ´e´ +for each binding generated by the enumerators ´\mathit{enums}´. +A _for comprehension_ `for (´\mathit{enums}\,´) yield ´e´` evaluates +expression ´e´ for each binding generated by the enumerators ´\mathit{enums}´ and collects the results. An enumerator sequence always starts with a generator; this can be followed by further generators, value -definitions, or guards. A _generator_ `$p$ <- $e$` -produces bindings from an expression $e$ which is matched in some way -against pattern $p$. A _value definition_ `$p$ = $e$` -binds the value name $p$ (or several names in a pattern $p$) to -the result of evaluating the expression $e$. A _guard_ -`if $e$` contains a boolean expression which restricts +definitions, or guards. A _generator_ `´p´ <- ´e´` +produces bindings from an expression ´e´ which is matched in some way +against pattern ´p´. A _value definition_ `´p´ = ´e´` +binds the value name ´p´ (or several names in a pattern ´p´) to +the result of evaluating the expression ´e´. A _guard_ +`if ´e´` contains a boolean expression which restricts enumerated bindings. The precise meaning of generators and guards is defined by translation to invocations of four methods: `map`, `withFilter`, `flatMap`, and `foreach`. These methods can be implemented in different ways for different carrier types. The translation scheme is as follows. In a first step, every -generator `$p$ <- $e$`, where $p$ is not [irrefutable](08-pattern-matching.html#patterns) -for the type of $e$, and $p$ is some pattern other than a simple name -or a name followed by a colon and a type, is replaced by +generator `´p´ <- ´e´`, where ´p´ is not [irrefutable](08-pattern-matching.html#patterns) +for the type of ´e´ is replaced by ```scala -$p$ <- $e$.withFilter { case $p$ => true; case _ => false } +´p´ <- ´e´.withFilter { case ´p´ => true; case _ => false } ``` Then, the following rules are applied repeatedly until all comprehensions have been eliminated. - A for comprehension - `for ($p$ <- $e\,$) yield $e'$` + `for (´p´ <- ´e\,´) yield ´e'´` is translated to - `$e$.map { case $p$ => $e'$ }`. + `´e´.map { case ´p´ => ´e'´ }`. - A for loop - `for ($p$ <- $e\,$) $e'$` + `for (´p´ <- ´e\,´) ´e'´` is translated to - `$e$.foreach { case $p$ => $e'$ }`. + `´e´.foreach { case ´p´ => ´e'´ }`. - A for comprehension ```scala - for ($p$ <- $e$; $p'$ <- $e'; \ldots$) yield $e''$ + for (´p´ <- ´e´; ´p'´ <- ´e'; \ldots´) yield ´e''´ ``` - where `$\ldots$` is a (possibly empty) + where `´\ldots´` is a (possibly empty) sequence of generators, definitions, or guards, is translated to ```scala - $e$.flatMap { case $p$ => for ($p'$ <- $e'; \ldots$) yield $e''$ } + ´e´.flatMap { case ´p´ => for (´p'´ <- ´e'; \ldots´) yield ´e''´ } ``` - A for loop ```scala - for ($p$ <- $e$; $p'$ <- $e'; \ldots$) $e''$ + for (´p´ <- ´e´; ´p'´ <- ´e'; \ldots´) ´e''´ ``` - where `$\ldots$` is a (possibly empty) + where `´\ldots´` is a (possibly empty) sequence of generators, definitions, or guards, is translated to ```scala - $e$.foreach { case $p$ => for ($p'$ <- $e'; \ldots$) $e''$ } + ´e´.foreach { case ´p´ => for (´p'´ <- ´e'; \ldots´) ´e''´ } ``` - - A generator `$p$ <- $e$` followed by a guard - `if $g$` is translated to a single generator - `$p$ <- $e$.withFilter(($x_1 , \ldots , x_n$) => $g\,$)` where - $x_1 , \ldots , x_n$ are the free variables of $p$. + - A generator `´p´ <- ´e´` followed by a guard + `if ´g´` is translated to a single generator + `´p´ <- ´e´.withFilter((´x_1 , \ldots , x_n´) => ´g\,´)` where + ´x_1 , \ldots , x_n´ are the free variables of ´p´. - - A generator `$p$ <- $e$` followed by a value definition - `$p'$ = $e'$` is translated to the following generator of pairs of values, where - $x$ and $x'$ are fresh names: + - A generator `´p´ <- ´e´` followed by a value definition + `´p'´ = ´e'´` is translated to the following generator of pairs of values, where + ´x´ and ´x'´ are fresh names: ```scala - ($p$, $p'$) <- for ($x @ p$ <- $e$) yield { val $x' @ p'$ = $e'$; ($x$, $x'$) } + (´p´, ´p'´) <- for (´x @ p´ <- ´e´) yield { val ´x' @ p'´ = ´e'´; (´x´, ´x'´) } ``` ###### Example -The following code produces all pairs of numbers between $1$ and $n-1$ +The following code produces all pairs of numbers between ´1´ and ´n-1´ whose sums are prime. ```scala @@ -1056,31 +1055,31 @@ The code above makes use of the fact that `map`, `flatMap`, Expr1 ::= ‘return’ [Expr] ``` -A _return expression_ `return $e$` must occur inside the body of some +A _return expression_ `return ´e´` must occur inside the body of some enclosing user defined method. The innermost enclosing method in a -source program, $m$, must have an explicitly declared result type, and -the type of $e$ must conform to it. +source program, ´m´, must have an explicitly declared result type, and +the type of ´e´ must conform to it. -The return expression evaluates the expression $e$ and returns its -value as the result of $m$. The evaluation of any statements or +The return expression evaluates the expression ´e´ and returns its +value as the result of ´m´. The evaluation of any statements or expressions following the return expression is omitted. The type of a return expression is `scala.Nothing`. -The expression $e$ may be omitted. The return expression +The expression ´e´ may be omitted. The return expression `return` is type-checked and evaluated as if it were `return ()`. Returning from the method from within a nested function may be implemented by throwing and catching a -`scala.runtime.NonLocalReturnException`. Any exception catches +`scala.runtime.NonLocalReturnControl`. Any exception catches between the point of return and the enclosing methods might see and catch that exception. A key comparison makes sure that this exception is only caught by the method instance which is terminated by the return. If the return expression is itself part of an anonymous function, it -is possible that the enclosing method $m$ has already returned +is possible that the enclosing method ´m´ has already returned before the return expression is executed. In that case, the thrown -`scala.runtime.NonLocalReturnException` will not be caught, and will +`scala.runtime.NonLocalReturnControl` will not be caught, and will propagate up the call stack. ## Throw Expressions @@ -1089,10 +1088,10 @@ propagate up the call stack. Expr1 ::= ‘throw’ Expr ``` -A _throw expression_ `throw $e$` evaluates the expression -$e$. The type of this expression must conform to -`Throwable`. If $e$ evaluates to an exception -reference, evaluation is aborted with the thrown exception. If $e$ +A _throw expression_ `throw ´e´` evaluates the expression +´e´. The type of this expression must conform to +`Throwable`. If ´e´ evaluates to an exception +reference, evaluation is aborted with the thrown exception. If ´e´ evaluates to `null`, evaluation is instead aborted with a `NullPointerException`. If there is an active [`try` expression](#try-expressions) which handles the thrown @@ -1106,50 +1105,50 @@ is `scala.Nothing`. Expr1 ::= ‘try’ Expr [‘catch’ Expr] [‘finally’ Expr] ``` -A _try expression_ is of the form `try { $b$ } catch $h$` -where the handler $h$ is a +A _try expression_ is of the form `try { ´b´ } catch ´h´` +where the handler ´h´ is a [pattern matching anonymous function](08-pattern-matching.html#pattern-matching-anonymous-functions) ```scala -{ case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$ } +{ case ´p_1´ => ´b_1´ ´\ldots´ case ´p_n´ => ´b_n´ } ``` This expression is evaluated by evaluating the block -$b$. If evaluation of $b$ does not cause an exception to be -thrown, the result of $b$ is returned. Otherwise the -handler $h$ is applied to the thrown exception. +´b´. If evaluation of ´b´ does not cause an exception to be +thrown, the result of ´b´ is returned. Otherwise the +handler ´h´ is applied to the thrown exception. If the handler contains a case matching the thrown exception, the first such case is invoked. If the handler contains no case matching the thrown exception, the exception is re-thrown. -Let $\mathit{pt}$ be the expected type of the try expression. The block -$b$ is expected to conform to $\mathit{pt}$. The handler $h$ -is expected conform to type `scala.PartialFunction[scala.Throwable, $\mathit{pt}\,$]`. +Let ´\mathit{pt}´ be the expected type of the try expression. The block +´b´ is expected to conform to ´\mathit{pt}´. The handler ´h´ +is expected conform to type `scala.PartialFunction[scala.Throwable, ´\mathit{pt}\,´]`. The type of the try expression is the [weak least upper bound](03-types.html#weak-conformance) -of the type of $b$ and the result type of $h$. +of the type of ´b´ and the result type of ´h´. -A try expression `try { $b$ } finally $e$` evaluates the block -$b$. If evaluation of $b$ does not cause an exception to be -thrown, the expression $e$ is evaluated. If an exception is thrown -during evaluation of $e$, the evaluation of the try expression is +A try expression `try { ´b´ } finally ´e´` evaluates the block +´b´. If evaluation of ´b´ does not cause an exception to be +thrown, the expression ´e´ is evaluated. If an exception is thrown +during evaluation of ´e´, the evaluation of the try expression is aborted with the thrown exception. If no exception is thrown during -evaluation of $e$, the result of $b$ is returned as the +evaluation of ´e´, the result of ´b´ is returned as the result of the try expression. -If an exception is thrown during evaluation of $b$, the finally block -$e$ is also evaluated. If another exception $e$ is thrown -during evaluation of $e$, evaluation of the try expression is +If an exception is thrown during evaluation of ´b´, the finally block +´e´ is also evaluated. If another exception ´e´ is thrown +during evaluation of ´e´, evaluation of the try expression is aborted with the thrown exception. If no exception is thrown during -evaluation of $e$, the original exception thrown in $b$ is -re-thrown once evaluation of $e$ has completed. The block -$b$ is expected to conform to the expected type of the try -expression. The finally expression $e$ is expected to conform to +evaluation of ´e´, the original exception thrown in ´b´ is +re-thrown once evaluation of ´e´ has completed. The block +´b´ is expected to conform to the expected type of the try +expression. The finally expression ´e´ is expected to conform to type `Unit`. -A try expression `try { $b$ } catch $e_1$ finally $e_2$` +A try expression `try { ´b´ } catch ´e_1´ finally ´e_2´` is a shorthand -for `try { try { $b$ } catch $e_1$ } finally $e_2$`. +for `try { try { ´b´ } catch ´e_1´ } finally ´e_2´`. ## Anonymous Functions @@ -1160,30 +1159,30 @@ Bindings ::= ‘(’ Binding {‘,’ Binding} ‘)’ Binding ::= (id | ‘_’) [‘:’ Type] ``` -The anonymous function of arity $n$, `($x_1$: $T_1 , \ldots , x_n$: $T_n$) => e` maps parameters $x_i$ of types $T_i$ to a result given by expression $e$. The scope of each formal parameter $x_i$ is $e$. Formal parameters must have pairwise distinct names. +The anonymous function of arity ´n´, `(´x_1´: ´T_1 , \ldots , x_n´: ´T_n´) => e` maps parameters ´x_i´ of types ´T_i´ to a result given by expression ´e´. The scope of each formal parameter ´x_i´ is ´e´. Formal parameters must have pairwise distinct names. -In the case of a single untyped formal parameter, `($x\,$) => $e$` can be abbreviated to `$x$ => $e$`. If an anonymous function `($x$: $T\,$) => $e$` with a single typed parameter appears as the result expression of a block, it can be abbreviated to `$x$: $T$ => e`. +In the case of a single untyped formal parameter, `(´x\,´) => ´e´` can be abbreviated to `´x´ => ´e´`. If an anonymous function `(´x´: ´T\,´) => ´e´` with a single typed parameter appears as the result expression of a block, it can be abbreviated to `´x´: ´T´ => e`. A formal parameter may also be a wildcard represented by an underscore `_`. In that case, a fresh name for the parameter is chosen arbitrarily. A named parameter of an anonymous function may be optionally preceded by an `implicit` modifier. In that case the parameter is labeled [`implicit`](07-implicits.html#implicit-parameters-and-views); however the parameter section itself does not count as an [implicit parameter section](07-implicits.html#implicit-parameters). Hence, arguments to anonymous functions always have to be given explicitly. ### Translation -If the expected type of the anonymous function is of the shape `scala.Function$n$[$S_1 , \ldots , S_n$, $R\,$]`, or can be [SAM-converted](#sam-conversion) to such a function type, the type `$T_i$` of a parameter `$x_i$` can be omitted, as far as `$S_i$` is defined in the expected type, and `$T_i$ = $S_i$` is assumed. Furthermore, the expected type when type checking $e$ is $R$. +If the expected type of the anonymous function is of the shape `scala.Function´n´[´S_1 , \ldots , S_n´, ´R\,´]`, or can be [SAM-converted](#sam-conversion) to such a function type, the type `´T_i´` of a parameter `´x_i´` can be omitted, as far as `´S_i´` is defined in the expected type, and `´T_i´ = ´S_i´` is assumed. Furthermore, the expected type when type checking ´e´ is ´R´. -If there is no expected type for the function literal, all formal parameter types `$T_i$` must be specified explicitly, and the expected type of $e$ is undefined. The type of the anonymous function is `scala.Function$n$[$T_1 , \ldots , T_n$, $R\,$]`, where $R$ is the [packed type](#expression-typing) of $e$. $R$ must be equivalent to a type which does not refer to any of the formal parameters $x_i$. +If there is no expected type for the function literal, all formal parameter types `´T_i´` must be specified explicitly, and the expected type of ´e´ is undefined. The type of the anonymous function is `scala.Function´n´[´T_1 , \ldots , T_n´, ´R\,´]`, where ´R´ is the [packed type](#expression-typing) of ´e´. ´R´ must be equivalent to a type which does not refer to any of the formal parameters ´x_i´. The eventual run-time value of an anonymous function is determined by the expected type: - - a subclass of one of the builtin function types, `scala.Function$n$[$S_1 , \ldots , S_n$, $R\,$]` (with $S_i$ and $R$ fully defined), + - a subclass of one of the builtin function types, `scala.Function´n´[´S_1 , \ldots , S_n´, ´R\,´]` (with ´S_i´ and ´R´ fully defined), - a [single-abstract-method (SAM) type](#sam-conversion); - - `PartialFunction[$T$, $U$]` + - `PartialFunction[´T´, ´U´]` - some other type. The standard anonymous function evaluates in the same way as the following instance creation expression: ```scala -new scala.Function$n$[$T_1 , \ldots , T_n$, $T$] { - def apply($x_1$: $T_1 , \ldots , x_n$: $T_n$): $T$ = $e$ +new scala.Function´n´[´T_1 , \ldots , T_n´, ´T´] { + def apply(´x_1´: ´T_1 , \ldots , x_n´: ´T_n´): ´T´ = ´e´ } ``` @@ -1212,7 +1211,7 @@ f => g => x => f(g(x)) // Curried function composition (x: Int,y: Int) => x + y // A summation function () => { count += 1; count } // The function which takes an - // empty parameter list $()$, + // empty parameter list ´()´, // increments a non-local variable // `count' and returns the new value. @@ -1232,19 +1231,19 @@ are legal. Such an expression represents an anonymous function where subsequent occurrences of underscores denote successive parameters. Define an _underscore section_ to be an expression of the form -`_:$T$` where $T$ is a type, or else of the form `_`, +`_:´T´` where ´T´ is a type, or else of the form `_`, provided the underscore does not appear as the expression part of a -type ascription `_:$T$`. +type ascription `_:´T´`. -An expression $e$ of syntactic category `Expr` _binds_ an underscore section -$u$, if the following two conditions hold: (1) $e$ properly contains $u$, and +An expression ´e´ of syntactic category `Expr` _binds_ an underscore section +´u´, if the following two conditions hold: (1) ´e´ properly contains ´u´, and (2) there is no other expression of syntactic category `Expr` -which is properly contained in $e$ and which itself properly contains $u$. +which is properly contained in ´e´ and which itself properly contains ´u´. -If an expression $e$ binds underscore sections $u_1 , \ldots , u_n$, in this order, it is equivalent to -the anonymous function `($u'_1$, ... $u'_n$) => $e'$` -where each $u_i'$ results from $u_i$ by replacing the underscore with a fresh identifier and -$e'$ results from $e$ by replacing each underscore section $u_i$ by $u_i'$. +If an expression ´e´ binds underscore sections ´u_1 , \ldots , u_n´, in this order, it is equivalent to +the anonymous function `(´u'_1´, ... ´u'_n´) => ´e'´` +where each ´u_i'´ results from ´u_i´ by replacing the underscore with a fresh identifier and +´e'´ results from ´e´ by replacing each underscore section ´u_i´ by ´u_i'´. ###### Example The anonymous functions in the left column use placeholder @@ -1269,8 +1268,8 @@ include at least the expressions of the following forms: - A string literal - A class constructed with [`Predef.classOf`](12-the-scala-standard-library.html#the-predef-object) - An element of an enumeration from the underlying platform -- A literal array, of the form `Array$(c_1 , \ldots , c_n)$`, - where all of the $c_i$'s are themselves constant expressions +- A literal array, of the form `Array´(c_1 , \ldots , c_n)´`, + where all of the ´c_i´'s are themselves constant expressions - An identifier defined by a [constant value definition](04-basic-declarations-and-definitions.html#value-declarations-and-definitions). ## Statements @@ -1292,8 +1291,8 @@ Statements occur as parts of blocks and templates. A _statement_ can be an import, a definition or an expression, or it can be empty. Statements used in the template of a class definition can also be declarations. An expression that is used as a statement can have an -arbitrary value type. An expression statement $e$ is evaluated by -evaluating $e$ and discarding the result of the evaluation. +arbitrary value type. An expression statement ´e´ is evaluated by +evaluating ´e´ and discarding the result of the evaluation. @@ -1315,8 +1314,8 @@ available implicit conversions are given in the next two sub-sections. ### Value Conversions The following seven implicit conversions can be applied to an -expression $e$ which has some value type $T$ and which is type-checked with -some expected type $\mathit{pt}$. +expression ´e´ which has some value type ´T´ and which is type-checked with +some expected type ´\mathit{pt}´. ###### Static Overloading Resolution If an expression denotes several possible members of a class, @@ -1324,22 +1323,22 @@ If an expression denotes several possible members of a class, is applied to pick a unique member. ###### Type Instantiation -An expression $e$ of polymorphic type +An expression ´e´ of polymorphic type ```scala -[$a_1$ >: $L_1$ <: $U_1 , \ldots , a_n$ >: $L_n$ <: $U_n$]$T$ +[´a_1´ >: ´L_1´ <: ´U_1 , \ldots , a_n´ >: ´L_n´ <: ´U_n´]´T´ ``` which does not appear as the function part of -a type application is converted to a type instance of $T$ +a type application is converted to a type instance of ´T´ by determining with [local type inference](#local-type-inference) -instance types `$T_1 , \ldots , T_n$` -for the type variables `$a_1 , \ldots , a_n$` and -implicitly embedding $e$ in the [type application](#type-applications) -`$e$[$T_1 , \ldots , T_n$]`. +instance types `´T_1 , \ldots , T_n´` +for the type variables `´a_1 , \ldots , a_n´` and +implicitly embedding ´e´ in the [type application](#type-applications) +`´e´[´T_1 , \ldots , T_n´]`. ###### Numeric Widening -If $e$ has a primitive number type which [weakly conforms](03-types.html#weak-conformance) +If ´e´ has a primitive number type which [weakly conforms](03-types.html#weak-conformance) to the expected type, it is widened to the expected type using one of the numeric conversion methods `toShort`, `toChar`, `toInt`, `toLong`, @@ -1352,13 +1351,13 @@ that is, if conversion back to the original type produces the original value. ###### Numeric Literal Narrowing If the expected type is `Byte`, `Short` or `Char`, and -the expression $e$ is an integer literal fitting in the range of that +the expression ´e´ is an integer literal fitting in the range of that type, it is converted to the same literal in that type. ###### Value Discarding -If $e$ has some value type and the expected type is `Unit`, -$e$ is converted to the expected type by embedding it in the -term `{ $e$; () }`. +If ´e´ has some value type and the expected type is `Unit`, +´e´ is converted to the expected type by embedding it in the +term `{ ´e´; () }`. ###### SAM conversion An expression `(p1, ..., pN) => body` of function type `(T1, ..., TN) => T` is sam-convertible to the expected type `S` if the following holds: @@ -1385,13 +1384,13 @@ Finally, we impose some implementation restrictions (these may be lifted in futu - `C` must not be `@specialized`. ###### View Application -If none of the previous conversions applies, and $e$'s type -does not conform to the expected type $\mathit{pt}$, it is attempted to convert -$e$ to the expected type with a [view](07-implicits.html#views). +If none of the previous conversions applies, and ´e´'s type +does not conform to the expected type ´\mathit{pt}´, it is attempted to convert +´e´ to the expected type with a [view](07-implicits.html#views). ###### Selection on `Dynamic` -If none of the previous conversions applies, and $e$ is a prefix -of a selection $e.x$, and $e$'s type conforms to class `scala.Dynamic`, +If none of the previous conversions applies, and ´e´ is a prefix +of a selection ´e.x´, and ´e´'s type conforms to class `scala.Dynamic`, then the selection is rewritten according to the rules for [dynamic member selection](#dynamic-member-selection). @@ -1401,8 +1400,8 @@ The following four implicit conversions can be applied to methods which are not applied to some argument list. ###### Evaluation -A parameterless method $m$ of type `=> $T$` is always converted to -type $T$ by evaluating the expression to which $m$ is bound. +A parameterless method ´m´ of type `=> ´T´` is always converted to +type ´T´ by evaluating the expression to which ´m´ is bound. ###### Implicit Application If the method takes only implicit parameters, implicit @@ -1410,43 +1409,43 @@ arguments are passed following the rules [here](07-implicits.html#implicit-param ###### Eta Expansion Otherwise, if the method is not a constructor, -and the expected type $\mathit{pt}$ is a function type, or, +and the expected type ´\mathit{pt}´ is a function type, or, for methods of non-zero arity, a type [sam-convertible](#sam-conversion) to a function type, -$(\mathit{Ts}') \Rightarrow T'$, [eta-expansion](#eta-expansion-section) -is performed on the expression $e$. +´(\mathit{Ts}') \Rightarrow T'´, [eta-expansion](#eta-expansion-section) +is performed on the expression ´e´. (The exception for zero-arity methods is to avoid surprises due to unexpected sam conversion.) ###### Empty Application -Otherwise, if $e$ has method type $()T$, it is implicitly applied to the empty -argument list, yielding $e()$. +Otherwise, if ´e´ has method type ´()T´, it is implicitly applied to the empty +argument list, yielding ´e()´. ### Overloading Resolution -If an identifier or selection $e$ references several members of a +If an identifier or selection ´e´ references several members of a class, the context of the reference is used to identify a unique -member. The way this is done depends on whether or not $e$ is used as -a function. Let $\mathscr{A}$ be the set of members referenced by $e$. +member. The way this is done depends on whether or not ´e´ is used as +a function. Let ´\mathscr{A}´ be the set of members referenced by ´e´. -Assume first that $e$ appears as a function in an application, as in -`$e$($e_1 , \ldots , e_m$)`. +Assume first that ´e´ appears as a function in an application, as in +`´e´(´e_1 , \ldots , e_m´)`. One first determines the set of functions that is potentially [applicable](#function-applications) based on the _shape_ of the arguments. -The *shape* of an argument expression $e$, written $\mathit{shape}(e)$, is +The *shape* of an argument expression ´e´, written ´\mathit{shape}(e)´, is a type that is defined as follows: - - For a function expression `($p_1$: $T_1 , \ldots , p_n$: $T_n$) => $b$: (Any $, \ldots ,$ Any) => $\mathit{shape}(b)$`, - where `Any` occurs $n$ times in the argument type. + - For a function expression `(´p_1´: ´T_1 , \ldots , p_n´: ´T_n´) => ´b´: (Any ´, \ldots ,´ Any) => ´\mathit{shape}(b)´`, + where `Any` occurs ´n´ times in the argument type. - For a pattern-matching anonymous function definition `{ case ... }`: `PartialFunction[Any, Nothing]`. - - For a named argument `$n$ = $e$`: $\mathit{shape}(e)$. + - For a named argument `´n´ = ´e´`: ´\mathit{shape}(e)´. - For all other expressions: `Nothing`. -Let $\mathscr{B}$ be the set of alternatives in $\mathscr{A}$ that are [_applicable_](#function-applications) -to expressions $(e_1 , \ldots , e_n)$ of types $(\mathit{shape}(e_1) , \ldots , \mathit{shape}(e_n))$. -If there is precisely one alternative in $\mathscr{B}$, that alternative is chosen. +Let ´\mathscr{B}´ be the set of alternatives in ´\mathscr{A}´ that are [_applicable_](#function-applications) +to expressions ´(e_1 , \ldots , e_n)´ of types ´(\mathit{shape}(e_1) , \ldots , \mathit{shape}(e_n))´. +If there is precisely one alternative in ´\mathscr{B}´, that alternative is chosen. -Otherwise, let $S_1 , \ldots , S_m$ be the list of types obtained by typing each argument as follows. +Otherwise, let ´S_1 , \ldots , S_m´ be the list of types obtained by typing each argument as follows. Normally, an argument is typed without an expected type, except when all alternatives explicitly specify the same parameter type for this argument (a missing parameter type, @@ -1463,27 +1462,27 @@ inference of the arguments (a function literal or eta-expanded method) to this o Note that the expected type drives eta-expansion (not performed unless a function-like type is expected), as well as inference of omitted parameter types of function literals. -More precisely, an argument `$e_i$` is typed with an expected type that is derived from the `$i$`th argument -type found in each alternative (call these `$T_{ij}$` for alternative `$j$` and argument position `$i$`) when -all `$T_{ij}$` are function types `$(A_{1j},..., A_{nj}) => ?$` (or the equivalent `PartialFunction`, or SAM) -of some arity `$n$`, and their argument types `$A_{kj}$` are identical across all overloads `$j$` for a -given `$k$`. Then, the expected type for `$e_i$` is derived as follows: - - we use `$PartialFunction[A_{1j},..., A_{nj}, ?]$` if for some overload `$j$`, `$T_{ij}$`'s type symbol is `PartialFunction`; - - else, if for some `$j$`, `$T_{ij}$` is `FunctionN`, the expected type is `$FunctionN[A_{1j},..., A_{nj}, ?]$`; - - else, if for all `$j$`, `$T_{ij}$` is a SAM type of the same class, defining argument types `$A_{1j},..., A_{nj}$` +More precisely, an argument `´e_i´` is typed with an expected type that is derived from the `´i´`th argument +type found in each alternative (call these `´T_{ij}´` for alternative `´j´` and argument position `´i´`) when +all `´T_{ij}´` are function types `´(A_{1j},..., A_{nj}) => ?´` (or the equivalent `PartialFunction`, or SAM) +of some arity `´n´`, and their argument types `´A_{kj}´` are identical across all overloads `´j´` for a +given `´k´`. Then, the expected type for `´e_i´` is derived as follows: + - we use `´PartialFunction[A_{1j},..., A_{nj}, ?]´` if for some overload `´j´`, `´T_{ij}´`'s type symbol is `PartialFunction`; + - else, if for some `´j´`, `´T_{ij}´` is `FunctionN`, the expected type is `´FunctionN[A_{1j},..., A_{nj}, ?]´`; + - else, if for all `´j´`, `´T_{ij}´` is a SAM type of the same class, defining argument types `´A_{1j},..., A_{nj}´` (and a potentially varying result type), the expected type encodes these argument types and the SAM class. -For every member $m$ in $\mathscr{B}$ one determines whether it is applicable -to expressions ($e_1 , \ldots , e_m$) of types $S_1, \ldots , S_m$. +For every member ´m´ in ´\mathscr{B}´ one determines whether it is applicable +to expressions (´e_1 , \ldots , e_m´) of types ´S_1, \ldots , S_m´. -It is an error if none of the members in $\mathscr{B}$ is applicable. If there is one -single applicable alternative, that alternative is chosen. Otherwise, let $\mathscr{CC}$ +It is an error if none of the members in ´\mathscr{B}´ is applicable. If there is one +single applicable alternative, that alternative is chosen. Otherwise, let ´\mathscr{CC}´ be the set of applicable alternatives which don't employ any default argument -in the application to $e_1 , \ldots , e_m$. +in the application to ´e_1 , \ldots , e_m´. -It is again an error if $\mathscr{CC}$ is empty. +It is again an error if ´\mathscr{CC}´ is empty. Otherwise, one chooses the _most specific_ alternative among the alternatives -in $\mathscr{CC}$, according to the following definition of being "as specific as", and +in ´\mathscr{CC}´, according to the following definition of being "as specific as", and "more specific than": -- A parameterized method $m$ of type `($p_1:T_1, \ldots , p_n:T_n$)$U$` is - _as specific as_ some other member $m'$ of type $S$ if $m'$ is [applicable](#function-applications) - to arguments `($p_1 , \ldots , p_n$)` of types $T_1 , \ldots , Tlast$; - if $T_n$ denotes a repeated parameter (it has shape $T*$), and so does $m'$'s last parameter, - $Tlast$ is taken as $T$, otherwise is $T_n$ used directly. -- A polymorphic method of type `[$a_1$ >: $L_1$ <: $U_1 , \ldots , a_n$ >: $L_n$ <: $U_n$]$T$` is - as specific as some other member of type $S$ if $T$ is as specific as $S$ - under the assumption that for $i = 1 , \ldots , n$ each $a_i$ is an abstract type name - bounded from below by $L_i$ and from above by $U_i$. +- A parameterized method ´m´ of type `(´p_1:T_1, \ldots , p_n:T_n´)´U´` is + _as specific as_ some other member ´m'´ of type ´S´ if ´m'´ is [applicable](#function-applications) + to arguments `(´p_1 , \ldots , p_n´)` of types ´T_1 , \ldots , T_n´. +- A polymorphic method of type `[´a_1´ >: ´L_1´ <: ´U_1 , \ldots , a_n´ >: ´L_n´ <: ´U_n´]´T´` is + as specific as some other member of type ´S´ if ´T´ is as specific as ´S´ + under the assumption that for ´i = 1 , \ldots , n´ each ´a_i´ is an abstract type name + bounded from below by ´L_i´ and from above by ´U_i´. - A member of any other type is always as specific as a parameterized method or a polymorphic method. -- Given two members of types $T$ and $U$ which are neither parameterized nor polymorphic method types, - the member of type $T$ is as specific as the member of type $U$ if - the existential dual of $T$ conforms to the existential dual of $U$. +- Given two members of types ´T´ and ´U´ which are neither parameterized nor polymorphic method types, + the member of type ´T´ is as specific as the member of type ´U´ if + the existential dual of ´T´ conforms to the existential dual of ´U´. Here, the existential dual of a polymorphic type - `[$a_1$ >: $L_1$ <: $U_1 , \ldots , a_n$ >: $L_n$ <: $U_n$]$T$` is - `$T$ forSome { type $a_1$ >: $L_1$ <: $U_1$ $, \ldots ,$ type $a_n$ >: $L_n$ <: $U_n$}`. + `[´a_1´ >: ´L_1´ <: ´U_1 , \ldots , a_n´ >: ´L_n´ <: ´U_n´]´T´` is + `´T´ forSome { type ´a_1´ >: ´L_1´ <: ´U_1´ ´, \ldots ,´ type ´a_n´ >: ´L_n´ <: ´U_n´}`. The existential dual of every other type is the type itself. -The _relative weight_ of an alternative $A$ over an alternative $B$ is a +The _relative weight_ of an alternative ´A´ over an alternative ´B´ is a number from 0 to 2, defined as the sum of -- 1 if $A$ is as specific as $B$, 0 otherwise, and -- 1 if $A$ is defined in a class or object which is derived from the class or object defining $B$, 0 otherwise. +- 1 if ´A´ is as specific as ´B´, 0 otherwise, and +- 1 if ´A´ is defined in a class or object which is derived from the class or object defining ´B´, 0 otherwise. -A class or object $C$ is _derived_ from a class or object $D$ if one of +A class or object ´C´ is _derived_ from a class or object ´D´ if one of the following holds: -- $C$ is a subclass of $D$, or -- $C$ is a companion object of a class derived from $D$, or -- $D$ is a companion object of a class from which $C$ is derived. +- ´C´ is a subclass of ´D´, or +- ´C´ is a companion object of a class derived from ´D´, or +- ´D´ is a companion object of a class from which ´C´ is derived. -An alternative $A$ is _more specific_ than an alternative $B$ if -the relative weight of $A$ over $B$ is greater than the relative -weight of $B$ over $A$. +An alternative ´A´ is _more specific_ than an alternative ´B´ if +the relative weight of ´A´ over ´B´ is greater than the relative +weight of ´B´ over ´A´. -It is an error if there is no alternative in $\mathscr{CC}$ which is more -specific than all other alternatives in $\mathscr{CC}$. +It is an error if there is no alternative in ´\mathscr{CC}´ which is more +specific than all other alternatives in ´\mathscr{CC}´. -Assume next that $e$ appears as a function in a type application, as -in `$e$[$\mathit{targs}\,$]`. Then all alternatives in -$\mathscr{A}$ which take the same number of type parameters as there are type -arguments in $\mathit{targs}$ are chosen. It is an error if no such alternative exists. +Assume next that ´e´ appears as a function in a type application, as +in `´e´[´\mathit{targs}\,´]`. Then all alternatives in +´\mathscr{A}´ which take the same number of type parameters as there are type +arguments in ´\mathit{targs}´ are chosen. It is an error if no such alternative exists. If there are several such alternatives, overloading resolution is -applied again to the whole expression `$e$[$\mathit{targs}\,$]`. +applied again to the whole expression `´e´[´\mathit{targs}\,´]`. -Assume finally that $e$ does not appear as a function in either an application or a type application. -If an expected type is given, let $\mathscr{B}$ be the set of those alternatives -in $\mathscr{A}$ which are [compatible](03-types.html#compatibility) to it. -Otherwise, let $\mathscr{B}$ be the same as $\mathscr{A}$. -In this last case we choose the most specific alternative among all alternatives in $\mathscr{B}$. -It is an error if there is no alternative in $\mathscr{B}$ which is -more specific than all other alternatives in $\mathscr{B}$. +Assume finally that ´e´ does not appear as a function in either an application or a type application. +If an expected type is given, let ´\mathscr{B}´ be the set of those alternatives +in ´\mathscr{A}´ which are [compatible](03-types.html#compatibility) to it. +Otherwise, let ´\mathscr{B}´ be the same as ´\mathscr{A}´. +In this last case we choose the most specific alternative among all alternatives in ´\mathscr{B}´. +It is an error if there is no alternative in ´\mathscr{B}´ which is +more specific than all other alternatives in ´\mathscr{B}´. ###### Example Consider the following definitions: ```scala class A extends B {} -def f(x: B, y: B) = $\ldots$ -def f(x: A, y: B) = $\ldots$ +def f(x: B, y: B) = ´\ldots´ +def f(x: A, y: B) = ´\ldots´ val a: A val b: B ``` Then the application `f(b, b)` refers to the first -definition of $f$ whereas the application `f(a, a)` +definition of ´f´ whereas the application `f(a, a)` refers to the second. Assume now we add a third overloaded definition ```scala -def f(x: B, y: A) = $\ldots$ +def f(x: B, y: A) = ´\ldots´ ``` Then the application `f(a, a)` is rejected for being ambiguous, since @@ -1575,92 +1572,92 @@ no most specific applicable signature exists. ### Local Type Inference Local type inference infers type arguments to be passed to expressions -of polymorphic type. Say $e$ is of type [$a_1$ >: $L_1$ <: $U_1, \ldots , a_n$ >: $L_n$ <: $U_n$]$T$ +of polymorphic type. Say ´e´ is of type [´a_1´ >: ´L_1´ <: ´U_1, \ldots , a_n´ >: ´L_n´ <: ´U_n´]´T´ and no explicit type parameters are given. Local type inference converts this expression to a type -application `$e$[$T_1 , \ldots , T_n$]`. The choice of the -type arguments $T_1 , \ldots , T_n$ depends on the context in which -the expression appears and on the expected type $\mathit{pt}$. +application `´e´[´T_1 , \ldots , T_n´]`. The choice of the +type arguments ´T_1 , \ldots , T_n´ depends on the context in which +the expression appears and on the expected type ´\mathit{pt}´. There are three cases. ###### Case 1: Selections If the expression appears as the prefix of a selection with a name -$x$, then type inference is _deferred_ to the whole expression -$e.x$. That is, if $e.x$ has type $S$, it is now treated as having -type [$a_1$ >: $L_1$ <: $U_1 , \ldots , a_n$ >: $L_n$ <: $U_n$]$S$, +´x´, then type inference is _deferred_ to the whole expression +´e.x´. That is, if ´e.x´ has type ´S´, it is now treated as having +type [´a_1´ >: ´L_1´ <: ´U_1 , \ldots , a_n´ >: ´L_n´ <: ´U_n´]´S´, and local type inference is applied in turn to infer type arguments -for $a_1 , \ldots , a_n$, using the context in which $e.x$ appears. +for ´a_1 , \ldots , a_n´, using the context in which ´e.x´ appears. ###### Case 2: Values -If the expression $e$ appears as a value without being applied to +If the expression ´e´ appears as a value without being applied to value arguments, the type arguments are inferred by solving a -constraint system which relates the expression's type $T$ with the -expected type $\mathit{pt}$. Without loss of generality we can assume that -$T$ is a value type; if it is a method type we apply +constraint system which relates the expression's type ´T´ with the +expected type ´\mathit{pt}´. Without loss of generality we can assume that +´T´ is a value type; if it is a method type we apply [eta-expansion](#eta-expansion-section) to convert it to a function type. Solving -means finding a substitution $\sigma$ of types $T_i$ for the type -parameters $a_i$ such that +means finding a substitution ´\sigma´ of types ´T_i´ for the type +parameters ´a_i´ such that -- None of the inferred types $T_i$ is a [singleton type](03-types.html#singleton-types) +- None of the inferred types ´T_i´ is a [singleton type](03-types.html#singleton-types) unless it is a singleton type corresponding to an object or a constant value - definition or the corresponding bound $U_i$ is a subtype of `scala.Singleton`. + definition or the corresponding bound ´U_i´ is a subtype of `scala.Singleton`. - All type parameter bounds are respected, i.e. - $\sigma L_i <: \sigma a_i$ and $\sigma a_i <: \sigma U_i$ for $i = 1 , \ldots , n$. + ´\sigma L_i <: \sigma a_i´ and ´\sigma a_i <: \sigma U_i´ for ´i = 1 , \ldots , n´. - The expression's type conforms to the expected type, i.e. - $\sigma T <: \sigma \mathit{pt}$. + ´\sigma T <: \sigma \mathit{pt}´. It is a compile time error if no such substitution exists. If several substitutions exist, local-type inference will choose for -each type variable $a_i$ a minimal or maximal type $T_i$ of the -solution space. A _maximal_ type $T_i$ will be chosen if the type -parameter $a_i$ appears [contravariantly](04-basic-declarations-and-definitions.html#variance-annotations) in the -type $T$ of the expression. A _minimal_ type $T_i$ will be chosen +each type variable ´a_i´ a minimal or maximal type ´T_i´ of the +solution space. A _maximal_ type ´T_i´ will be chosen if the type +parameter ´a_i´ appears [contravariantly](04-basic-declarations-and-definitions.html#variance-annotations) in the +type ´T´ of the expression. A _minimal_ type ´T_i´ will be chosen in all other situations, i.e. if the variable appears covariantly, -non-variantly or not at all in the type $T$. We call such a substitution -an _optimal solution_ of the given constraint system for the type $T$. +non-variantly or not at all in the type ´T´. We call such a substitution +an _optimal solution_ of the given constraint system for the type ´T´. ###### Case 3: Methods The last case applies if the expression -$e$ appears in an application $e(d_1 , \ldots , d_m)$. In that case -$T$ is a method type $(p_1:R_1 , \ldots , p_m:R_m)T'$. Without loss of -generality we can assume that the result type $T'$ is a value type; if +´e´ appears in an application ´e(d_1 , \ldots , d_m)´. In that case +´T´ is a method type ´(p_1:R_1 , \ldots , p_m:R_m)T'´. Without loss of +generality we can assume that the result type ´T'´ is a value type; if it is a method type we apply [eta-expansion](#eta-expansion-section) to -convert it to a function type. One computes first the types $S_j$ of -the argument expressions $d_j$, using two alternative schemes. Each -argument expression $d_j$ is typed first with the expected type $R_j$, -in which the type parameters $a_1 , \ldots , a_n$ are taken as type -constants. If this fails, the argument $d_j$ is typed instead with an -expected type $R_j'$ which results from $R_j$ by replacing every type -parameter in $a_1 , \ldots , a_n$ with _undefined_. +convert it to a function type. One computes first the types ´S_j´ of +the argument expressions ´d_j´, using two alternative schemes. Each +argument expression ´d_j´ is typed first with the expected type ´R_j´, +in which the type parameters ´a_1 , \ldots , a_n´ are taken as type +constants. If this fails, the argument ´d_j´ is typed instead with an +expected type ´R_j'´ which results from ´R_j´ by replacing every type +parameter in ´a_1 , \ldots , a_n´ with _undefined_. In a second step, type arguments are inferred by solving a constraint system which relates the method's type with the expected type -$\mathit{pt}$ and the argument types $S_1 , \ldots , S_m$. Solving the +´\mathit{pt}´ and the argument types ´S_1 , \ldots , S_m´. Solving the constraint system means -finding a substitution $\sigma$ of types $T_i$ for the type parameters -$a_i$ such that +finding a substitution ´\sigma´ of types ´T_i´ for the type parameters +´a_i´ such that -- None of the inferred types $T_i$ is a [singleton type](03-types.html#singleton-types) +- None of the inferred types ´T_i´ is a [singleton type](03-types.html#singleton-types) unless it is a singleton type corresponding to an object or a constant value - definition or the corresponding bound $U_i$ is a subtype of `scala.Singleton`. -- All type parameter bounds are respected, i.e. $\sigma L_i <: \sigma a_i$ and - $\sigma a_i <: \sigma U_i$ for $i = 1 , \ldots , n$. -- The method's result type $T'$ conforms to the expected type, i.e. $\sigma T' <: \sigma \mathit{pt}$. + definition or the corresponding bound ´U_i´ is a subtype of `scala.Singleton`. +- All type parameter bounds are respected, i.e. ´\sigma L_i <: \sigma a_i´ and + ´\sigma a_i <: \sigma U_i´ for ´i = 1 , \ldots , n´. +- The method's result type ´T'´ conforms to the expected type, i.e. ´\sigma T' <: \sigma \mathit{pt}´. - Each argument type [weakly conforms](03-types.html#weak-conformance) to the corresponding formal parameter - type, i.e. $\sigma S_j <:_w \sigma R_j$ for $j = 1 , \ldots , m$. + type, i.e. ´\sigma S_j <:_w \sigma R_j´ for ´j = 1 , \ldots , m´. It is a compile time error if no such substitution exists. If several -solutions exist, an optimal one for the type $T'$ is chosen. +solutions exist, an optimal one for the type ´T'´ is chosen. -All or parts of an expected type $\mathit{pt}$ may be undefined. The rules for +All or parts of an expected type ´\mathit{pt}´ may be undefined. The rules for [conformance](03-types.html#conformance) are extended to this case by adding -the rule that for any type $T$ the following two statements are always -true: $\mathit{undefined} <: T$ and $T <: \mathit{undefined}$ +the rule that for any type ´T´ the following two statements are always +true: ´\mathit{undefined} <: T´ and ´T <: \mathit{undefined}´ It is possible that no minimal or maximal solution for a type variable -exists, in which case a compile-time error results. Because $<:$ is a +exists, in which case a compile-time error results. Because ´<:´ is a pre-order, it is also possible that a solution set has several optimal solutions for a type. In that case, a Scala compiler is free to pick any one of them. @@ -1710,7 +1707,7 @@ the type parameter `a` of `cons`: ```scala Int <: a? List[scala.Nothing] <: List[a?] -List[a?] <: $\mathit{undefined}$ +List[a?] <: ´\mathit{undefined}´ ``` The optimal solution of this constraint system is @@ -1737,7 +1734,7 @@ First, the argument expressions are typed. The first argument first tried to be typed with expected type `List[a]`. This fails, as `List[Int]` is not a subtype of `List[a]`. Therefore, the second strategy is tried; `xs` is now typed with expected type -`List[$\mathit{undefined}$]`. This succeeds and yields the argument type +`List[´\mathit{undefined}´]`. This succeeds and yields the argument type `List[Int]`. In a second step, one solves the following constraint system for @@ -1746,7 +1743,7 @@ the type parameter `a` of `cons`: ```scala String <: a? List[Int] <: List[a?] -List[a?] <: $\mathit{undefined}$ +List[a?] <: ´\mathit{undefined}´ ``` The optimal solution of this constraint system is @@ -1762,19 +1759,19 @@ so `scala.Any` is the type inferred for `a`. _Eta-expansion_ converts an expression of method type to an equivalent expression of function type. It proceeds in two steps. -First, one identifies the maximal sub-expressions of $e$; let's -say these are $e_1 , \ldots , e_m$. For each of these, one creates a -fresh name $x_i$. Let $e'$ be the expression resulting from -replacing every maximal subexpression $e_i$ in $e$ by the -corresponding fresh name $x_i$. Second, one creates a fresh name $y_i$ -for every argument type $T_i$ of the method ($i = 1 , \ldots , -n$). The result of eta-conversion is then: +First, one identifies the maximal sub-expressions of ´e´; let's +say these are ´e_1 , \ldots , e_m´. For each of these, one creates a +fresh name ´x_i´. Let ´e'´ be the expression resulting from +replacing every maximal subexpression ´e_i´ in ´e´ by the +corresponding fresh name ´x_i´. Second, one creates a fresh name ´y_i´ +for every argument type ´T_i´ of the method (´i = 1 , \ldots , +n´). The result of eta-conversion is then: ```scala -{ val $x_1$ = $e_1$; - $\ldots$ - val $x_m$ = $e_m$; - ($y_1: T_1 , \ldots , y_n: T_n$) => $e'$($y_1 , \ldots , y_n$) +{ val ´x_1´ = ´e_1´; + ´\ldots´ + val ´x_m´ = ´e_m´; + (´y_1: T_1 , \ldots , y_n: T_n´) => ´e'´(´y_1 , \ldots , y_n´) } ``` @@ -1786,7 +1783,7 @@ a sub-expression of parameterless method type, is not evaluated in the expanded The standard Scala library defines a marker trait `scala.Dynamic`. Subclasses of this trait are able to intercept selections and applications on their instances by defining methods of the names `applyDynamic`, `applyDynamicNamed`, `selectDynamic`, and `updateDynamic`. -The following rewrites are performed, assuming $e$'s type conforms to `scala.Dynamic`, and the original expression does not type check under the normal rules, as specified fully in the relevant subsection of [implicit conversion](#dynamic-member-selection): +The following rewrites are performed, assuming ´e´'s type conforms to `scala.Dynamic`, and the original expression does not type check under the normal rules, as specified fully in the relevant subsection of [implicit conversion](#dynamic-member-selection): * `e.m[Ti](xi)` becomes `e.applyDynamic[Ti]("m")(xi)` * `e.m[Ti]` becomes `e.selectDynamic[Ti]("m")` diff --git a/spec/07-implicits.md b/spec/07-implicits.md index fd144e37fd03..6f38fdd48074 100644 --- a/spec/07-implicits.md +++ b/spec/07-implicits.md @@ -45,7 +45,7 @@ object Monoids { ## Implicit Parameters An _implicit parameter list_ -`(implicit $p_1$,$\ldots$,$p_n$)` of a method marks the parameters $p_1 , \ldots , p_n$ as +`(implicit ´p_1´,´\ldots´,´p_n´)` of a method marks the parameters ´p_1 , \ldots , p_n´ as implicit. A method or constructor can have only one implicit parameter list, and it must be the last parameter list given. @@ -55,8 +55,8 @@ effect. However, if such a method misses arguments for its implicit parameters, such arguments will be automatically provided. The actual arguments that are eligible to be passed to an implicit -parameter of type $T$ fall into two categories. First, eligible are -all identifiers $x$ that can be accessed at the point of the method +parameter of type ´T´ fall into two categories. First, eligible are +all identifiers ´x´ that can be accessed at the point of the method call without a prefix and that denote an [implicit definition](#the-implicit-modifier) or an implicit parameter. To be accessible without a prefix, an identifier @@ -64,27 +64,27 @@ must be a local name, a member of an enclosing template or a name introduced by [import clause](04-basic-declarations-and-definitions.html#import-clauses). If there are no eligible identifiers under this rule, then, second, eligible are also all `implicit` members of some object that belongs to the implicit -scope of the implicit parameter's type, $T$. - -The _implicit scope_ of a type $T$ consists of all [companion modules](05-classes-and-objects.html#object-definitions) of classes that are associated with the implicit parameter's type. -Here, we say a class $C$ is _associated_ with a type $T$ if it is a [base class](05-classes-and-objects.html#class-linearization) of some part of $T$. - -The _parts_ of a type $T$ are: - -- if $T$ is a compound type `$T_1$ with $\ldots$ with $T_n$`, - the union of the parts of $T_1 , \ldots , T_n$, as well as $T$ itself; -- if $T$ is a parameterized type `$S$[$T_1 , \ldots , T_n$]`, - the union of the parts of $S$ and $T_1 , \ldots , T_n$; -- if $T$ is a singleton type `$p$.type`, - the parts of the type of $p$; -- if $T$ is a type projection `$S$#$U$`, - the parts of $S$ as well as $T$ itself; -- if $T$ is a type alias, the parts of its expansion; -- if $T$ is an abstract type, the parts of its upper bound; -- if $T$ denotes an implicit conversion to a type with a method with argument types $T_1 , \ldots , T_n$ and result type $U$, - the union of the parts of $T_1 , \ldots , T_n$ and $U$; +scope of the implicit parameter's type, ´T´. + +The _implicit scope_ of a type ´T´ consists of all [companion modules](05-classes-and-objects.html#object-definitions) of classes that are associated with the implicit parameter's type. +Here, we say a class ´C´ is _associated_ with a type ´T´ if it is a [base class](05-classes-and-objects.html#class-linearization) of some part of ´T´. + +The _parts_ of a type ´T´ are: + +- if ´T´ is a compound type `´T_1´ with ´\ldots´ with ´T_n´`, + the union of the parts of ´T_1 , \ldots , T_n´, as well as ´T´ itself; +- if ´T´ is a parameterized type `´S´[´T_1 , \ldots , T_n´]`, + the union of the parts of ´S´ and ´T_1 , \ldots , T_n´; +- if ´T´ is a singleton type `´p´.type`, + the parts of the type of ´p´; +- if ´T´ is a type projection `´S´#´U´`, + the parts of ´S´ as well as ´T´ itself; +- if ´T´ is a type alias, the parts of its expansion; +- if ´T´ is an abstract type, the parts of its upper bound; +- if ´T´ denotes an implicit conversion to a type with a method with argument types ´T_1 , \ldots , T_n´ and result type ´U´, + the union of the parts of ´T_1 , \ldots , T_n´ and ´U´; - the parts of quantified (existential or universal) and annotated types are defined as the parts of the underlying types (e.g., the parts of `T forSome { ... }` are the parts of `T`); -- in all other cases, just $T$ itself. +- in all other cases, just ´T´ itself. Note that packages are internally represented as classes with companion modules to hold the package members. Thus, implicits defined in a package object are part of the implicit scope of a type prefixed by that package. @@ -238,7 +238,7 @@ explicitly. To prevent infinite expansions, such as the `magic` example above, the compiler keeps track of a stack of “open implicit types” for which implicit arguments are currently being searched. Whenever an -implicit argument for type $T$ is searched, $T$ is added to the stack paired with the implicit +implicit argument for type ´T´ is searched, ´T´ is added to the stack paired with the implicit definition which produces it, and whether it was required to satisfy a by-name implicit argument or not. The type is removed from the stack once the search for the implicit argument either definitely fails or succeeds. Everytime a type is about to be added to the stack, it is checked against @@ -253,33 +253,33 @@ existing entries which were produced by the same implicit definition and then, + otherwise it is added to the stack paired with the implicit definition which produces it. Implicit resolution continues with the implicit arguments of that definition (if any). -Here, the _core type_ of $T$ is $T$ with aliases expanded, +Here, the _core type_ of ´T´ is ´T´ with aliases expanded, top-level type [annotations](11-annotations.html#user-defined-annotations) and [refinements](03-types.html#compound-types) removed, and occurrences of top-level existentially bound variables replaced by their upper bounds. -A core type $T$ _dominates_ a type $U$ if $T$ is [equivalent](03-types.html#equivalence) to $U$, -or if the top-level type constructors of $T$ and $U$ have a common element and $T$ is more complex -than $U$ and the _covering sets_ of $T$ and $U$ are equal. +A core type ´T´ _dominates_ a type ´U´ if ´T´ is [equivalent](03-types.html#equivalence) to ´U´, +or if the top-level type constructors of ´T´ and ´U´ have a common element and ´T´ is more complex +than ´U´ and the _covering sets_ of ´T´ and ´U´ are equal. -The set of _top-level type constructors_ $\mathit{ttcs}(T)$ of a type $T$ depends on the form of +The set of _top-level type constructors_ ´\mathit{ttcs}(T)´ of a type ´T´ depends on the form of the type: -- For a type designator, $\mathit{ttcs}(p.c) ~=~ \{c\}$; -- For a parameterized type, $\mathit{ttcs}(p.c[\mathit{targs}]) ~=~ \{c\}$; -- For a singleton type, $\mathit{ttcs}(p.type) ~=~ \mathit{ttcs}(T)$, provided $p$ has type $T$; -- For a compound type, `$\mathit{ttcs}(T_1$ with $\ldots$ with $T_n)$` $~=~ \mathit{ttcs}(T_1) \cup \ldots \cup \mathit{ttcs}(T_n)$. +- For a type designator, ´\mathit{ttcs}(p.c) ~=~ \{c\}´; +- For a parameterized type, ´\mathit{ttcs}(p.c[\mathit{targs}]) ~=~ \{c\}´; +- For a singleton type, ´\mathit{ttcs}(p.type) ~=~ \mathit{ttcs}(T)´, provided ´p´ has type ´T´; +- For a compound type, `´\mathit{ttcs}(T_1´ with ´\ldots´ with ´T_n)´` ´~=~ \mathit{ttcs}(T_1) \cup \ldots \cup \mathit{ttcs}(T_n)´. -The _complexity_ $\operatorname{complexity}(T)$ of a core type is an integer which also depends on the form of +The _complexity_ ´\operatorname{complexity}(T)´ of a core type is an integer which also depends on the form of the type: -- For a type designator, $\operatorname{complexity}(p.c) ~=~ 1 + \operatorname{complexity}(p)$ -- For a parameterized type, $\operatorname{complexity}(p.c[\mathit{targs}]) ~=~ 1 + \Sigma \operatorname{complexity}(\mathit{targs})$ -- For a singleton type denoting a package $p$, $\operatorname{complexity}(p.type) ~=~ 0$ -- For any other singleton type, $\operatorname{complexity}(p.type) ~=~ 1 + \operatorname{complexity}(T)$, provided $p$ has type $T$; -- For a compound type, `$\operatorname{complexity}(T_1$ with $\ldots$ with $T_n)$` $= \Sigma\operatorname{complexity}(T_i)$ +- For a type designator, ´\operatorname{complexity}(p.c) ~=~ 1 + \operatorname{complexity}(p)´ +- For a parameterized type, ´\operatorname{complexity}(p.c[\mathit{targs}]) ~=~ 1 + \Sigma \operatorname{complexity}(\mathit{targs})´ +- For a singleton type denoting a package ´p´, ´\operatorname{complexity}(p.type) ~=~ 0´ +- For any other singleton type, ´\operatorname{complexity}(p.type) ~=~ 1 + \operatorname{complexity}(T)´, provided ´p´ has type ´T´; +- For a compound type, `´\operatorname{complexity}(T_1´ with ´\ldots´ with ´T_n)´` ´= \Sigma\operatorname{complexity}(T_i)´ -The _covering set_ $\mathit{cs}(T)$ of a type $T$ is the set of type designators mentioned in a type. +The _covering set_ ´\mathit{cs}(T)´ of a type ´T´ is the set of type designators mentioned in a type. For example, given the following, ```scala @@ -290,9 +290,9 @@ type C = List[(Int, String)] the corresponding covering sets are: -- $\mathit{cs}(A)$: List, Tuple2, Int -- $\mathit{cs}(B)$: List, Tuple2, Int -- $\mathit{cs}(C)$: List, Tuple2, Int, String +- ´\mathit{cs}(A)´: List, Tuple2, Int +- ´\mathit{cs}(B)´: List, Tuple2, Int +- ´\mathit{cs}(C)´: List, Tuple2, Int, String ###### Example When typing `sort(xs)` for some list `xs` of type `List[List[List[Int]]]`, @@ -332,35 +332,35 @@ will issue an error signalling a divergent implicit expansion. ## Views Implicit parameters and methods can also define implicit conversions -called views. A _view_ from type $S$ to type $T$ is +called views. A _view_ from type ´S´ to type ´T´ is defined by an implicit value which has function type -`$S$ => $T$` or `(=> $S$) => $T$` or by a method convertible to a value of that +`´S´ => ´T´` or `(=> ´S´) => ´T´` or by a method convertible to a value of that type. Views are applied in three situations: -1. If an expression $e$ is of type $T$, and $T$ does not conform to the - expression's expected type $\mathit{pt}$. In this case an implicit $v$ is - searched which is applicable to $e$ and whose result type conforms to - $\mathit{pt}$. The search proceeds as in the case of implicit parameters, - where the implicit scope is the one of `$T$ => $\mathit{pt}$`. If - such a view is found, the expression $e$ is converted to - `$v$($e$)`. -1. In a selection $e.m$ with $e$ of type $T$, if the selector $m$ does - not denote an accessible member of $T$. In this case, a view $v$ is searched - which is applicable to $e$ and whose result contains a member named - $m$. The search proceeds as in the case of implicit parameters, where - the implicit scope is the one of $T$. If such a view is found, the - selection $e.m$ is converted to `$v$($e$).$m$`. -1. In a selection $e.m(\mathit{args})$ with $e$ of type $T$, if the selector - $m$ denotes some member(s) of $T$, but none of these members is applicable to the arguments - $\mathit{args}$. In this case a view $v$ is searched which is applicable to $e$ - and whose result contains a method $m$ which is applicable to $\mathit{args}$. +1. If an expression ´e´ is of type ´T´, and ´T´ does not conform to the + expression's expected type ´\mathit{pt}´. In this case an implicit ´v´ is + searched which is applicable to ´e´ and whose result type conforms to + ´\mathit{pt}´. The search proceeds as in the case of implicit parameters, + where the implicit scope is the one of `´T´ => ´\mathit{pt}´`. If + such a view is found, the expression ´e´ is converted to + `´v´(´e´)`. +1. In a selection ´e.m´ with ´e´ of type ´T´, if the selector ´m´ does + not denote an accessible member of ´T´. In this case, a view ´v´ is searched + which is applicable to ´e´ and whose result contains a member named + ´m´. The search proceeds as in the case of implicit parameters, where + the implicit scope is the one of ´T´. If such a view is found, the + selection ´e.m´ is converted to `´v´(´e´).´m´`. +1. In a selection ´e.m(\mathit{args})´ with ´e´ of type ´T´, if the selector + ´m´ denotes some member(s) of ´T´, but none of these members is applicable to the arguments + ´\mathit{args}´. In this case a view ´v´ is searched which is applicable to ´e´ + and whose result contains a method ´m´ which is applicable to ´\mathit{args}´. The search proceeds as in the case of implicit parameters, where - the implicit scope is the one of $T$. If such a view is found, the - selection $e.m$ is converted to `$v$($e$).$m(\mathit{args})$`. + the implicit scope is the one of ´T´. If such a view is found, the + selection ´e.m´ is converted to `´v´(´e´).´m(\mathit{args})´`. -The implicit view, if it is found, can accept its argument $e$ as a +The implicit view, if it is found, can accept its argument ´e´ as a call-by-value or as a call-by-name parameter. However, call-by-value implicits take precedence over call-by-name implicits. @@ -405,33 +405,33 @@ method. {‘<%’ Type} {‘:’ Type} ``` -A type parameter $A$ of a method or non-trait class may have one or more view -bounds `$A$ <% $T$`. In this case the type parameter may be -instantiated to any type $S$ which is convertible by application of a -view to the bound $T$. +A type parameter ´A´ of a method or non-trait class may have one or more view +bounds `´A´ <% ´T´`. In this case the type parameter may be +instantiated to any type ´S´ which is convertible by application of a +view to the bound ´T´. -A type parameter $A$ of a method or non-trait class may also have one -or more context bounds `$A$ : $T$`. In this case the type parameter may be -instantiated to any type $S$ for which _evidence_ exists at the -instantiation point that $S$ satisfies the bound $T$. Such evidence -consists of an implicit value with type $T[S]$. +A type parameter ´A´ of a method or non-trait class may also have one +or more context bounds `´A´ : ´T´`. In this case the type parameter may be +instantiated to any type ´S´ for which _evidence_ exists at the +instantiation point that ´S´ satisfies the bound ´T´. Such evidence +consists of an implicit value with type ´T[S]´. A method or class containing type parameters with view or context bounds is treated as being equivalent to a method with implicit parameters. Consider first the case of a single parameter with view and/or context bounds such as: ```scala -def $f$[$A$ <% $T_1$ ... <% $T_m$ : $U_1$ : $U_n$]($\mathit{ps}$): $R$ = ... +def ´f´[´A´ <% ´T_1´ ... <% ´T_m´ : ´U_1´ : ´U_n´](´\mathit{ps}´): ´R´ = ... ``` Then the method definition above is expanded to ```scala -def $f$[$A$]($\mathit{ps}$)(implicit $v_1$: $A$ => $T_1$, ..., $v_m$: $A$ => $T_m$, - $w_1$: $U_1$[$A$], ..., $w_n$: $U_n$[$A$]): $R$ = ... +def ´f´[´A´](´\mathit{ps}´)(implicit ´v_1´: ´A´ => ´T_1´, ..., ´v_m´: ´A´ => ´T_m´, + ´w_1´: ´U_1´[´A´], ..., ´w_n´: ´U_n´[´A´]): ´R´ = ... ``` -where the $v_i$ and $w_j$ are fresh names for the newly introduced implicit parameters. These +where the ´v_i´ and ´w_j´ are fresh names for the newly introduced implicit parameters. These parameters are called _evidence parameters_. If a class or method has several view- or context-bounded type parameters, each @@ -448,7 +448,7 @@ For example: ```scala def foo[A: M](implicit b: B): C // expands to: -// def foo[A](implicit evidence$1: M[A], b: B): C +// def foo[A](implicit evidence´1: M[A], b: B): C ``` ###### Example @@ -474,52 +474,52 @@ trait ClassManifest[T] extends OptManifest[T] trait Manifest[T] extends ClassManifest[T] ``` -If an implicit parameter of a method or constructor is of a subtype $M[T]$ of -class `OptManifest[T]`, _a manifest is determined for $M[S]$_, +If an implicit parameter of a method or constructor is of a subtype ´M[T]´ of +class `OptManifest[T]`, _a manifest is determined for ´M[S]´_, according to the following rules. -First if there is already an implicit argument that matches $M[T]$, this +First if there is already an implicit argument that matches ´M[T]´, this argument is selected. -Otherwise, let $\mathit{Mobj}$ be the companion object `scala.reflect.Manifest` -if $M$ is trait `Manifest`, or be -the companion object `scala.reflect.ClassManifest` otherwise. Let $M'$ be the trait -`Manifest` if $M$ is trait `Manifest`, or be the trait `OptManifest` otherwise. +Otherwise, let ´\mathit{Mobj}´ be the companion object `scala.reflect.Manifest` +if ´M´ is trait `Manifest`, or be +the companion object `scala.reflect.ClassManifest` otherwise. Let ´M'´ be the trait +`Manifest` if ´M´ is trait `Manifest`, or be the trait `OptManifest` otherwise. Then the following rules apply. -1. If $T$ is a value class or one of the classes `Any`, `AnyVal`, `Object`, +1. If ´T´ is a value class or one of the classes `Any`, `AnyVal`, `Object`, `Null`, or `Nothing`, a manifest for it is generated by selecting - the corresponding manifest value `Manifest.$T$`, which exists in the + the corresponding manifest value `Manifest.´T´`, which exists in the `Manifest` module. -1. If $T$ is an instance of `Array[$S$]`, a manifest is generated - with the invocation `$\mathit{Mobj}$.arrayType[S](m)`, where $m$ is the manifest - determined for $M[S]$. -1. If $T$ is some other class type $S$#$C[U_1, \ldots, U_n]$ where the prefix - type $S$ cannot be statically determined from the class $C$, - a manifest is generated with the invocation `$\mathit{Mobj}$.classType[T]($m_0$, classOf[T], $ms$)` - where $m_0$ is the manifest determined for $M'[S]$ and $ms$ are the - manifests determined for $M'[U_1], \ldots, M'[U_n]$. -1. If $T$ is some other class type with type arguments $U_1 , \ldots , U_n$, +1. If ´T´ is an instance of `Array[´S´]`, a manifest is generated + with the invocation `´\mathit{Mobj}´.arrayType[S](m)`, where ´m´ is the manifest + determined for ´M[S]´. +1. If ´T´ is some other class type ´S´#´C[U_1, \ldots, U_n]´ where the prefix + type ´S´ cannot be statically determined from the class ´C´, + a manifest is generated with the invocation `´\mathit{Mobj}´.classType[T](´m_0´, classOf[T], ´ms´)` + where ´m_0´ is the manifest determined for ´M'[S]´ and ´ms´ are the + manifests determined for ´M'[U_1], \ldots, M'[U_n]´. +1. If ´T´ is some other class type with type arguments ´U_1 , \ldots , U_n´, a manifest is generated - with the invocation `$\mathit{Mobj}$.classType[T](classOf[T], $ms$)` - where $ms$ are the - manifests determined for $M'[U_1] , \ldots , M'[U_n]$. -1. If $T$ is a singleton type `$p$.type`, a manifest is generated with - the invocation `$\mathit{Mobj}$.singleType[T]($p$)` -1. If $T$ is a refined type $T' \{ R \}$, a manifest is generated for $T'$. + with the invocation `´\mathit{Mobj}´.classType[T](classOf[T], ´ms´)` + where ´ms´ are the + manifests determined for ´M'[U_1] , \ldots , M'[U_n]´. +1. If ´T´ is a singleton type `´p´.type`, a manifest is generated with + the invocation `´\mathit{Mobj}´.singleType[T](´p´)` +1. If ´T´ is a refined type ´T' \{ R \}´, a manifest is generated for ´T'´. (That is, refinements are never reflected in manifests). -1. If $T$ is an intersection type - `$T_1$ with $, \ldots ,$ with $T_n$` - where $n > 1$, the result depends on whether a full manifest is +1. If ´T´ is an intersection type + `´T_1´ with ´, \ldots ,´ with ´T_n´` + where ´n > 1´, the result depends on whether a full manifest is to be determined or not. - If $M$ is trait `Manifest`, then + If ´M´ is trait `Manifest`, then a manifest is generated with the invocation - `Manifest.intersectionType[T]($ms$)` where $ms$ are the manifests - determined for $M[T_1] , \ldots , M[T_n]$. - Otherwise, if $M$ is trait `ClassManifest`, + `Manifest.intersectionType[T](´ms´)` where ´ms´ are the manifests + determined for ´M[T_1] , \ldots , M[T_n]´. + Otherwise, if ´M´ is trait `ClassManifest`, then a manifest is generated for the [intersection dominator](03-types.html#type-erasure) - of the types $T_1 , \ldots , T_n$. -1. If $T$ is some other type, then if $M$ is trait `OptManifest`, + of the types ´T_1 , \ldots , T_n´. +1. If ´T´ is some other type, then if ´M´ is trait `OptManifest`, a manifest is generated from the designator `scala.reflect.NoManifest`. - If $M$ is a type different from `OptManifest`, a static error results. + If ´M´ is a type different from `OptManifest`, a static error results. diff --git a/spec/08-pattern-matching.md b/spec/08-pattern-matching.md index 4dee789118a5..0a2b222a3b06 100644 --- a/spec/08-pattern-matching.md +++ b/spec/08-pattern-matching.md @@ -39,12 +39,12 @@ than once in a pattern. Some examples of patterns are: 1. The pattern `ex: IOException` matches all instances of class `IOException`, binding variable `ex` to the instance. - 1. The pattern `Some(x)` matches values of the form `Some($v$)`, - binding `x` to the argument value $v$ of the `Some` constructor. + 1. The pattern `Some(x)` matches values of the form `Some(´v´)`, + binding `x` to the argument value ´v´ of the `Some` constructor. 1. The pattern `(x, _)` matches pairs of values, binding `x` to the first component of the pair. The second component is matched with a wildcard pattern. - 1. The pattern `x :: y :: xs` matches lists of length $\geq 2$, + 1. The pattern `x :: y :: xs` matches lists of length ´\geq 2´, binding `x` to the list's first element, `y` to the list's second element, and `xs` to the remainder. 1. The pattern `1 | 2 | 3` matches the integers between 1 and 3. @@ -60,9 +60,9 @@ patterns. | varid ``` -A _variable pattern_ $x$ is a simple identifier which starts with a +A _variable pattern_ ´x´ is a simple identifier which starts with a lower case letter. It matches any value, and binds the variable name -to that value. The type of $x$ is the expected type of the pattern as +to that value. The type of ´x´ is the expected type of the pattern as given from outside. A special case is the wild-card pattern `_` which is treated as if it was a fresh variable on each occurrence. @@ -73,11 +73,11 @@ which is treated as if it was a fresh variable on each occurrence. | ‘_’ ‘:’ TypePat ``` -A _typed pattern_ $x: T$ consists of a pattern variable $x$ and a -type pattern $T$. The type of $x$ is the type pattern $T$, where +A _typed pattern_ ´x: T´ consists of a pattern variable ´x´ and a +type pattern ´T´. The type of ´x´ is the type pattern ´T´, where each type variable and wildcard is replaced by a fresh, unknown type. This pattern matches any value matched by the [type pattern](#type-patterns) -$T$; it binds the variable name to +´T´; it binds the variable name to that value. ### Pattern Binders @@ -86,13 +86,13 @@ that value. Pattern2 ::= varid ‘@’ Pattern3 ``` -A _pattern binder_ `$x$@$p$` consists of a pattern variable $x$ and a -pattern $p$. The type of the variable $x$ is the static type $T$ implied -by the pattern $p$. -This pattern matches any value $v$ matched by the pattern $p$, +A _pattern binder_ `´x´@´p´` consists of a pattern variable ´x´ and a +pattern ´p´. The type of the variable ´x´ is the static type ´T´ implied +by the pattern ´p´. +This pattern matches any value ´v´ matched by the pattern ´p´, and it binds the variable name to that value. -A pattern $p$ _implies_ a type $T$ if the pattern matches only values of the type $T$. +A pattern ´p´ _implies_ a type ´T´ if the pattern matches only values of the type ´T´. ### Literal Patterns @@ -100,8 +100,8 @@ A pattern $p$ _implies_ a type $T$ if the pattern matches only values of the typ SimplePattern ::= Literal ``` -A _literal pattern_ $L$ matches any value that is equal (in terms of -`==`) to the literal $L$. The type of $L$ must conform to the +A _literal pattern_ ´L´ matches any value that is equal (in terms of +`==`) to the literal ´L´. The type of ´L´ must conform to the expected type of the pattern. ### Interpolated string patterns @@ -146,7 +146,7 @@ Then, XML pattern matching could be expressed like this: ```scala case xml""" - \$linktext + $linktext """ => ... ``` @@ -158,10 +158,10 @@ where linktext is a variable bound by the pattern. SimplePattern ::= StableId ``` -A _stable identifier pattern_ is a [stable identifier](03-types.html#paths) $r$. -The type of $r$ must conform to the expected -type of the pattern. The pattern matches any value $v$ such that -`$r$ == $v$` (see [here](12-the-scala-standard-library.html#root-classes)). +A _stable identifier pattern_ is a [stable identifier](03-types.html#paths) ´r´. +The type of ´r´ must conform to the expected +type of the pattern. The pattern matches any value ´v´ such that +`´r´ == ´v´` (see [here](12-the-scala-standard-library.html#root-classes)). To resolve the syntactic overlap with a variable pattern, a stable identifier pattern may not be a simple name starting with a lower-case @@ -194,24 +194,24 @@ one is a variable pattern. SimplePattern ::= StableId ‘(’ [Patterns] ‘)’ ``` -A _constructor pattern_ is of the form $c(p_1 , \ldots , p_n)$ where $n -\geq 0$. It consists of a stable identifier $c$, followed by element -patterns $p_1 , \ldots , p_n$. The constructor $c$ is a simple or +A _constructor pattern_ is of the form ´c(p_1 , \ldots , p_n)´ where ´n +\geq 0´. It consists of a stable identifier ´c´, followed by element +patterns ´p_1 , \ldots , p_n´. The constructor ´c´ is a simple or qualified name which denotes a [case class](05-classes-and-objects.html#case-classes). If the case class is monomorphic, then it must conform to the expected type of the pattern, and the formal -parameter types of $x$'s [primary constructor](05-classes-and-objects.html#class-definitions) -are taken as the expected types of the element patterns $p_1, \ldots , -p_n$. If the case class is polymorphic, then its type parameters are -instantiated so that the instantiation of $c$ conforms to the expected -type of the pattern. The instantiated formal parameter types of $c$'s +parameter types of ´x´'s [primary constructor](05-classes-and-objects.html#class-definitions) +are taken as the expected types of the element patterns ´p_1, \ldots , +p_n´. If the case class is polymorphic, then its type parameters are +instantiated so that the instantiation of ´c´ conforms to the expected +type of the pattern. The instantiated formal parameter types of ´c´'s primary constructor are then taken as the expected types of the -component patterns $p_1, \ldots , p_n$. The pattern matches all -objects created from constructor invocations $c(v_1 , \ldots , v_n)$ -where each element pattern $p_i$ matches the corresponding value -$v_i$. +component patterns ´p_1, \ldots , p_n´. The pattern matches all +objects created from constructor invocations ´c(v_1 , \ldots , v_n)´ +where each element pattern ´p_i´ matches the corresponding value +´v_i´. -A special case arises when $c$'s formal parameter types end in a +A special case arises when ´c´'s formal parameter types end in a repeated parameter. This is further discussed [here](#pattern-sequences). ### Tuple Patterns @@ -220,9 +220,9 @@ repeated parameter. This is further discussed [here](#pattern-sequences). SimplePattern ::= ‘(’ [Patterns] ‘)’ ``` -A _tuple pattern_ `($p_1 , \ldots , p_n$)` is an alias -for the constructor pattern `scala.Tuple$n$($p_1 , \ldots , p_n$)`, -where $n \geq 2$. The empty tuple +A _tuple pattern_ `(´p_1 , \ldots , p_n´)` is an alias +for the constructor pattern `scala.Tuple´n´(´p_1 , \ldots , p_n´)`, +where ´n \geq 2´. The empty tuple `()` is the unique value of type `scala.Unit`. ### Extractor Patterns @@ -231,39 +231,39 @@ where $n \geq 2$. The empty tuple SimplePattern ::= StableId ‘(’ [Patterns] ‘)’ ``` -An _extractor pattern_ $x(p_1 , \ldots , p_n)$ where $n \geq 0$ is of +An _extractor pattern_ ´x(p_1 , \ldots , p_n)´ where ´n \geq 0´ is of the same syntactic form as a constructor pattern. However, instead of -a case class, the stable identifier $x$ denotes an object which has a +a case class, the stable identifier ´x´ denotes an object which has a member method named `unapply` or `unapplySeq` that matches the pattern. An extractor pattern cannot match the value `null`. The implementation ensures that the `unapply`/`unapplySeq` method is not applied to `null`. -An `unapply` method in an object $x$ _matches_ the pattern -$x(p_1 , \ldots , p_n)$ if it has a single parameter (and, optionally, an +An `unapply` method in an object ´x´ _matches_ the pattern +´x(p_1 , \ldots , p_n)´ if it has a single parameter (and, optionally, an implicit parameter list) and one of the following applies: -* $n=0$ and `unapply`'s result type is `Boolean`. In this case - the extractor pattern matches all values $v$ for which - `$x$.unapply($v$)` yields `true`. -* $n=1$ and `unapply`'s result type is `Option[$T$]`, for some - type $T$. In this case, the (only) argument pattern $p_1$ is typed in - turn with expected type $T$. The extractor pattern matches then all - values $v$ for which `$x$.unapply($v$)` yields a value of form - `Some($v_1$)`, and $p_1$ matches $v_1$. -* $n>1$ and `unapply`'s result type is - `Option[($T_1 , \ldots , T_n$)]`, for some - types $T_1 , \ldots , T_n$. In this case, the argument patterns $p_1 - , \ldots , p_n$ are typed in turn with expected types $T_1 , \ldots , - T_n$. The extractor pattern matches then all values $v$ for which - `$x$.unapply($v$)` yields a value of form - `Some(($v_1 , \ldots , v_n$))`, and each pattern - $p_i$ matches the corresponding value $v_i$. - -An `unapplySeq` method in an object $x$ matches the pattern -$x(q_1 , \ldots , q_m, p_1 , \ldots , p_n)$ if it takes exactly one argument -and its result type is of the form `Option[($T_1 , \ldots , T_m$, Seq[S])]` (if `m = 0`, the type `Option[Seq[S]]` is also accepted). +* ´n=0´ and `unapply`'s result type is `Boolean`. In this case + the extractor pattern matches all values ´v´ for which + `´x´.unapply(´v´)` yields `true`. +* ´n=1´ and `unapply`'s result type is `Option[´T´]`, for some + type ´T´. In this case, the (only) argument pattern ´p_1´ is typed in + turn with expected type ´T´. The extractor pattern matches then all + values ´v´ for which `´x´.unapply(´v´)` yields a value of form + `Some(´v_1´)`, and ´p_1´ matches ´v_1´. +* ´n>1´ and `unapply`'s result type is + `Option[(´T_1 , \ldots , T_n´)]`, for some + types ´T_1 , \ldots , T_n´. In this case, the argument patterns ´p_1 + , \ldots , p_n´ are typed in turn with expected types ´T_1 , \ldots , + T_n´. The extractor pattern matches then all values ´v´ for which + `´x´.unapply(´v´)` yields a value of form + `Some((´v_1 , \ldots , v_n´))`, and each pattern + ´p_i´ matches the corresponding value ´v_i´. + +An `unapplySeq` method in an object ´x´ matches the pattern +´x(q_1 , \ldots , q_m, p_1 , \ldots , p_n)´ if it takes exactly one argument +and its result type is of the form `Option[(´T_1 , \ldots , T_m´, Seq[S])]` (if `m = 0`, the type `Option[Seq[S]]` is also accepted). This case is further discussed [below](#pattern-sequences). ###### Example @@ -294,20 +294,20 @@ val y = x match { SimplePattern ::= StableId ‘(’ [Patterns ‘,’] [varid ‘@’] ‘_’ ‘*’ ‘)’ ``` -A _pattern sequence_ $p_1 , \ldots , p_n$ appears in two contexts. -First, in a constructor pattern $c(q_1 , \ldots , q_m, p_1 , \ldots , p_n)$, where $c$ is a case class which has $m+1$ primary constructor parameters, ending in a [repeated parameter](04-basic-declarations-and-definitions.html#repeated-parameters) of type `S*`. -Second, in an extractor pattern $x(q_1 , \ldots , q_m, p_1 , \ldots , p_n)$ if the extractor object $x$ does not have an `unapply` method, -but it does define an `unapplySeq` method with a result type conforming to `Option[(T_1, ... , T_m, Seq[S])]` (if `m = 0`, the type `Option[Seq[S]]` is also accepted). The expected type for the patterns $p_i$ is $S$. +A _pattern sequence_ ´p_1 , \ldots , p_n´ appears in two contexts. +First, in a constructor pattern ´c(q_1 , \ldots , q_m, p_1 , \ldots , p_n)´, where ´c´ is a case class which has ´m+1´ primary constructor parameters, ending in a [repeated parameter](04-basic-declarations-and-definitions.html#repeated-parameters) of type `S*`. +Second, in an extractor pattern ´x(q_1 , \ldots , q_m, p_1 , \ldots , p_n)´ if the extractor object ´x´ does not have an `unapply` method, +but it does define an `unapplySeq` method with a result type conforming to `Option[(T_1, ... , T_m, Seq[S])]` (if `m = 0`, the type `Option[Seq[S]]` is also accepted). The expected type for the patterns ´p_i´ is ´S´. The last pattern in a pattern sequence may be a _sequence wildcard_ `_*`. -Each element pattern $p_i$ is type-checked with -$S$ as expected type, unless it is a sequence wildcard. If a final -sequence wildcard is present, the pattern matches all values $v$ that +Each element pattern ´p_i´ is type-checked with +´S´ as expected type, unless it is a sequence wildcard. If a final +sequence wildcard is present, the pattern matches all values ´v´ that are sequences which start with elements matching patterns -$p_1 , \ldots , p_{n-1}$. If no final sequence wildcard is given, the -pattern matches all values $v$ that are sequences of -length $n$ which consist of elements matching patterns $p_1 , \ldots , -p_n$. +´p_1 , \ldots , p_{n-1}´. If no final sequence wildcard is given, the +pattern matches all values ´v´ that are sequences of +length ´n´ which consist of elements matching patterns ´p_1 , \ldots , +p_n´. ### Infix Operation Patterns @@ -315,14 +315,14 @@ p_n$. Pattern3 ::= SimplePattern {id [nl] SimplePattern} ``` -An _infix operation pattern_ $p;\mathit{op};q$ is a shorthand for the -constructor or extractor pattern $\mathit{op}(p, q)$. The precedence and +An _infix operation pattern_ ´p;\mathit{op};q´ is a shorthand for the +constructor or extractor pattern ´\mathit{op}(p, q)´. The precedence and associativity of operators in patterns is the same as in [expressions](06-expressions.html#prefix,-infix,-and-postfix-operations). -An infix operation pattern $p;\mathit{op};(q_1 , \ldots , q_n)$ is a -shorthand for the constructor or extractor pattern $\mathit{op}(p, q_1 -, \ldots , q_n)$. +An infix operation pattern ´p;\mathit{op};(q_1 , \ldots , q_n)´ is a +shorthand for the constructor or extractor pattern ´\mathit{op}(p, q_1 +, \ldots , q_n)´. ### Pattern Alternatives @@ -330,11 +330,11 @@ shorthand for the constructor or extractor pattern $\mathit{op}(p, q_1 Pattern ::= Pattern1 { ‘|’ Pattern1 } ``` -A _pattern alternative_ `$p_1$ | $\ldots$ | $p_n$` -consists of a number of alternative patterns $p_i$. All alternative +A _pattern alternative_ `´p_1´ | ´\ldots´ | ´p_n´` +consists of a number of alternative patterns ´p_i´. All alternative patterns are type checked with the expected type of the pattern. They may not bind variables other than wildcards. The alternative pattern -matches a value $v$ if at least one its alternatives matches $v$. +matches a value ´v´ if at least one its alternatives matches ´v´. ### XML Patterns @@ -358,14 +358,14 @@ type `Seq[A]`. ### Irrefutable Patterns -A pattern $p$ is _irrefutable_ for a type $T$, if one of the following applies: +A pattern ´p´ is _irrefutable_ for a type ´T´, if one of the following applies: -1. $p$ is a variable pattern, -1. $p$ is a typed pattern $x: T'$, and $T <: T'$, -1. $p$ is a constructor pattern $c(p_1 , \ldots , p_n)$, the type $T$ - is an instance of class $c$, the [primary constructor](05-classes-and-objects.html#class-definitions) - of type $T$ has argument types $T_1 , \ldots , T_n$, and each $p_i$ is - irrefutable for $T_i$. +1. ´p´ is a variable pattern, +1. ´p´ is a typed pattern ´x: T'´, and ´T <: T'´, +1. ´p´ is a constructor pattern ´c(p_1 , \ldots , p_n)´, the type ´T´ + is an instance of class ´c´, the [primary constructor](05-classes-and-objects.html#class-definitions) + of type ´T´ has argument types ´T_1 , \ldots , T_n´, and each ´p_i´ is + irrefutable for ´T_i´. ## Type Patterns @@ -374,42 +374,42 @@ A pattern $p$ is _irrefutable_ for a type $T$, if one of the following applies: ``` Type patterns consist of types, type variables, and wildcards. -A type pattern $T$ is of one of the following forms: +A type pattern ´T´ is of one of the following forms: -* A reference to a class $C$, $p.C$, or `$T$#$C$`. This +* A reference to a class ´C´, ´p.C´, or `´T´#´C´`. This type pattern matches any non-null instance of the given class. Note that the prefix of the class, if it exists, is relevant for determining - class instances. For instance, the pattern $p.C$ matches only - instances of classes $C$ which were created with the path $p$ as + class instances. For instance, the pattern ´p.C´ matches only + instances of classes ´C´ which were created with the path ´p´ as prefix. This also applies to prefixes which are not given syntactically. - For example, if $C$ refers to a class defined in the nearest enclosing - class and is thus equivalent to $this.C$, it is considered to have a prefix. + For example, if ´C´ refers to a class defined in the nearest enclosing + class and is thus equivalent to ´this.C´, it is considered to have a prefix. The bottom types `scala.Nothing` and `scala.Null` cannot be used as type patterns, because they would match nothing in any case. -* A singleton type `$p$.type`. This type pattern matches only the value - denoted by the path $p$ (the `eq` method is used to compare the matched value - to $p$). +* A singleton type `´p´.type`. This type pattern matches only the value + denoted by the path ´p´ (the `eq` method is used to compare the matched value + to ´p´). -* A literal type `$lit$`. This type pattern matches only the value - denoted by the literal $lit$ (the `==` method is used to compare the matched - value to $lit$). +* A literal type `´lit´`. This type pattern matches only the value + denoted by the literal ´lit´ (the `==` method is used to compare the matched + value to ´lit´). -* A compound type pattern `$T_1$ with $\ldots$ with $T_n$` where each $T_i$ is a +* A compound type pattern `´T_1´ with ´\ldots´ with ´T_n´` where each ´T_i´ is a type pattern. This type pattern matches all values that are matched by each of - the type patterns $T_i$. + the type patterns ´T_i´. -* A parameterized type pattern $T[a_1 , \ldots , a_n]$, where the $a_i$ +* A parameterized type pattern ´T[a_1 , \ldots , a_n]´, where the ´a_i´ are type variable patterns or wildcards `_`. - This type pattern matches all values which match $T$ for + This type pattern matches all values which match ´T´ for some arbitrary instantiation of the type variables and wildcards. The bounds or alias type of these type variable are determined as described [here](#type-parameter-inference-in-patterns). -* A parameterized type pattern `scala.Array$[T_1]$`, where - $T_1$ is a type pattern. This type pattern matches any non-null instance - of type `scala.Array$[U_1]$`, where $U_1$ is a type matched by $T_1$. +* A parameterized type pattern `scala.Array´[T_1]´`, where + ´T_1´ is a type pattern. This type pattern matches any non-null instance + of type `scala.Array´[U_1]´`, where ´U_1´ is a type matched by ´T_1´. Types which are not of one of the forms described above are also accepted as type patterns. However, such type patterns will be translated to their @@ -429,17 +429,17 @@ pattern. ### Type parameter inference for typed patterns -Assume a typed pattern $p: T'$. Let $T$ result from $T'$ where all wildcards in -$T'$ are renamed to fresh variable names. Let $a_1 , \ldots , a_n$ be -the type variables in $T$. These type variables are considered bound -in the pattern. Let the expected type of the pattern be $\mathit{pt}$. +Assume a typed pattern ´p: T'´. Let ´T´ result from ´T'´ where all wildcards in +´T'´ are renamed to fresh variable names. Let ´a_1 , \ldots , a_n´ be +the type variables in ´T´. These type variables are considered bound +in the pattern. Let the expected type of the pattern be ´\mathit{pt}´. Type parameter inference constructs first a set of subtype constraints over -the type variables $a_i$. The initial constraints set $\mathcal{C}\_0$ reflects -just the bounds of these type variables. That is, assuming $T$ has -bound type variables $a_1 , \ldots , a_n$ which correspond to class -type parameters $a_1' , \ldots , a_n'$ with lower bounds $L_1, \ldots , L_n$ -and upper bounds $U_1 , \ldots , U_n$, $\mathcal{C}_0$ contains the constraints +the type variables ´a_i´. The initial constraints set ´\mathcal{C}\_0´ reflects +just the bounds of these type variables. That is, assuming ´T´ has +bound type variables ´a_1 , \ldots , a_n´ which correspond to class +type parameters ´a_1' , \ldots , a_n'´ with lower bounds ´L_1, \ldots , L_n´ +and upper bounds ´U_1 , \ldots , U_n´, ´\mathcal{C}_0´ contains the constraints $$ \begin{cases} @@ -448,45 +448,45 @@ a_i &<: \sigma U_i & \quad (i = 1, \ldots , n) \\\\ \end{cases} $$ -where $\sigma$ is the substitution $[a_1' := a_1 , \ldots , a_n' :=a_n]$. +where ´\sigma´ is the substitution ´[a_1' := a_1 , \ldots , a_n' :=a_n]´. -The set $\mathcal{C}_0$ is then augmented by further subtype constraints. There are two +The set ´\mathcal{C}_0´ is then augmented by further subtype constraints. There are two cases. ###### Case 1 -If there exists a substitution $\sigma$ over the type variables $a_i , \ldots , a_n$ such that $\sigma T$ conforms to $\mathit{pt}$, one determines the weakest subtype constraints -$\mathcal{C}\_1$ over the type variables $a_1, \ldots , a_n$ such that $\mathcal{C}\_0 \wedge \mathcal{C}_1$ implies that $T$ conforms to $\mathit{pt}$. +If there exists a substitution ´\sigma´ over the type variables ´a_i , \ldots , a_n´ such that ´\sigma T´ conforms to ´\mathit{pt}´, one determines the weakest subtype constraints +´\mathcal{C}\_1´ over the type variables ´a_1, \ldots , a_n´ such that ´\mathcal{C}\_0 \wedge \mathcal{C}_1´ implies that ´T´ conforms to ´\mathit{pt}´. ###### Case 2 -Otherwise, if $T$ can not be made to conform to $\mathit{pt}$ by +Otherwise, if ´T´ can not be made to conform to ´\mathit{pt}´ by instantiating its type variables, one determines all type variables in -$\mathit{pt}$ which are defined as type parameters of a method enclosing -the pattern. Let the set of such type parameters be $b_1 , \ldots , -b_m$. Let $\mathcal{C}\_0'$ be the subtype constraints reflecting the bounds of the -type variables $b_i$. If $T$ denotes an instance type of a final -class, let $\mathcal{C}\_2$ be the weakest set of subtype constraints over the type -variables $a_1 , \ldots , a_n$ and $b_1 , \ldots , b_m$ such that -$\mathcal{C}\_0 \wedge \mathcal{C}\_0' \wedge \mathcal{C}\_2$ implies that $T$ conforms to -$\mathit{pt}$. If $T$ does not denote an instance type of a final class, -let $\mathcal{C}\_2$ be the weakest set of subtype constraints over the type variables -$a_1 , \ldots , a_n$ and $b_1 , \ldots , b_m$ such that $\mathcal{C}\_0 \wedge -\mathcal{C}\_0' \wedge \mathcal{C}\_2$ implies that it is possible to construct a type -$T'$ which conforms to both $T$ and $\mathit{pt}$. It is a static error if -there is no satisfiable set of constraints $\mathcal{C}\_2$ with this property. +´\mathit{pt}´ which are defined as type parameters of a method enclosing +the pattern. Let the set of such type parameters be ´b_1 , \ldots , +b_m´. Let ´\mathcal{C}\_0'´ be the subtype constraints reflecting the bounds of the +type variables ´b_i´. If ´T´ denotes an instance type of a final +class, let ´\mathcal{C}\_2´ be the weakest set of subtype constraints over the type +variables ´a_1 , \ldots , a_n´ and ´b_1 , \ldots , b_m´ such that +´\mathcal{C}\_0 \wedge \mathcal{C}\_0' \wedge \mathcal{C}\_2´ implies that ´T´ conforms to +´\mathit{pt}´. If ´T´ does not denote an instance type of a final class, +let ´\mathcal{C}\_2´ be the weakest set of subtype constraints over the type variables +´a_1 , \ldots , a_n´ and ´b_1 , \ldots , b_m´ such that ´\mathcal{C}\_0 \wedge +\mathcal{C}\_0' \wedge \mathcal{C}\_2´ implies that it is possible to construct a type +´T'´ which conforms to both ´T´ and ´\mathit{pt}´. It is a static error if +there is no satisfiable set of constraints ´\mathcal{C}\_2´ with this property. The final step consists in choosing type bounds for the type variables which imply the established constraint system. The process is different for the two cases above. ###### Case 1 -We take $a_i >: L_i <: U_i$ where each $L_i$ is minimal and each $U_i$ is maximal wrt $<:$ such that $a_i >: L_i <: U_i$ for $i = 1, \ldots, n$ implies $\mathcal{C}\_0 \wedge \mathcal{C}\_1$. +We take ´a_i >: L_i <: U_i´ where each ´L_i´ is minimal and each ´U_i´ is maximal wrt ´<:´ such that ´a_i >: L_i <: U_i´ for ´i = 1, \ldots, n´ implies ´\mathcal{C}\_0 \wedge \mathcal{C}\_1´. ###### Case 2 -We take $a_i >: L_i <: U_i$ and $b\_i >: L_i' <: U_i' $ where each $L_i$ -and $L_j'$ is minimal and each $U_i$ and $U_j'$ is maximal such that -$a_i >: L_i <: U_i$ for $i = 1 , \ldots , n$ and -$b_j >: L_j' <: U_j'$ for $j = 1 , \ldots , m$ -implies $\mathcal{C}\_0 \wedge \mathcal{C}\_0' \wedge \mathcal{C}_2$. +We take ´a_i >: L_i <: U_i´ and ´b\_i >: L_i' <: U_i' ´ where each ´L_i´ +and ´L_j'´ is minimal and each ´U_i´ and ´U_j'´ is maximal such that +´a_i >: L_i <: U_i´ for ´i = 1 , \ldots , n´ and +´b_j >: L_j' <: U_j'´ for ´j = 1 , \ldots , m´ +implies ´\mathcal{C}\_0 \wedge \mathcal{C}\_0' \wedge \mathcal{C}_2´. In both cases, local type inference is permitted to limit the complexity of inferred bounds. Minimality and maximality of types have @@ -494,10 +494,10 @@ to be understood relative to the set of types of acceptable complexity. ### Type parameter inference for constructor patterns -Assume a constructor pattern $C(p_1 , \ldots , p_n)$ where class $C$ -has type parameters $a_1 , \ldots , a_n$. These type parameters +Assume a constructor pattern ´C(p_1 , \ldots , p_n)´ where class ´C´ +has type parameters ´a_1 , \ldots , a_n´. These type parameters are inferred in the same way as for the typed pattern -`(_: $C[a_1 , \ldots , a_n]$)`. +`(_: ´C[a_1 , \ldots , a_n]´)`. ###### Example Consider the program fragment: @@ -583,54 +583,56 @@ function's declared result type, `Number`. A _pattern matching expression_ ```scala -e match { case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$ } +e match { case ´p_1´ => ´b_1´ ´\ldots´ case ´p_n´ => ´b_n´ } ``` -consists of a selector expression $e$ and a number $n > 0$ of -cases. Each case consists of a (possibly guarded) pattern $p_i$ and a -block $b_i$. Each $p_i$ might be complemented by a guard -`if $e$` where $e$ is a boolean expression. +consists of a selector expression ´e´ and a number ´n > 0´ of +cases. Each case consists of a (possibly guarded) pattern ´p_i´ and a +block ´b_i´. Each ´p_i´ might be complemented by a guard +`if ´e´` where ´e´ is a boolean expression. The scope of the pattern -variables in $p_i$ comprises the pattern's guard and the corresponding block $b_i$. +variables in ´p_i´ comprises the pattern's guard and the corresponding block ´b_i´. -Let $T$ be the type of the selector expression $e$ and let $a_1 -, \ldots , a_m$ be the type parameters of all methods enclosing -the pattern matching expression. For every $a_i$, let $L_i$ be its -lower bound and $U_i$ be its higher bound. Every pattern $p \in \{p_1, , \ldots , p_n\}$ +Let ´T´ be the type of the selector expression ´e´ and let ´a_1 +, \ldots , a_m´ be the type parameters of all methods enclosing +the pattern matching expression. For every ´a_i´, let ´L_i´ be its +lower bound and ´U_i´ be its higher bound. Every pattern ´p \in \{p_1, , \ldots , p_n\}´ can be typed in two ways. First, it is attempted -to type $p$ with $T$ as its expected type. If this fails, $p$ is -instead typed with a modified expected type $T'$ which results from -$T$ by replacing every occurrence of a type parameter $a_i$ by -\mbox{\sl undefined}. If this second step fails also, a compile-time -error results. If the second step succeeds, let $T_p$ be the type of -pattern $p$ seen as an expression. One then determines minimal bounds -$L_11 , \ldots , L_m'$ and maximal bounds $U_1' , \ldots , U_m'$ such -that for all $i$, $L_i <: L_i'$ and $U_i' <: U_i$ and the following +to type ´p´ with ´T´ as its expected type. If this fails, ´p´ is +instead typed with a modified expected type ´T'´ which results from +´T´ by replacing every occurrence of a type parameter ´a_i´ by +*undefined*. If this second step fails also, a compile-time +error results. If the second step succeeds, let ´T_p´ be the type of +pattern ´p´ seen as an expression. One then determines minimal bounds +´L_11 , \ldots , L_m'´ and maximal bounds ´U_1' , \ldots , U_m'´ such +that for all ´i´, ´L_i <: L_i'´ and ´U_i' <: U_i´ and the following constraint system is satisfied: -$$L_1 <: a_1 <: U_1\;\wedge\;\ldots\;\wedge\;L_m <: a_m <: U_m \ \Rightarrow\ T_p <: T$$ +$$ +L_1 <: a_1 <: U_1\;\wedge\;\ldots\;\wedge\;L_m <: a_m <: U_m \ \Rightarrow\ T_p <: T +$$ If no such bounds can be found, a compile time error results. If such -bounds are found, the pattern matching clause starting with $p$ is -then typed under the assumption that each $a_i$ has lower bound $L_i'$ -instead of $L_i$ and has upper bound $U_i'$ instead of $U_i$. +bounds are found, the pattern matching clause starting with ´p´ is +then typed under the assumption that each ´a_i´ has lower bound ´L_i'´ +instead of ´L_i´ and has upper bound ´U_i'´ instead of ´U_i´. -The expected type of every block $b_i$ is the expected type of the +The expected type of every block ´b_i´ is the expected type of the whole pattern matching expression. The type of the pattern matching expression is then the [weak least upper bound](03-types.html#weak-conformance) of the types of all blocks -$b_i$. +´b_i´. When applying a pattern matching expression to a selector value, patterns are tried in sequence until one is found which matches the -[selector value](#patterns). Say this case is `case $p_i \Rightarrow b_i$`. -The result of the whole expression is the result of evaluating $b_i$, -where all pattern variables of $p_i$ are bound to +[selector value](#patterns). Say this case is `case ´p_i \Rightarrow b_i´`. +The result of the whole expression is the result of evaluating ´b_i´, +where all pattern variables of ´p_i´ are bound to the corresponding parts of the selector value. If no matching pattern is found, a `scala.MatchError` exception is thrown. The pattern in a case may also be followed by a guard suffix -`if e` with a boolean expression $e$. The guard expression is +`if e` with a boolean expression ´e´. The guard expression is evaluated if the preceding pattern in the case matches. If the guard expression evaluates to `true`, the pattern match succeeds as normal. If the guard expression evaluates to `false`, the pattern @@ -698,57 +700,57 @@ conforms to its expected type, `T`. An anonymous function can be defined by a sequence of cases ```scala -{ case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$ } +{ case ´p_1´ => ´b_1´ ´\ldots´ case ´p_n´ => ´b_n´ } ``` which appear as an expression without a prior `match`. The expected type of such an expression must in part be defined. It must -be either `scala.Function$k$[$S_1 , \ldots , S_k$, $R$]` for some $k > 0$, -or `scala.PartialFunction[$S_1$, $R$]`, where the -argument type(s) $S_1 , \ldots , S_k$ must be fully determined, but the result type -$R$ may be undetermined. +be either `scala.Function´k´[´S_1 , \ldots , S_k´, ´R´]` for some ´k > 0´, +or `scala.PartialFunction[´S_1´, ´R´]`, where the +argument type(s) ´S_1 , \ldots , S_k´ must be fully determined, but the result type +´R´ may be undetermined. If the expected type is [SAM-convertible](06-expressions.html#sam-conversion) -to `scala.Function$k$[$S_1 , \ldots , S_k$, $R$]`, +to `scala.Function´k´[´S_1 , \ldots , S_k´, ´R´]`, the expression is taken to be equivalent to the anonymous function: ```scala -($x_1: S_1 , \ldots , x_k: S_k$) => ($x_1 , \ldots , x_k$) match { - case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$ +(´x_1: S_1 , \ldots , x_k: S_k´) => (´x_1 , \ldots , x_k´) match { + case ´p_1´ => ´b_1´ ´\ldots´ case ´p_n´ => ´b_n´ } ``` -Here, each $x_i$ is a fresh name. +Here, each ´x_i´ is a fresh name. As was shown [here](06-expressions.html#anonymous-functions), this anonymous function is in turn equivalent to the following instance creation expression, where - $T$ is the weak least upper bound of the types of all $b_i$. + ´T´ is the weak least upper bound of the types of all ´b_i´. ```scala -new scala.Function$k$[$S_1 , \ldots , S_k$, $T$] { - def apply($x_1: S_1 , \ldots , x_k: S_k$): $T$ = ($x_1 , \ldots , x_k$) match { - case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$ +new scala.Function´k´[´S_1 , \ldots , S_k´, ´T´] { + def apply(´x_1: S_1 , \ldots , x_k: S_k´): ´T´ = (´x_1 , \ldots , x_k´) match { + case ´p_1´ => ´b_1´ ´\ldots´ case ´p_n´ => ´b_n´ } } ``` -If the expected type is `scala.PartialFunction[$S$, $R$]`, +If the expected type is `scala.PartialFunction[´S´, ´R´]`, the expression is taken to be equivalent to the following instance creation expression: ```scala -new scala.PartialFunction[$S$, $T$] { - def apply($x$: $S$): $T$ = x match { - case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$ +new scala.PartialFunction[´S´, ´T´] { + def apply(´x´: ´S´): ´T´ = x match { + case ´p_1´ => ´b_1´ ´\ldots´ case ´p_n´ => ´b_n´ } - def isDefinedAt($x$: $S$): Boolean = { - case $p_1$ => true $\ldots$ case $p_n$ => true + def isDefinedAt(´x´: ´S´): Boolean = { + case ´p_1´ => true ´\ldots´ case ´p_n´ => true case _ => false } } ``` -Here, $x$ is a fresh name and $T$ is the weak least upper bound of the -types of all $b_i$. The final default case in the `isDefinedAt` -method is omitted if one of the patterns $p_1 , \ldots , p_n$ is +Here, ´x´ is a fresh name and ´T´ is the weak least upper bound of the +types of all ´b_i´. The final default case in the `isDefinedAt` +method is omitted if one of the patterns ´p_1 , \ldots , p_n´ is already a variable or wildcard pattern. ###### Example diff --git a/spec/09-top-level-definitions.md b/spec/09-top-level-definitions.md index 3d6b59be459a..33c436e8d77b 100644 --- a/spec/09-top-level-definitions.md +++ b/spec/09-top-level-definitions.md @@ -26,10 +26,10 @@ package clause. A _compilation unit_ ```scala -package $p_1$; -$\ldots$ -package $p_n$; -$\mathit{stats}$ +package ´p_1´; +´\ldots´ +package ´p_n´; +´\mathit{stats}´ ``` starting with one or more package @@ -37,10 +37,10 @@ clauses is equivalent to a compilation unit consisting of the packaging ```scala -package $p_1$ { $\ldots$ - package $p_n$ { - $\mathit{stats}$ - } $\ldots$ +package ´p_1´ { ´\ldots´ + package ´p_n´ { + ´\mathit{stats}´ + } ´\ldots´ } ``` @@ -64,15 +64,15 @@ objects and packages. Unlike other objects, packages are not introduced by a definition. Instead, the set of members of a package is determined by packagings. -A packaging `package $p$ { $\mathit{ds}$ }` injects all -definitions in $\mathit{ds}$ as members into the package whose qualified name -is $p$. Members of a package are called _top-level_ definitions. -If a definition in $\mathit{ds}$ is labeled `private`, it is +A packaging `package ´p´ { ´\mathit{ds}´ }` injects all +definitions in ´\mathit{ds}´ as members into the package whose qualified name +is ´p´. Members of a package are called _top-level_ definitions. +If a definition in ´\mathit{ds}´ is labeled `private`, it is visible only for other members in the package. -Inside the packaging, all members of package $p$ are visible under their +Inside the packaging, all members of package ´p´ are visible under their simple names. However this rule does not extend to members of enclosing -packages of $p$ that are designated by a prefix of the path $p$. +packages of ´p´ that are designated by a prefix of the path ´p´. ```scala package org.net.prj { @@ -84,7 +84,7 @@ all members of package `org.net.prj` are visible under their simple names, but members of packages `org` or `org.net` require explicit qualification or imports. -Selections $p$.$m$ from $p$ as well as imports from $p$ +Selections ´p´.´m´ from ´p´ as well as imports from ´p´ work as for objects. However, unlike other objects, packages may not be used as values. It is illegal to have a package with the same fully qualified name as a module or a class. @@ -100,14 +100,14 @@ are visible to each other without qualification. PackageObject ::= ‘package’ ‘object’ ObjectDef ``` -A _package object_ `package object $p$ extends $t$` adds the -members of template $t$ to the package $p$. There can be only one +A _package object_ `package object ´p´ extends ´t´` adds the +members of template ´t´ to the package ´p´. There can be only one package object per package. The standard naming convention is to place the definition above in a file named `package.scala` that's -located in the directory corresponding to package $p$. +located in the directory corresponding to package ´p´. The package object should not define a member with the same name as -one of the top-level objects or classes defined in package $p$. If +one of the top-level objects or classes defined in package ´p´. If there is a name conflict, the behavior of the program is currently undefined. It is expected that this restriction will be lifted in a future version of Scala. @@ -120,8 +120,8 @@ QualId ::= id {‘.’ id} A reference to a package takes the form of a qualified identifier. Like all other references, package references are relative. That is, -a package reference starting in a name $p$ will be looked up in the -closest enclosing scope that defines a member named $p$. +a package reference starting in a name ´p´ will be looked up in the +closest enclosing scope that defines a member named ´p´. If a package name is shadowed, it's possible to refer to its fully-qualified name by prefixing it with @@ -171,8 +171,8 @@ passed to the `main` method as a parameter of type The `main` method of a program can be directly defined in the object, or it can be inherited. The scala library defines a special class `scala.App` whose body acts as a `main` method. -An objects $m$ inheriting from this class is thus a program, -which executes the initialization code of the object $m$. +An objects ´m´ inheriting from this class is thus a program, +which executes the initialization code of the object ´m´. ###### Example The following example will create a hello world program by defining diff --git a/spec/10-xml-expressions-and-patterns.md b/spec/10-xml-expressions-and-patterns.md index c147d728391c..a9b7edb14fff 100644 --- a/spec/10-xml-expressions-and-patterns.md +++ b/spec/10-xml-expressions-and-patterns.md @@ -75,8 +75,8 @@ AttValue ::= ‘"’ {CharQ | CharRef} ‘"’ ScalaExpr ::= Block -CharData ::= { CharNoRef } $\textit{ without}$ {CharNoRef}‘{’CharB {CharNoRef} - $\textit{ and without}$ {CharNoRef}‘]]>’{CharNoRef} +CharData ::= { CharNoRef } ´\textit{ without}´ {CharNoRef}‘{’CharB {CharNoRef} + ´\textit{ and without}´ {CharNoRef}‘]]>’{CharNoRef} ``` @@ -89,17 +89,17 @@ Thus, `{{` represents the XML text `{` and does not introduce an embedded Scala ```ebnf BaseChar, CDSect, Char, Comment, CombiningChar, Ideographic, NameChar, PI, S, Reference - ::= $\textit{“as in W3C XML”}$ + ::= ´\textit{“as in W3C XML”}´ -Char1 ::= Char $\textit{ without}$ ‘<’ | ‘&’ -CharQ ::= Char1 $\textit{ without}$ ‘"’ -CharA ::= Char1 $\textit{ without}$ ‘'’ -CharB ::= Char1 $\textit{ without}$ ‘{’ +Char1 ::= Char ´\textit{ without}´ ‘<’ | ‘&’ +CharQ ::= Char1 ´\textit{ without}´ ‘"’ +CharA ::= Char1 ´\textit{ without}´ ‘'’ +CharB ::= Char1 ´\textit{ without}´ ‘{’ Name ::= XNameStart {NameChar} XNameStart ::= ‘_’ | BaseChar | Ideographic - $\textit{ (as in W3C XML, but without }$ ‘:’$)$ + ´\textit{ (as in W3C XML, but without }´ ‘:’´)´ ``` ## XML patterns diff --git a/spec/11-annotations.md b/spec/11-annotations.md index bfb23c53f3da..881442b9f624 100644 --- a/spec/11-annotations.md +++ b/spec/11-annotations.md @@ -14,15 +14,15 @@ chapter: 11 ## Definition Annotations associate meta-information with definitions. -A simple annotation has the form `@$c$` or `@$c(a_1 , \ldots , a_n)$`. -Here, $c$ is a constructor of a class $C$, which must conform +A simple annotation has the form `@´c´` or `@´c(a_1 , \ldots , a_n)´`. +Here, ´c´ is a constructor of a class ´C´, which must conform to the class `scala.Annotation`. Annotations may apply to definitions or declarations, types, or expressions. An annotation of a definition or declaration appears in front of that definition. An annotation of a type appears after -that type. An annotation of an expression $e$ appears after the -expression $e$, separated by a colon. More than one annotation clause +that type. An annotation of an expression ´e´ appears after the +expression ´e´, separated by a colon. More than one annotation clause may apply to an entity. The order in which these annotations are given does not matter. @@ -105,7 +105,7 @@ Java platform, the following annotations have a standard meaning. ```scala def f(x: Option[Int]) = (x: @unchecked) match { - case Some(y) => y + case Some(y) => y } ``` diff --git a/spec/12-the-scala-standard-library.md b/spec/12-the-scala-standard-library.md index 271a7f19921b..80d66c0c4166 100644 --- a/spec/12-the-scala-standard-library.md +++ b/spec/12-the-scala-standard-library.md @@ -56,10 +56,10 @@ abstract class Any { final def != (that: Any): Boolean = !(this == that) /** Hash code; abstract here */ - def hashCode: Int = $\ldots$ + def hashCode: Int = ´\ldots´ /** Textual representation; abstract here */ - def toString: String = $\ldots$ + def toString: String = ´\ldots´ /** Type test; needs to be inlined to work as given */ def isInstanceOf[a]: Boolean @@ -78,35 +78,35 @@ final class AnyVal extends Any /** The root class of all reference types */ class AnyRef extends Any { def equals(that: Any): Boolean = this eq that - final def eq(that: AnyRef): Boolean = $\ldots$ // reference equality + final def eq(that: AnyRef): Boolean = ´\ldots´ // reference equality final def ne(that: AnyRef): Boolean = !(this eq that) - def hashCode: Int = $\ldots$ // hashCode computed from allocation address - def toString: String = $\ldots$ // toString computed from hashCode and class name + def hashCode: Int = ´\ldots´ // hashCode computed from allocation address + def toString: String = ´\ldots´ // toString computed from hashCode and class name def synchronized[T](body: => T): T // execute `body` in while locking `this`. } ``` -The type test `$x$.isInstanceOf[$T$]` is equivalent to a typed +The type test `´x´.isInstanceOf[´T´]` is equivalent to a typed pattern match ```scala -$x$ match { - case _: $T'$ => true +´x´ match { + case _: ´T'´ => true case _ => false } ``` -where the type $T'$ is the same as $T$ except if $T$ is -of the form $D$ or $D[\mathit{tps}]$ where $D$ is a type member of some outer class $C$. -In this case $T'$ is `$C$#$D$` (or `$C$#$D[tps]$`, respectively), whereas $T$ itself would expand to `$C$.this.$D[tps]$`. +where the type ´T'´ is the same as ´T´ except if ´T´ is +of the form ´D´ or ´D[\mathit{tps}]´ where ´D´ is a type member of some outer class ´C´. +In this case ´T'´ is `´C´#´D´` (or `´C´#´D[tps]´`, respectively), whereas ´T´ itself would expand to `´C´.this.´D[tps]´`. In other words, an `isInstanceOf` test does not check that types have the same enclosing instance. -The test `$x$.asInstanceOf[$T$]` is treated specially if $T$ is a +The test `´x´.asInstanceOf[´T´]` is treated specially if ´T´ is a [numeric value type](#value-classes). In this case the cast will be translated to an application of a [conversion method](#numeric-value-types) -`x.to$T$`. For non-numeric values $x$ the operation will raise a +`x.to´T´`. For non-numeric values ´x´ the operation will raise a `ClassCastException`. ## Value Classes @@ -146,14 +146,14 @@ from every numeric value type to all higher-ranked numeric value types. Therefore, lower-ranked types are implicitly converted to higher-ranked types when required by the [context](06-expressions.html#implicit-conversions). -Given two numeric value types $S$ and $T$, the _operation type_ of -$S$ and $T$ is defined as follows: If both $S$ and $T$ are subrange -types then the operation type of $S$ and $T$ is `Int`. Otherwise -the operation type of $S$ and $T$ is the larger of the two types wrt -ranking. Given two numeric values $v$ and $w$ the operation type of -$v$ and $w$ is the operation type of their run-time types. +Given two numeric value types ´S´ and ´T´, the _operation type_ of +´S´ and ´T´ is defined as follows: If both ´S´ and ´T´ are subrange +types then the operation type of ´S´ and ´T´ is `Int`. Otherwise +the operation type of ´S´ and ´T´ is the larger of the two types wrt +ranking. Given two numeric values ´v´ and ´w´ the operation type of +´v´ and ´w´ is the operation type of their run-time types. -Any numeric value type $T$ supports the following methods. +Any numeric value type ´T´ supports the following methods. * Comparison methods for equals (`==`), not-equals (`!=`), less-than (`<`), greater-than (`>`), less-than-or-equals @@ -166,13 +166,13 @@ Any numeric value type $T$ supports the following methods. * Arithmetic methods addition (`+`), subtraction (`-`), multiplication (`*`), division (`/`), and remainder (`%`), which each exist in 7 overloaded alternatives. Each - alternative takes a parameter of some numeric value type $U$. Its - result type is the operation type of $T$ and $U$. The operation is + alternative takes a parameter of some numeric value type ´U´. Its + result type is the operation type of ´T´ and ´U´. The operation is evaluated by converting the receiver and its argument to their operation type and performing the given arithmetic operation of that type. * Parameterless arithmetic methods identity (`+`) and negation - (`-`), with result type $T$. The first of these returns the + (`-`), with result type ´T´. The first of these returns the receiver unchanged, whereas the second returns its negation. * Conversion methods `toByte`, `toShort`, `toChar`, `toInt`, `toLong`, `toFloat`, `toDouble` which @@ -189,21 +189,21 @@ Integer numeric value types support in addition the following operations: {`|`}, and bitwise-exclusive-or (`^`), which each exist in 5 overloaded alternatives. Each alternative takes a parameter of some integer numeric value type. Its result type is the operation type of - $T$ and $U$. The operation is evaluated by converting the receiver and + ´T´ and ´U´. The operation is evaluated by converting the receiver and its argument to their operation type and performing the given bitwise operation of that type. * A parameterless bit-negation method (`~`). Its result type is - the receiver type $T$ or `Int`, whichever is larger. + the receiver type ´T´ or `Int`, whichever is larger. The operation is evaluated by converting the receiver to the result type and negating every bit in its value. * Bit-shift methods left-shift (`<<`), arithmetic right-shift (`>>`), and unsigned right-shift (`>>>`). Each of these - methods has two overloaded alternatives, which take a parameter $n$ + methods has two overloaded alternatives, which take a parameter ´n´ of type `Int`, respectively `Long`. The result type of the - operation is the receiver type $T$, or `Int`, whichever is larger. + operation is the receiver type ´T´, or `Int`, whichever is larger. The operation is evaluated by converting the receiver to the result - type and performing the specified shift by $n$ bits. + type and performing the specified shift by ´n´ bits. Numeric value types also implement operations `equals`, `hashCode`, and `toString` from class `Any`. @@ -353,25 +353,25 @@ right operand. ### The `Tuple` classes -Scala defines tuple classes `Tuple$n$` for $n = 2 , \ldots , 22$. +Scala defines tuple classes `Tuple´n´` for ´n = 2 , \ldots , 22´. These are defined as follows. ```scala package scala -case class Tuple$n$[+T_1, ..., +T_n](_1: T_1, ..., _$n$: T_$n$) { - def toString = "(" ++ _1 ++ "," ++ $\ldots$ ++ "," ++ _$n$ ++ ")" +case class Tuple´n´[+T_1, ..., +T_n](_1: T_1, ..., _´n´: T_´n´) { + def toString = "(" ++ _1 ++ "," ++ ´\ldots´ ++ "," ++ _´n´ ++ ")" } ``` ### The `Function` Classes -Scala defines function classes `Function$n$` for $n = 1 , \ldots , 22$. +Scala defines function classes `Function´n´` for ´n = 1 , \ldots , 22´. These are defined as follows. ```scala package scala -trait Function$n$[-T_1, ..., -T_$n$, +R] { - def apply(x_1: T_1, ..., x_$n$: T_$n$): R +trait Function´n´[-T_1, ..., -T_´n´, +R] { + def apply(x_1: T_1, ..., x_´n´: T_´n´): R def toString = "" } ``` @@ -397,17 +397,17 @@ informational purposes only: ```scala final class Array[T](_length: Int) extends java.io.Serializable with java.lang.Cloneable { - def length: Int = $\ldots$ - def apply(i: Int): T = $\ldots$ - def update(i: Int, x: T): Unit = $\ldots$ - override def clone(): Array[T] = $\ldots$ + def length: Int = ´\ldots´ + def apply(i: Int): T = ´\ldots´ + def update(i: Int, x: T): Unit = ´\ldots´ + override def clone(): Array[T] = ´\ldots´ } ``` -If $T$ is not a type parameter or abstract type, the type `Array[T]` +If ´T´ is not a type parameter or abstract type, the type `Array[T]` is represented as the array type `|T|[]` in the underlying host system, where `|T|` is the erasure of `T`. -If $T$ is a type parameter or abstract type, a different representation might be +If ´T´ is a type parameter or abstract type, a different representation might be used (it is `Object` on the Java platform). #### Operations @@ -443,10 +443,10 @@ explained in the following. #### Variance Unlike arrays in Java, arrays in Scala are _not_ -co-variant; That is, $S <: T$ does not imply -`Array[$S$] $<:$ Array[$T$]` in Scala. +co-variant; That is, ´S <: T´ does not imply +`Array[´S´] ´<:´ Array[´T´]` in Scala. However, it is possible to cast an array -of $S$ to an array of $T$ if such a cast is permitted in the host +of ´S´ to an array of ´T´ if such a cast is permitted in the host environment. For instance `Array[String]` does not conform to @@ -461,13 +461,13 @@ val xs = new Array[String](2) val ys: Array[Object] = xs.asInstanceOf[Array[Object]] // OK ``` -The instantiation of an array with a polymorphic element type $T$ requires -information about type $T$ at runtime. +The instantiation of an array with a polymorphic element type ´T´ requires +information about type ´T´ at runtime. This information is synthesized by adding a [context bound](07-implicits.html#context-bounds-and-view-bounds) -of `scala.reflect.ClassTag` to type $T$. +of `scala.reflect.ClassTag` to type ´T´. An example is the following implementation of method `mkArray`, which creates -an array of an arbitrary type $T$, given a sequence of $T$`s which +an array of an arbitrary type ´T´, given a sequence of ´T´`s which defines its elements: ```scala @@ -483,7 +483,7 @@ def mkArray[T : ClassTag](elems: Seq[T]): Array[T] = { } ``` -If type $T$ is a type for which the host platform offers a specialized array +If type ´T´ is a type for which the host platform offers a specialized array representation, this representation is used. ###### Example @@ -502,46 +502,46 @@ package scala object Array { /** copies array elements from `src` to `dest`. */ def copy(src: AnyRef, srcPos: Int, - dest: AnyRef, destPos: Int, length: Int): Unit = $\ldots$ + dest: AnyRef, destPos: Int, length: Int): Unit = ´\ldots´ /** Returns an array of length 0 */ def empty[T: ClassTag]: Array[T] = /** Create an array with given elements. */ - def apply[T: ClassTag](xs: T*): Array[T] = $\ldots$ + def apply[T: ClassTag](xs: T*): Array[T] = ´\ldots´ /** Creates array with given dimensions */ - def ofDim[T: ClassTag](n1: Int): Array[T] = $\ldots$ + def ofDim[T: ClassTag](n1: Int): Array[T] = ´\ldots´ /** Creates a 2-dimensional array */ - def ofDim[T: ClassTag](n1: Int, n2: Int): Array[Array[T]] = $\ldots$ - $\ldots$ + def ofDim[T: ClassTag](n1: Int, n2: Int): Array[Array[T]] = ´\ldots´ + ´\ldots´ /** Concatenate all argument arrays into a single array. */ - def concat[T: ClassTag](xss: Array[T]*): Array[T] = $\ldots$ + def concat[T: ClassTag](xss: Array[T]*): Array[T] = ´\ldots´ /** Returns an array that contains the results of some element computation a number * of times. */ - def fill[T: ClassTag](n: Int)(elem: => T): Array[T] = $\ldots$ + def fill[T: ClassTag](n: Int)(elem: => T): Array[T] = ´\ldots´ /** Returns a two-dimensional array that contains the results of some element * computation a number of times. */ - def fill[T: ClassTag](n1: Int, n2: Int)(elem: => T): Array[Array[T]] = $\ldots$ - $\ldots$ + def fill[T: ClassTag](n1: Int, n2: Int)(elem: => T): Array[Array[T]] = ´\ldots´ + ´\ldots´ /** Returns an array containing values of a given function over a range of integer * values starting from 0. */ - def tabulate[T: ClassTag](n: Int)(f: Int => T): Array[T] = $\ldots$ + def tabulate[T: ClassTag](n: Int)(f: Int => T): Array[T] = ´\ldots´ /** Returns a two-dimensional array containing values of a given function * over ranges of integer values starting from `0`. */ - def tabulate[T: ClassTag](n1: Int, n2: Int)(f: (Int, Int) => T): Array[Array[T]] = $\ldots$ - $\ldots$ + def tabulate[T: ClassTag](n1: Int, n2: Int)(f: (Int, Int) => T): Array[Array[T]] = ´\ldots´ + ´\ldots´ /** Returns an array containing a sequence of increasing integers in a range. */ - def range(start: Int, end: Int): Array[Int] = $\ldots$ + def range(start: Int, end: Int): Array[Int] = ´\ldots´ /** Returns an array containing equally spaced values in some integer interval. */ - def range(start: Int, end: Int, step: Int): Array[Int] = $\ldots$ + def range(start: Int, end: Int, step: Int): Array[Int] = ´\ldots´ /** Returns an array containing repeated applications of a function to a start value. */ - def iterate[T: ClassTag](start: T, len: Int)(f: T => T): Array[T] = $\ldots$ + def iterate[T: ClassTag](start: T, len: Int)(f: T => T): Array[T] = ´\ldots´ /** Enables pattern matching over arrays */ def unapplySeq[A](x: Array[A]): Option[IndexedSeq[A]] = Some(x) diff --git a/spec/13-syntax-summary.md b/spec/13-syntax-summary.md index 1d5fd3f1c2aa..837054f5a772 100644 --- a/spec/13-syntax-summary.md +++ b/spec/13-syntax-summary.md @@ -14,8 +14,8 @@ The lexical syntax of Scala is given by the following grammar in EBNF form: ```ebnf whiteSpace ::= ‘\u0020’ | ‘\u0009’ | ‘\u000D’ | ‘\u000A’ +upper ::= ‘A’ | … | ‘Z’ | ‘$’ // and any character in Unicode category Lu, Lt or Nl, and any character in Lo and Ml that don't have contributory property Other_Lowercase lower ::= ‘a’ | … | ‘z’ | ‘_’ // and any character in Unicode category Ll, and and any character in Lo or Ml that has contributory property Other_Lowercase -upper ::= ‘A’ | … | ‘Z’ | ‘\$’ // and any character in Unicode category Lu, Lt or Nl, and any character in Lo and Ml that don't have contributory property Other_Lowercase letter ::= upper | lower digit ::= ‘0’ | … | ‘9’ paren ::= ‘(’ | ‘)’ | ‘[’ | ‘]’ | ‘{’ | ‘}’ @@ -74,7 +74,7 @@ symbolLiteral ::= ‘'’ plainid comment ::= ‘/*’ “any sequence of characters; nested comments are allowed” ‘*/’ | ‘//’ “any sequence of characters up to end of line” -nl ::= $\mathit{“new line character”}$ +nl ::= ´\mathit{“new line character”}´ semi ::= ‘;’ | nl {nl} ``` diff --git a/spec/15-changelog.md b/spec/15-changelog.md index bff9ac2c6341..da5c3c60008f 100644 --- a/spec/15-changelog.md +++ b/spec/15-changelog.md @@ -73,7 +73,7 @@ A formal parameter to an anonymous function may now be a #### Unicode alternative for left arrow -The Unicode glyph ‘\\(\leftarrow\\)’ \\(`\u2190`\\) is now treated as a reserved +The Unicode glyph ‘´\leftarrow´’ ´`\u2190`´ is now treated as a reserved identifier, equivalent to the ASCII symbol ‘`<-`’. ## Changes in Version 2.7.1 @@ -201,7 +201,7 @@ one may for example write the following existential types It is now possible to define lazy value declarations using the new modifier [`lazy`](04-basic-declarations-and-definitions.html#value-declarations-and-definitions). A `lazy` value definition evaluates its right hand -side \\(e\\) the first time the value is accessed. Example: +side ´e´ the first time the value is accessed. Example: import compat.Platform._ val t0 = currentTime @@ -343,24 +343,24 @@ _(09-Mar-2007)_ The `private` and `protected` modifiers now accept a [`[this]` qualifier](05-classes-and-objects.html#modifiers). -A definition \\(M\\) which is labelled `private[this]` is private, +A definition ´M´ which is labelled `private[this]` is private, and in addition can be accessed only from within the current object. -That is, the only legal prefixes for \\(M\\) are `this` or `$C$.this`. -Analogously, a definition \\(M\\) which is labelled `protected[this]` is +That is, the only legal prefixes for ´M´ are `this` or `´C´.this`. +Analogously, a definition ´M´ which is labelled `protected[this]` is protected, and in addition can be accessed only from within the current object. #### Tuples, revised -The syntax for [tuples](06-expressions.html#tuples) has been changed from \\(\\{…\\}\\) to -\\((…)\\). For any sequence of types \\(T_1 , … , T_n\\), +The syntax for [tuples](06-expressions.html#tuples) has been changed from ´\\{…\\}´ to +´(…)´. For any sequence of types ´T_1 , … , T_n´, -\\((T_1 , … , T_n)\\) is a shorthand for `Tuple$n$[$T_1 , … , T_n$]`. +´(T_1 , … , T_n)´ is a shorthand for `Tuple´n´[´T_1 , … , T_n´]`. -Analogously, for any sequence of expressions or patterns \\(x_1 -, … , x_n\\), +Analogously, for any sequence of expressions or patterns ´x_1 +, … , x_n´, -\\((x_1 , … , x_n)\\) is a shorthand for `Tuple$n$($x_1 , … , x_n$)`. +´(x_1 , … , x_n)´ is a shorthand for `Tuple´n´(´x_1 , … , x_n´)`. #### Access modifiers for primary constructors @@ -461,13 +461,13 @@ Patterns” by Emir, Odersky and Williams. #### Tuples A new [lightweight syntax for tuples](06-expressions.html#tuples) has been introduced. -For any sequence of types \\(T_1 , … , T_n\\), +For any sequence of types ´T_1 , … , T_n´, -\\(\{T_1 , … , T_n \}\\) is a shorthand for `Tuple$n$[$T_1 , … , T_n$]`. +´\{T_1 , … , T_n \}´ is a shorthand for `Tuple´n´[´T_1 , … , T_n´]`. -Analogously, for any sequence of expressions or patterns \\(x_1, … , x_n\\), +Analogously, for any sequence of expressions or patterns ´x_1, … , x_n´, -\\(\{x_1 , … , x_n \}\\) is a shorthand for `Tuple$n$($x_1 , … , x_n$)`. +´\{x_1 , … , x_n \}´ is a shorthand for `Tuple´n´(´x_1 , … , x_n´)`. #### Infix operators of greater arities @@ -497,8 +497,8 @@ A simplified syntax for [methods returning `unit`] (04-basic-declarations-and-definitions.html#procedures) has been introduced. Scala now allows the following shorthands: -`def f(params)` \\(\mbox{for}\\) `def f(params): unit` -`def f(params) { ... }` \\(\mbox{for}\\) `def f(params): unit = { ... }` +`def f(params)` **for** `def f(params): unit` +`def f(params) { ... }` **for** `def f(params): unit = { ... }` #### Type Patterns @@ -544,15 +544,15 @@ referenced from the companion module of the class and vice versa. The lookup method for [implicit definitions](07-implicits.html#implicit-parameters) has been generalized. -When searching for an implicit definition matching a type \\(T\\), now are considered +When searching for an implicit definition matching a type ´T´, now are considered 1. all identifiers accessible without prefix, and -2. all members of companion modules of classes associated with \\(T\\). +2. all members of companion modules of classes associated with ´T´. (The second clause is more general than before). Here, a class is _associated_ -with a type \\(T\\) if it is referenced by some part of \\(T\\), or if it is a -base class of some part of \\(T\\). +with a type ´T´ if it is referenced by some part of ´T´, or if it is a +base class of some part of ´T´. For instance, to find implicit members corresponding to the type HashSet[List[Int], String] @@ -618,8 +618,8 @@ _(24-May-2006)_ #### Class Literals There is a new syntax for [class literals](06-expressions.html#literals): -For any class type \\(C\\), `classOf[$C$]` designates the run-time -representation of \\(C\\). +For any class type ´C´, `classOf[´C´]` designates the run-time +representation of ´C´. ## Changes in Version 2.0 diff --git a/spec/_includes/table-of-contents.yml b/spec/_includes/table-of-contents.yml index 1671eb20e39f..b70f97da5424 100644 --- a/spec/_includes/table-of-contents.yml +++ b/spec/_includes/table-of-contents.yml @@ -15,5 +15,9 @@ {% endif %} {% endfor %} - + +

+ This document was generated from + HTML version of Scala {{ site.latestScalaVersion }} spec +

diff --git a/spec/_layouts/default.yml b/spec/_layouts/default.yml index 94ccf7200bff..85dd08ac7e01 100644 --- a/spec/_layouts/default.yml +++ b/spec/_layouts/default.yml @@ -6,16 +6,11 @@ - - + + + + diff --git a/spec/public/scripts/main.js b/spec/public/scripts/main.js index 073f68cc850f..51625189f4bf 100644 --- a/spec/public/scripts/main.js +++ b/spec/public/scripts/main.js @@ -43,13 +43,22 @@ hljs.configure({ languages: [] }); -// syntax highlighting after mathjax is loaded so that mathjax can be used in code blocks -MathJax.Hub.Queue(function () { +// KaTeX configuration +document.addEventListener("DOMContentLoaded", function() { + renderMathInElement(document.body, { + delimiters: [ + {left: "´", right: "´", display: false}, // "display: false" -> inline + {left: "$$", right: "$$", display: true} + ], + ignoredTags: ['script', 'noscript', 'style', 'textarea'], + }); + // syntax highlighting after KaTeX is loaded, + // so that math can be used in code blocks hljs.initHighlighting(); $("pre nobr").addClass("fixws"); // point when all necessary js is done, so PDF to be rendered window.status = "loaded"; -}) +}); $("#chapters a").each(function (index) { if (document.location.pathname.endsWith($(this).attr("href"))) diff --git a/spec/public/stylesheets/print.css b/spec/public/stylesheets/print.css index bff99b7b8ca1..f0efff28b203 100644 --- a/spec/public/stylesheets/print.css +++ b/spec/public/stylesheets/print.css @@ -2,23 +2,27 @@ body { padding: 0px; - margin: 0.5em; + margin: 0px; } .anchor, #navigation, .to_top, .version-notice, .hidden-print { display: none !important; } +.print-only { + display: block; +} + #content-container { width: 100%; float: none; } /* no scrollbars, jump to next row.. */ -/*.highlight pre code { +.highlight pre code { overflow: hidden; white-space: pre-wrap; -}*/ +} main { position: relative; @@ -30,3 +34,9 @@ main { min-height: none; background-color: #FFF; } + +/* Avoid clipped headings https://github.com/pdfkit/pdfkit/issues/113#issuecomment-7027798 */ +h2, h3, h4, h5, h6 { + padding: 0px; + margin: 0px; +} diff --git a/spec/public/stylesheets/screen.css b/spec/public/stylesheets/screen.css index 36f4a5a18126..2073613eaea7 100644 --- a/spec/public/stylesheets/screen.css +++ b/spec/public/stylesheets/screen.css @@ -425,7 +425,7 @@ header { color: #FFFFFF; text-decoration: none; font-size: 0.63vw; - padding: 100% 8px; + padding: 100% 5px; } #chapters a:hover, #chapters a:focus, #github:hover, #github:focus { @@ -515,3 +515,7 @@ header { font-weight: bold; text-decoration: underline; } + +.print-only { + display: none; +}