diff options
| -rw-r--r-- | 04-identifiers-names-and-scopes.md | 12 | ||||
| -rw-r--r-- | 05-types.md | 6 | ||||
| -rw-r--r-- | 06-basic-declarations-and-definitions.md | 16 | ||||
| -rw-r--r-- | 07-classes-and-objects.md | 269 | ||||
| -rw-r--r-- | 08-expressions.md | 100 | ||||
| -rw-r--r-- | 09-implicit-parameters-and-views.md | 10 | ||||
| -rw-r--r-- | 10-pattern-matching.md | 33 | ||||
| -rw-r--r-- | 13-user-defined-annotations.md | 40 | ||||
| -rw-r--r-- | 14-the-scala-standard-library.md | 3 |
9 files changed, 234 insertions, 255 deletions
diff --git a/04-identifiers-names-and-scopes.md b/04-identifiers-names-and-scopes.md index 3086525634..62d150d281 100644 --- a/04-identifiers-names-and-scopes.md +++ b/04-identifiers-names-and-scopes.md @@ -64,6 +64,12 @@ 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](05-types.html#value-types). +The type of $e.x$ is the member type of the referenced entity in $T$. + + ###### Example: bindings Assume the following two definitions of a objects named `X` in packages `P` and `Q`. @@ -105,9 +111,3 @@ object A { }}}}}} ``` -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](05-types.html#value-types). The type of $e.x$ is the member type of the -referenced entity in $T$. - diff --git a/05-types.md b/05-types.md index e544d01eb4..1049813f2e 100644 --- a/05-types.md +++ b/05-types.md @@ -302,7 +302,7 @@ 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 +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 @@ -348,7 +348,7 @@ a value `callsign` and a `fly` method. InfixType ::= CompoundType {id [nl] CompoundType} ``` -An infix type `$T_1$ \mathit{op} $T_2$` consists of an infix +An infix type `$T_1 \mathit{op} T_2$` consists of an infix operator $\mathit{op}$ which gets applied to two type operands $T_1$ and $T_2$. The type is equivalent to the type application `$\mathit{op}$[$T_1$, $T_2$]`. The infix operator $\mathit{op}$ may be an @@ -935,7 +935,7 @@ type $C'$, if one of the following holds. The $(<:)$ relation forms pre-order between types, -i.e.\ it is transitive and reflexive. _least upper bounds_ and +i.e. it is transitive and reflexive. _least upper bounds_ and _greatest lower bounds_ of a set of types are understood to be relative to that order. diff --git a/06-basic-declarations-and-definitions.md b/06-basic-declarations-and-definitions.md index de718bb6b0..0d00857366 100644 --- a/06-basic-declarations-and-definitions.md +++ b/06-basic-declarations-and-definitions.md @@ -64,7 +64,7 @@ All definitions have a ``repeated form`` where the initial definition keyword is followed by several constituent definitions which are separated by commas. A repeated definition is always interpreted as a sequence formed from the -constituent definitions. E.g.\ the function definition +constituent definitions. E.g. the function definition `def f(x) = x, g(y) = y` expands to `def f(x) = x; def g(y) = y` and the type definition @@ -419,7 +419,7 @@ The most general form of a first-order type parameter is `$@a_1 \ldots @a_n$ $\pm$ $t$ >: $L$ <: $U$`. Here, $L$, and $U$ are lower and upper bounds that constrain possible type arguments for the parameter. It is a -compile-time error if $L$ does not conform to $U$. $\pm$ is a _variance_, i.e.\ an optional prefix of either `+`, or +compile-time error if $L$ does not conform to $U$. $\pm$ is a _variance_, i.e. an optional prefix of either `+`, or `-`. One or more annotations may precede the type parameter. <!-- @@ -433,7 +433,7 @@ TODO: Why TODO: this is a pretty awkward description of scoping and distinctness of binders --> -The names of all type parameters must be pairwise different in their enclosing type parameter clause. The scope of a type parameter includes in each case the whole type parameter clause. Therefore it is possible that a type parameter appears as part of its own bounds or the bounds of other type parameters in the same clause. However, a type parameter may not be bounded directly or indirectly by itself.\ +The names of all type parameters must be pairwise different in their enclosing type parameter clause. The scope of a type parameter includes in each case the whole type parameter clause. Therefore it is possible that a type parameter appears as part of its own bounds or the bounds of other type parameters in the same clause. However, a type parameter may not be bounded directly or indirectly by itself. A type constructor parameter adds a nested type parameter clause to the type parameter. The most general form of a type constructor parameter is `$@a_1\ldots@a_n$ $\pm$ $t[\mathit{tps}\,]$ >: $L$ <: $U$`. @@ -610,7 +610,7 @@ 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 +i.e. an expression which defines the function's result. A parameter 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 @@ -676,7 +676,7 @@ def compare$\$$default$\$$2[T](a: T): T = a ParamType ::= ‘=>’ Type ``` -The type of a value parameter may be prefixed by `=>`, e.g.\ +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 corresponding argument is not evaluated at the point of function @@ -879,7 +879,7 @@ The most general form of an import expression is a list of _import selectors_ 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 +$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 @@ -909,11 +909,11 @@ $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 +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$ +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 diff --git a/07-classes-and-objects.md b/07-classes-and-objects.md index 1b3072a801..84c1ca82b1 100644 --- a/07-classes-and-objects.md +++ b/07-classes-and-objects.md @@ -73,7 +73,7 @@ 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 +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. @@ -110,12 +110,10 @@ object O extends Base with Mixin {} <!-- TODO: Make all references to Java generic --> -**Inheriting from Java Types** \ -A template may have a Java class as its superclass and Java interfaces as its +**Inheriting from Java Types** A template may have a Java class as its superclass and Java interfaces as its mixins. -**Template Evaluation** \ -Consider a template `$sc$ with $mt_1$ with $mt_n$ { $\mathit{stats}$ }`. +**Template Evaluation** 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}$. @@ -132,7 +130,7 @@ consists of the following steps. - Finally the statement sequence $\mathit{stats}\,$ is evaluated. -_Delayed Initializaton_ \ +###### Delayed Initializaton The initialization code of an object or class (but not a trait) that follows the superclass constructor invocation and the mixin-evaluation of the template's base @@ -166,7 +164,7 @@ 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 +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](08-expressions.html#local-type-inference). If no explicit @@ -281,7 +279,7 @@ $M`$ where every occurrence of a type parameter $t`$ of $M`$ has been replaced b --> Member definitions fall into two categories: concrete and abstract. -Members of class $C$ are either _directly defined_ (i.e.\ they appear in +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: @@ -507,122 +505,129 @@ modifier may not occur more than once. Modifiers preceding a repeated definition apply to all constituent definitions. The rules governing the validity and meaning of a modifier are as follows. -- The `private` modifier can be used with any definition or - 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). They - are not inherited by subclasses and they may not override definitions - in parent classes. - - The 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 - [companion module](#object-definitions). - - An 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 - 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 - case the member is called _qualified private_. - - Class-private or object-private members may not be abstract, and may - not have `protected` or `override` modifiers. - -- The `protected` modifier applies to class member definitions. - Protected members of a class can be accessed from within - - the template of the defining class, - - 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. 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 - [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: - - 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 - `super`, or - - $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 - unqualified `protected` apply. - -- The `override` modifier applies to class member definitions or - declarations. It - is mandatory for member definitions or declarations that override some - other concrete - member definition in a parent class. If an `override` - modifier is given, there must be at least one overridden member - definition or declaration (either concrete or abstract). - -- 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 - abstract (i.e.\ defined by a declaration), or it is labeled - `abstract` and `override` and - 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 - member is _abstract_ if only a declaration is given for it; it is - _concrete_ if a full definition is given. - -- The `abstract` modifier is used in class definitions. It is - redundant for traits, and mandatory for all other classes which have - incomplete members. Abstract classes cannot be - [instantiated](08-expressions.html#instance-creation-expressions) with a constructor invocation - unless followed by mixins and/or a refinement which override all - incomplete members of the class. Only abstract classes and traits can have - abstract term members. - - The `abstract` modifier can also be used in conjunction with - `override` for class member definitions. In that case the - previous discussion applies. - -- The `final` modifier applies to class member definitions and to - class definitions. A `final` class member definition may not be - overridden in subclasses. A `final` class may not be inherited by - a template. `final` is redundant for object definitions. Members - of final classes or objects are implicitly also final, so the - `final` modifier is generally redundant for them, too. Note, however, that - [constant value definitions](06-basic-declarations-and-definitions.html#value-declarations-and-definitions) do require - an explicit `final` modifier, even if they are defined in a final class or - object. `final` may not be applied to incomplete members, and it may not be - combined in one modifier list with `sealed`. - -- The `sealed` modifier applies to class definitions. A - `sealed` class may not be directly inherited, except if the inheriting - template is defined in the same source file as the inherited class. - However, subclasses of a sealed class can be inherited anywhere. - -- The `lazy` modifier applies to value definitions. A `lazy` - value is initialized the first time it is accessed (which might never - happen at all). Attempting to access a lazy value during its - initialization might lead to looping behavior. If an exception is - thrown during initialization, the value is considered uninitialized, - and a later access will retry to evaluate its right hand side. +### `private` +The `private` modifier can be used with any definition or +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). They +are not inherited by subclasses and they may not override definitions +in parent classes. + +The 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 +[companion module](#object-definitions). + +An 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 +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 +case the member is called _qualified private_. + +Class-private or object-private members may not be abstract, and may +not have `protected` or `override` modifiers. + +#### `protected` +The `protected` modifier applies to class member definitions. +Protected members of a class can be accessed from within + - the template of the defining class, + - 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. 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 +[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: + - 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 + `super`, or + - $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 +unqualified `protected` apply. + +#### `override` +The `override` modifier applies to class member definitions or declarations. +It is mandatory for member definitions or declarations that override some +other concrete member definition in a parent class. If an `override` +modifier is given, there must be at least one overridden member +definition or declaration (either concrete or abstract). + +#### `abstract override` +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 +abstract (i.e. defined by a declaration), or it is labeled +`abstract` and `override` and +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 +member is _abstract_ if only a declaration is given for it; +it is _concrete_ if a full definition is given. + +#### `abstract` +The `abstract` modifier is used in class definitions. It is +redundant for traits, and mandatory for all other classes which have +incomplete members. Abstract classes cannot be +[instantiated](08-expressions.html#instance-creation-expressions) with a constructor invocation +unless followed by mixins and/or a refinement which override all +incomplete members of the class. Only abstract classes and traits can have +abstract term members. + +The `abstract` modifier can also be used in conjunction with +`override` for class member definitions. In that case the +previous discussion applies. + +#### `final` +The `final` modifier applies to class member definitions and to +class definitions. A `final` class member definition may not be +overridden in subclasses. A `final` class may not be inherited by +a template. `final` is redundant for object definitions. Members +of final classes or objects are implicitly also final, so the +`final` modifier is generally redundant for them, too. Note, however, that +[constant value definitions](06-basic-declarations-and-definitions.html#value-declarations-and-definitions) do require +an explicit `final` modifier, even if they are defined in a final class or +object. `final` may not be applied to incomplete members, and it may not be +combined in one modifier list with `sealed`. + +#### `sealed` +The `sealed` modifier applies to class definitions. A +`sealed` class may not be directly inherited, except if the inheriting +template is defined in the same source file as the inherited class. +However, subclasses of a sealed class can be inherited anywhere. + +#### `lazy` +The `lazy` modifier applies to value definitions. A `lazy` +value is initialized the first time it is accessed (which might never +happen at all). Attempting to access a lazy value during its +initialization might lead to looping behavior. If an exception is +thrown during initialization, the value is considered uninitialized, +and a later access will retry to evaluate its right hand side. ###### Example @@ -673,7 +678,7 @@ new m.C(0) {} // **** error: illegal inheritance from sealed class. ``` A similar access restriction can be achieved by marking the primary -constructor `private` ((example)[#example-private-constructor]). +constructor `private` ([example](#example-private-constructor)). ## Class Definitions @@ -799,7 +804,7 @@ 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 which begins with a self constructor invocation. The self constructor -invocation must construct a generic instance of the class. I.e.\ if the +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 @@ -825,7 +830,7 @@ expressions themselves. However, unlike other methods, constructors are never inherited. To prevent infinite cycles of constructor invocations, there is the restriction that every self constructor invocation must refer to a constructor definition which precedes it -(i.e.\ it must refer to either a preceding auxiliary constructor or the +(i.e. it must refer to either a preceding auxiliary constructor or the primary constructor of the class). @@ -994,14 +999,12 @@ 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 +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](08-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. +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 least proper supertype (which is statically known). diff --git a/08-expressions.md b/08-expressions.md index 03475bbf4a..1257eb3bfc 100644 --- a/08-expressions.md +++ b/08-expressions.md @@ -260,7 +260,7 @@ type of argument $e_i$ $(i = 1 , \ldots , m)$. If $f$ is a polymorphic method, [local type inference](#local-type-inference) is used to determine type arguments for $f$. 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$. +i.e. the application of an `apply` method defined by $f$. The function $f$ must be _applicable_ to its arguments $e_1 , \ldots , e_n$ of types $S_1 , \ldots , S_n$. @@ -309,10 +309,10 @@ 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](06-basic-declarations-and-definitions.html#repeated-parameters) of type `$S$*` and it must be the only argument matching this -parameter (i.e.\ the number of formal parameters and actual arguments +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 @@ -414,9 +414,9 @@ The final result of the transformation is a block of the form 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$) + 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$) + 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}$) } ``` @@ -428,12 +428,12 @@ The final result of the transformation is a block of the form SimpleExpr ::= SimpleExpr1 `_' ``` -The expression ~`$e$ _`~ is well-formed if $e$ is of method +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 +parameters, `$e$ _` represents $e$ converted to a function type by [eta expansion](#eta-expansion). If $e$ is a parameterless method or call-by-name parameter of type -`=>$T$`, `$e$ _`~ represents the function of type +`=>$T$`, `$e$ _` represents the function of type `() => $T$`, which evaluates $e$ when it is applied to the empty parameterlist `()`. @@ -473,7 +473,7 @@ U_i$, where $\sigma$ is the substitution $[a_1 := T_1 , \ldots , a_n 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$.apply[$T_1 , \ldots ,$ T$_n$]`, i.e. the application of an `apply` method defined by $e$. Type applications can be omitted if @@ -593,7 +593,7 @@ 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 +- 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 @@ -671,7 +671,7 @@ character. Characters are listed below in increasing order of precedence, with characters on the same line having the same precedence. ``` -$\mbox{\rm\sl(all letters)}$ +(all letters) | ^ & @@ -680,7 +680,7 @@ $\mbox{\rm\sl(all letters)}$ : + - * / % -$\mbox{\rm\sl(all other special characters)}$ +(all other special characters) ``` That is, operators starting with a letter have lowest precedence, @@ -713,7 +713,7 @@ parts of an expression as follows. sequence is interpreted as $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 + 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 @@ -814,7 +814,7 @@ is interpreted as the invocation `$f.x$_=($e\,$)`. An assignment `$f$($\mathit{args}\,$) = $e$` with a function application to the left of the ‘`=`’ operator is interpreted as -`$f.$update($\mathit{args}$, $e\,$)`, i.e.\ +`$f.$update($\mathit{args}$, $e\,$)`, i.e. the invocation of an `update` function defined by $f$. ###### Example @@ -1373,13 +1373,13 @@ The following five 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}$. -_Overloading Resolution_ \ +#### Overloading Resolution If an expression denotes several possible members of a class, [overloading resolution](#overloading-resolution) is applied to pick a unique member. -_Type Instantiation_ \ +###### Type Instantiation An expression $e$ of polymorphic type ``` @@ -1394,29 +1394,29 @@ 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_ \ +###### Numeric Widening If $e$ has a primitive number type which [weakly conforms](05-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`, `toFloat`, `toDouble` defined [here](14-the-scala-standard-library.html#numeric-value-types). -_Numeric Literal Narrowing_ \ +###### 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 type, it is converted to the same literal in that type. -_Value Discarding_ \ +###### 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$; () }`. -_View Application_ \ +###### 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](09-implicit-parameters-and-views.html#views).\bigskip +$e$ to the expected type with a [view](09-implicit-parameters-and-views.html#views). -_Dynamic Member Selection_ \ +###### Dynamic Member Selection 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 @@ -1427,23 +1427,23 @@ then the selection is rewritten according to the rules for The following four implicit conversions can be applied to methods which are not applied to some argument list. -_Evaluation_ \ +###### Evaluation 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 - arguments are passed following the rules [here](09-implicit-parameters-and-views.html#implicit-parameters). +###### Implicit Application +If the method takes only implicit parameters, implicit +arguments are passed following the rules [here](09-implicit-parameters-and-views.html#implicit-parameters). -_Eta Expansion_ \ - Otherwise, if the method is not a constructor, - and the expected type $\mathit{pt}$ is a function type - $(\mathit{Ts}') \Rightarrow T'$, [eta-expansion](#eta-expansion) - is performed on the expression $e$. +###### Eta Expansion +Otherwise, if the method is not a constructor, +and the expected type $\mathit{pt}$ is a function type +$(\mathit{Ts}') \Rightarrow T'$, [eta-expansion](#eta-expansion) +is performed on the expression $e$. -_Empty Application_ \ - Otherwise, if $e$ has method type $()T$, it is implicitly applied to the empty - argument list, yielding $e()$. +###### Empty Application +Otherwise, if $e$ has method type $()T$, it is implicitly applied to the empty +argument list, yielding $e()$. ### Overloading Resolution @@ -1592,7 +1592,7 @@ 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_ \ +###### 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 @@ -1600,7 +1600,7 @@ 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. -_Case 2: Values_ \ +###### Case 2: Values 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 @@ -1611,9 +1611,9 @@ means finding a substitution $\sigma$ of types $T_i$ for the type parameters $a_i$ such that - None of inferred types $T_i$ is a [singleton type](05-types.html#singleton-types) -- All type parameter bounds are respected, i.e.\ +- 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 expression's type conforms to the expected type, i.e.\ +- The expression's type conforms to the expected type, i.e. $\sigma T <: \sigma \mathit{pt}$. It is a compile time error if no such substitution exists. @@ -1622,11 +1622,11 @@ 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](06-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, +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$. -_Case 3: Methods_ \ +###### 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 @@ -1638,7 +1638,7 @@ 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 {\sl undefined}. +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 @@ -1648,14 +1648,12 @@ finding a substitution $\sigma$ of types $T_i$ for the type parameters $a_i$ such that - None of inferred types $T_i$ is a [singleton type](05-types.html#singleton-types) -- 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}$. +- 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](05-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. @@ -1716,7 +1714,7 @@ the type parameter `a` of `cons`: ``` Int <: a? List[scala.Nothing] <: List[a?] -List[a?] <: $\mbox{\sl undefined}$ +List[a?] <: $\mathit{undefined}$ ``` The optimal solution of this constraint system is @@ -1744,7 +1742,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[$\mbox{\sl 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 @@ -1753,7 +1751,7 @@ the type parameter `a` of `cons`: ``` String <: a? List[Int] <: List[a?] -List[a?] <: $\mbox{\sl undefined}$ +List[a?] <: $\mathit{undefined}$ ``` The optimal solution of this constraint system is @@ -1806,7 +1804,7 @@ Further assuming the selection is not followed by any function arguments, such a $e$.applyDynamic("$x$") ``` -If the selection is followed by some arguments, e.g.\ $e.x(\mathit{args})$, then that expression +If the selection is followed by some arguments, e.g. $e.x(\mathit{args})$, then that expression is rewritten to ``` diff --git a/09-implicit-parameters-and-views.md b/09-implicit-parameters-and-views.md index 6e662bf5f1..b55109636a 100644 --- a/09-implicit-parameters-and-views.md +++ b/09-implicit-parameters-and-views.md @@ -409,13 +409,11 @@ Then the following rules apply. 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$)` +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]$. + 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$)` diff --git a/10-pattern-matching.md b/10-pattern-matching.md index 9496ab6300..1271b85e83 100644 --- a/10-pattern-matching.md +++ b/10-pattern-matching.md @@ -37,7 +37,7 @@ than once in a pattern. ###### Example Some examples of patterns are: 1. The pattern `ex: IOException` matches all instances of class - `IOException`, binding variable \verb@ex@ to the instance. + `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 `(x, _)` matches pairs of values, binding `x` to @@ -245,7 +245,7 @@ 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](06-basic-declarations-and-definitions.html#repeated-parameters) of type $S*$. +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](06-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$. @@ -400,11 +400,7 @@ The set $\mathcal{C}_0$ is then augmented by further subtype constraints. There 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 @@ -428,9 +424,7 @@ 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$ @@ -444,7 +438,7 @@ complexity of inferred bounds. Minimality and maximality of types have to be understood relative to the set of types of acceptable complexity. -Type parameter inference for constructor patterns. \ +#### Type parameter inference for constructor patterns. Assume a constructor pattern $C(p_1 , \ldots , p_n)$ where class $C$ has type type parameters $a_1 , \ldots , a_n$. These type parameters are inferred in the same way as for the typed pattern @@ -549,8 +543,8 @@ variables in $p_i$ comprises the pattern's guard and the corresponding block $b_ 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 +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 @@ -576,15 +570,14 @@ $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 -$\mathbf{case} p_i \Rightarrow b_i$. The result of the whole expression is -then 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 +The pattern in a case may also be followed by a guard suffix +`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 @@ -600,7 +593,7 @@ expression is evaluated only if the pattern it guards matches. If the selector of a pattern match is an instance of a [`sealed` class](07-classes-and-objects.html#modifiers), the compilation of pattern matching can emit warnings which diagnose -that a given set of patterns is not exhaustive, i.e.\ that there is a +that a given set of patterns is not exhaustive, i.e. that there is a possibility of a `MatchError` being raised at run-time. ###### Example: `eval` diff --git a/13-user-defined-annotations.md b/13-user-defined-annotations.md index 46d3f26bfc..3011d91134 100644 --- a/13-user-defined-annotations.md +++ b/13-user-defined-annotations.md @@ -35,19 +35,16 @@ String @local // Type annotation The meaning of annotation clauses is implementation-dependent. On the Java platform, the following annotations have a standard meaning. - * `@transient` \ - Marks a field to be non-persistent; this is + * `@transient` Marks a field to be non-persistent; this is equivalent to the `transient` modifier in Java. - * `@volatile` \ - Marks a field which can change its value + * `@volatile` Marks a field which can change its value outside the control of the program; this is equivalent to the `volatile` modifier in Java. - * `@SerialVersionUID(<longlit>)` \ - Attaches a serial version identifier (a + * `@SerialVersionUID(<longlit>)` Attaches a serial version identifier (a `long` constant) to a class. This is equivalent to a the following field definition in Java: @@ -56,8 +53,7 @@ Java platform, the following annotations have a standard meaning. private final static SerialVersionUID = <longlit> ``` - * `@throws(<classlit>)` \ - A Java compiler checks that a program contains handlers for checked exceptions + * `@throws(<classlit>)` A Java compiler checks that a program contains handlers for checked exceptions by analyzing which checked exceptions can result from execution of a method or constructor. For each checked exception which is a possible result, the `throws` @@ -66,8 +62,7 @@ Java platform, the following annotations have a standard meaning. ## Java Beans Annotations - * `@scala.beans.BeanProperty` \ - When prefixed to a definition of some variable `X`, this + * `@scala.beans.BeanProperty` When prefixed to a definition of some variable `X`, this annotation causes getter and setter methods `getX`, `setX` in the Java bean style to be added in the class containing the variable. The first letter of the variable appears capitalized after @@ -77,27 +72,23 @@ Java platform, the following annotations have a standard meaning. code-generation; therefore, these methods become visible only once a classfile for the containing class is generated. - * `@scala.beans.BooleanBeanProperty` \ - This annotation is equivalent to `scala.reflect.BeanProperty`, but + * `@scala.beans.BooleanBeanProperty` This annotation is equivalent to `scala.reflect.BeanProperty`, but the generated getter method is named `isX` instead of `getX`. ## Deprecation Annotations - * `@deprecated(<stringlit>)` \ - Marks a definition as deprecated. Accesses to the + * `@deprecated(<stringlit>)` Marks a definition as deprecated. Accesses to the defined entity will then cause a deprecated warning mentioning the message `<stringlit>` to be issued from the compiler. Deprecated warnings are suppressed in code that belongs itself to a definition that is labeled deprecated. - * `@deprecatedName(name: <symbollit>)` \ - Marks a formal parameter name as deprecated. Invocations of this entity + * `@deprecatedName(name: <symbollit>)` Marks a formal parameter name as deprecated. Invocations of this entity using named parameter syntax refering to the deprecated parameter name cause a deprecation warning. ## Scala Compiler Annotations - * `@unchecked` \ - When applied to the selector of a `match` expression, + * `@unchecked` When applied to the selector of a `match` expression, this attribute suppresses any warnings about non-exhaustive pattern matches which would otherwise be emitted. For instance, no warnings would be produced for the method definition below. @@ -112,8 +103,7 @@ Java platform, the following annotations have a standard meaning. infer that the pattern match is non-exhaustive, and could produce a warning because `Option` is a `sealed` class. - * `@uncheckedStable` \ - When applied a value declaration or definition, it allows the defined + * `@uncheckedStable` When applied a value declaration or definition, it allows the defined value to appear in a path, even if its type is [volatile](05-types.html#volatile-types). For instance, the following member definitions are legal: @@ -132,8 +122,7 @@ Java platform, the following annotations have a standard meaning. types, the annotation has no effect. - * `@specialized` \ - When applied to the definition of a type parameter, this annotation causes + * `@specialized` When applied to the definition of a type parameter, this annotation causes the compiler to generate specialized definitions for primitive types. An optional list of primitive @@ -149,9 +138,8 @@ Java platform, the following annotations have a standard meaning. ``` Whenever the static type of an expression matches a specialized variant of - a definition, - the compiler will instead use the specialized version. See \cite{spec-sid} - for more details of the implementation. + a definition, the compiler will instead use the specialized version. + See \cite{spec-sid} for more details of the implementation. Other annotations may be interpreted by platform- or @@ -171,7 +159,7 @@ during the compilation run that analyzes them. Classes inheriting from `scala.ClassfileAnnotation` may be subject to further restrictions in order to assure that they can be mapped to the host environment. In particular, on both the Java and -the .NET platforms, such classes must be toplevel; i.e.\ they may not +the .NET platforms, such classes must be toplevel; i.e. they may not be contained in another class or object. Additionally, on both Java and .NET, all constructor arguments must be constant expressions. diff --git a/14-the-scala-standard-library.md b/14-the-scala-standard-library.md index 066fdb1570..662207be05 100644 --- a/14-the-scala-standard-library.md +++ b/14-the-scala-standard-library.md @@ -318,8 +318,7 @@ The `equals` method returns `true` if the argument is the same boolean value as the receiver, `false` otherwise. The `hashCode` method returns a fixed, implementation-specific hash-code when invoked on `true`, and a different, fixed, implementation-specific hash-code when invoked on `false`. The `toString` method -returns the receiver converted to a string, i.e.\ either `"true"` -or `"false"`. +returns the receiver converted to a string, i.e. either `"true"` or `"false"`. ### Class `Unit` |