From bca19f35103c4ff1205e1c8054eb3f803217a18b Mon Sep 17 00:00:00 2001 From: Antoine Gourlay Date: Mon, 15 Sep 2014 12:02:12 +0200 Subject: spec: fix latex formatting all over the place Two things worth mentioning: - `\em` and `emph` are not supported by MathJax, - and things like `\mathcal{C}_0` require escaping the `_`, otherwise markdown sees it as the beginning of `_some string_`. It doesn't happen without the closing bracket in front, e.g. in `b_0`. --- spec/01-lexical-syntax.md | 4 +- spec/03-types.md | 28 ++++++------ spec/04-basic-declarations-and-definitions.md | 20 ++++----- spec/05-classes-and-objects.md | 21 ++++----- spec/06-expressions.md | 32 +++++++------- spec/07-implicit-parameters-and-views.md | 12 +++--- spec/08-pattern-matching.md | 62 ++++++++++++++------------- spec/10-xml-expressions-and-patterns.md | 24 +++++------ spec/12-the-scala-standard-library.md | 2 +- 9 files changed, 104 insertions(+), 101 deletions(-) (limited to 'spec') diff --git a/spec/01-lexical-syntax.md b/spec/01-lexical-syntax.md index 6c8712cda2..ef1f2bf053 100644 --- a/spec/01-lexical-syntax.md +++ b/spec/01-lexical-syntax.md @@ -429,7 +429,7 @@ by an [escape sequence](#escape-sequences). Note that `'\u000A'` is _not_ a valid character literal because Unicode conversion is done before literal parsing and the Unicode -character \\u000A (line feed) is not a printable +character `\u000A` (line feed) is not a printable character. One can use instead the escape sequence `'\n'` or the octal escape `'\12'` ([see here](#escape-sequences)). @@ -528,7 +528,7 @@ The following escape sequences are recognized in character and string literals. A character with Unicode between 0 and 255 may also be represented by -an octal escape, i.e. a backslash ‘\’ followed by a +an octal escape, i.e. a backslash `'\'` followed by a sequence of up to three octal characters. It is a compile time error if a backslash character in a character or diff --git a/spec/03-types.md b/spec/03-types.md index 4a02c7a8c1..29e6426530 100644 --- a/spec/03-types.md +++ b/spec/03-types.md @@ -231,7 +231,7 @@ 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$. +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 @@ -241,12 +241,12 @@ standard Scala library (they might also add other methods and implement other traits). ```scala -case class Tuple$n$[+T1, … , +$T_n$](_1: T1, … , _n: $T_n$) -extends Product_n[T1, … , $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[+T1, … , +$T_n$] { +trait Product_n[+$T_1$, … , +$T_n$] { override def productArity = $n$ - def _1: T1 + def _1: $T_1$ … def _n: $T_n$ } @@ -362,7 +362,7 @@ 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 +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$, @@ -420,10 +420,10 @@ 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 +$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 +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$ }`. @@ -438,7 +438,7 @@ 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 +$[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 @@ -579,8 +579,8 @@ 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 @@ -634,7 +634,7 @@ produce the typings ```scala empty : [A >: Nothing <: Any] List[A] -union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A] . +union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A] ``` ### Type Constructors @@ -893,7 +893,7 @@ transitive relation that satisfies the following conditions. - 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 + $[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 diff --git a/spec/04-basic-declarations-and-definitions.md b/spec/04-basic-declarations-and-definitions.md index ab1f98ea07..358a4765ff 100644 --- a/spec/04-basic-declarations-and-definitions.md +++ b/spec/04-basic-declarations-and-definitions.md @@ -111,7 +111,7 @@ ids ::= id {‘,’ id} ``` A value declaration `val $x$: $T$` introduces $x$ as a name of a value of -type $T$. +type $T$. A value definition `val $x$: $T$ = $e$` defines $x$ as a name of the value that results from the evaluation of $e$. @@ -152,7 +152,7 @@ $\ldots$ val $x_n$ = $\$ x$._n . ``` -Here, $\$ x$ is a fresh name. +Here, $\$ x$ is a fresh name. 2. If $p$ has a unique bound variable $x$: @@ -339,13 +339,13 @@ A _type alias_ `type $t$ = $T$` defines $t$ to be an alias name for the type $T$. The left hand side of a type alias may have a type parameter clause, e.g. `type $t$[$\mathit{tps}\,$] = $T$`. The scope of a type parameter extends over the right hand side $T$ and the -type parameter clause $\mathit{tps}$ itself. +type parameter clause $\mathit{tps}$ itself. The scope rules for [definitions](#basic-declarations-and-definitions) and [type parameters](#function-declarations-and-definitions) make it possible that a type name appears in its own bound or in its right-hand side. However, it is a static error if -a type alias refers recursively to the defined type constructor itself. +a type alias refers recursively to the defined type constructor itself. That is, the type $T$ in a type alias `type $t$[$\mathit{tps}\,$] = $T$` may not refer directly or indirectly to the name $t$. It is also an error if an abstract type is directly or indirectly its own upper or lower bound. @@ -436,9 +436,9 @@ TODO: this is a pretty awkward description of scoping and distinctness of binder 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$`. +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$`. -The above scoping restrictions are generalized to the case of nested type parameter clauses, which declare higher-order type parameters. Higher-order type parameters (the type parameters of a type parameter $t$) are only visible in their immediately surrounding parameter clause (possibly including clauses at a deeper nesting level) and in the bounds of $t$. Therefore, their names must only be pairwise different from the names of other visible parameters. Since the names of higher-order type parameters are thus often irrelevant, they may be denoted with a ‘_’, which is nowhere visible. +The above scoping restrictions are generalized to the case of nested type parameter clauses, which declare higher-order type parameters. Higher-order type parameters (the type parameters of a type parameter $t$) are only visible in their immediately surrounding parameter clause (possibly including clauses at a deeper nesting level) and in the bounds of $t$. Therefore, their names must only be pairwise different from the names of other visible parameters. Since the names of higher-order type parameters are thus often irrelevant, they may be denoted with a `‘_’`, which is nowhere visible. ###### Example Here are some well-formed type parameter clauses: @@ -498,7 +498,7 @@ changes at the following constructs. - The variance position of a type parameter is the opposite of the variance position of the enclosing type parameter clause. - The variance position of the lower bound of a type declaration or type parameter - is the opposite of the variance position of the type declaration or parameter. + is the opposite of the variance position of the type declaration or parameter. - The type of a mutable variable is always in invariant position. - The right-hand side of a type alias is always in invariant position. - The prefix $S$ of a type selection `$S$#$T$` is always in invariant position. @@ -628,7 +628,7 @@ 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. +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 @@ -708,7 +708,7 @@ 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$. @@ -878,7 +878,7 @@ The most general form of an import expression is a list of _import selectors_ { $x_1$ => $y_1 , \ldots , x_n$ => $y_n$, _ } ``` -for $n \geq 0$, where the final wildcard ‘_’ may be absent. It +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 diff --git a/spec/05-classes-and-objects.md b/spec/05-classes-and-objects.md index 70fa3e0272..429f0b75bc 100644 --- a/spec/05-classes-and-objects.md +++ b/spec/05-classes-and-objects.md @@ -339,7 +339,8 @@ $M'$: - 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 labeled `protected`. - If $M'$ is not an abstract member, then $M$ must be labeled `override`. @@ -699,7 +700,7 @@ ClassTemplateOpt ::= `extends' ClassTemplate | [[`extends'] TemplateBody] The most general form of class definition is ```scala -class $c$[$\mathit{tps}\,$] $as$ $m$($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$) extends $t$ $\gap(n \geq 0)$. +class $c$[$\mathit{tps}\,$] $as$ $m$($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$) extends $t$ $\quad(n \geq 0)$. ``` Here, @@ -719,7 +720,7 @@ Here, - $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$. @@ -885,10 +886,10 @@ object $c$ { 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$. +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. @@ -919,9 +920,9 @@ def copy[$\mathit{tps}\,$]($\mathit{ps}'_1\,$)$\ldots$($\mathit{ps}'_n$): $c$[$\ ``` 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}$`. +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}$`. diff --git a/spec/06-expressions.md b/spec/06-expressions.md index b2144aac6d..7e0a5facf1 100644 --- a/spec/06-expressions.md +++ b/spec/06-expressions.md @@ -62,12 +62,12 @@ $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 +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$ }. ``` @@ -269,7 +269,7 @@ it has the form $x_i=e'_i$ and $x_i$ is one of the parameter names $p_1 , \ldots , p_n$. The function $f$ is applicable if all of the following conditions hold: -- For every named argument $x_i=e'_i$ the type $S_i$ +- For every named argument $x_i=e_i'$ the type $S_i$ is compatible with the parameter type $T_j$ whose name $p_j$ matches $x_i$. - For every positional argument $e_i$ the type $S_i$ is compatible with $T_i$. @@ -388,7 +388,7 @@ the form } ``` -where every argument in $(\mathit{args}_1) , \ldots , (\mathit{args}_l)$ is a reference to +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 @@ -700,18 +700,18 @@ 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)$. @@ -817,12 +817,12 @@ the invocation of an `update` function defined by $f$. ###### Example Here are some assignment expressions and their equivalent expansions. --------------------------- --------------------- -`x.f = e` x.f_=(e) -`x.f() = e` x.f.update(e) -`x.f(i) = e` x.f.update(i, e) -`x.f(i, j) = e` x.f.update(i, j, e) --------------------------- --------------------- +| assignment | expansion | +|--------------------------|----------------------| +|`x.f = e` | `x.f_=(e)` | +|`x.f() = e` | `x.f.update(e)` | +|`x.f(i) = e` | `x.f.update(i, e)` | +|`x.f(i, j) = e` | `x.f.update(i, j, e)`| ### Example diff --git a/spec/07-implicit-parameters-and-views.md b/spec/07-implicit-parameters-and-views.md index 1a4d70409c..e07adc9e82 100644 --- a/spec/07-implicit-parameters-and-views.md +++ b/spec/07-implicit-parameters-and-views.md @@ -203,14 +203,14 @@ the type: - 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_ $\mathit{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, $\mathit{complexity}(p.c) ~=~ 1 + \mathit{complexity}(p)$ -- For a parameterized type, $\mathit{complexity}(p.c[\mathit{targs}]) ~=~ 1 + \Sigma \mathit{complexity}(\mathit{targs})$ -- For a singleton type denoting a package $p$, $\mathit{complexity}(p.type) ~=~ 0$ -- For any other singleton type, $\mathit{complexity}(p.type) ~=~ 1 + \mathit{complexity}(T)$, provided $p$ has type $T$; -- For a compound type, `$\mathit{complexity}(T_1$ with $\ldots$ with $T_n)$` $= \Sigma\mathit{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)$ ###### Example diff --git a/spec/08-pattern-matching.md b/spec/08-pattern-matching.md index 7b4d070181..6f71196b0d 100644 --- a/spec/08-pattern-matching.md +++ b/spec/08-pattern-matching.md @@ -63,7 +63,7 @@ patterns. 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 -given from outside. A special case is the wild-card pattern $\_$ +given from outside. A special case is the wild-card pattern `_` which is treated as if it was a fresh variable on each occurrence. ### Typed Patterns @@ -100,7 +100,7 @@ and it binds the variable name to that value. ``` 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 +`==`) to the literal $L$. The type of $L$ must conform to the expected type of the pattern. ### Stable Identifier Patterns @@ -346,7 +346,7 @@ A type pattern $T$ is of one of the following forms: the type patterns $T_i$. * A parameterized type pattern $T[a_1 , \ldots , a_n]$, where the $a_i$ - are type variable patterns or wildcards $\_$. + are type variable patterns or wildcards `_`. 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 @@ -377,62 +377,64 @@ 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 +$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 +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$ +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 -| | | | | -|-------------|------|---------------|------------------------| -|$a_i$ | $<:$ | $\sigma U_i$ | $(i = 1, \ldots , n)$ | -|$\sigma L_i$ | $<:$ | $a_i$ | $(i = 1 , \ldots , n)$ | +$$ +\begin{cases} +a_i &<: \sigma U_i & \quad (i = 1, \ldots , n) \\\\ +\sigma L_i &<: a_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 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 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 +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 +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 +$\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 +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. +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 +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$. +$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 @@ -552,16 +554,16 @@ $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'_1 , \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 +$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$$ 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$. +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 whole pattern matching expression. The type of the pattern matching @@ -571,7 +573,7 @@ $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$`. +[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 diff --git a/spec/10-xml-expressions-and-patterns.md b/spec/10-xml-expressions-and-patterns.md index d8c45ecf85..8d4b459844 100644 --- a/spec/10-xml-expressions-and-patterns.md +++ b/spec/10-xml-expressions-and-patterns.md @@ -37,10 +37,10 @@ Entity references are not resolved at runtime. Element ::= EmptyElemTag | STag Content ETag -EmptyElemTag ::= ‘<’ Name {S Attribute} [S] ‘/>’ +EmptyElemTag ::= ‘<’ Name {S Attribute} [S] ‘/>’ -STag ::= ‘<’ Name {S Attribute} [S] ‘>’ -ETag ::= ‘’ +STag ::= ‘<’ Name {S Attribute} [S] ‘>’ +ETag ::= ‘’ Content ::= [CharData] {Content1 [CharData]} Content1 ::= XmlContent | Reference @@ -68,7 +68,7 @@ character `\u0020`. This behavior can be changed to preserve all whitespace with a compiler option. ```ebnf -Attribute ::= Name Eq AttValue +Attribute ::= Name Eq AttValue AttValue ::= ‘"’ {CharQ | CharRef} ‘"’ | ‘'’ {CharA | CharRef} ‘'’ @@ -76,8 +76,8 @@ AttValue ::= ‘"’ {CharQ | CharRef} ‘"’ ScalaExpr ::= Block -CharData ::= { CharNoRef } $\mbox{\rm\em without}$ {CharNoRef}`{'CharB {CharNoRef} - $\mbox{\rm\em and without}$ {CharNoRef}`]]>'{CharNoRef} +CharData ::= { CharNoRef } $\textit{ without}$ {CharNoRef}`{'CharB {CharNoRef} + $\textit{ and without}$ {CharNoRef}`]]>'{CharNoRef} ``` @@ -90,17 +90,17 @@ Thus, `{{` represents the XML text `{` and does not introduce an embedded Scala ```ebnf BaseChar, Char, Comment, CombiningChar, Ideographic, NameChar, S, Reference - ::= $\mbox{\rm\em “as in W3C XML”}$ + ::= $\textit{“as in W3C XML”}$ -Char1 ::= Char $\mbox{\rm\em without}$ ‘<’ | ‘&’ -CharQ ::= Char1 $\mbox{\rm\em without}$ ‘"’ -CharA ::= Char1 $\mbox{\rm\em without}$ ‘'’ -CharB ::= Char1 $\mbox{\rm\em without}$ ‘{’ +Char1 ::= Char $\textit{ without}$ ‘<’ | ‘&’ +CharQ ::= Char1 $\textit{ without}$ ‘"’ +CharA ::= Char1 $\textit{ without}$ ‘'’ +CharB ::= Char1 $\textit{ without}$ ‘{’ Name ::= XNameStart {NameChar} XNameStart ::= ‘_’ | BaseChar | Ideographic - $\mbox{\rm\em (as in W3C XML, but without }$ ‘:’ + $\textit{ (as in W3C XML, but without }$ ‘:’$)$ ``` ## XML patterns diff --git a/spec/12-the-scala-standard-library.md b/spec/12-the-scala-standard-library.md index 9d4d69e52a..7ccbe0c9bd 100644 --- a/spec/12-the-scala-standard-library.md +++ b/spec/12-the-scala-standard-library.md @@ -86,8 +86,8 @@ class AnyRef extends Any { def synchronized[T](body: => T): T // execute `body` in while locking `this`. } +``` -```scala The type test `$x$.isInstanceOf[$T$]` is equivalent to a typed pattern match -- cgit v1.2.3