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`.
scala · retronym · Sep 18, 2014 · Jul 29, 2014 · Sep 15, 2014 · Sep 15, 2014
commit bca19f35103c4ff1205e1c8054eb3f803217a18b
diff --git 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
@@ -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
@@ -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
@@ -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$.
-  <!-- TODO: check whether this is accurate -->
+
+<!-- TODO: check whether this is accurate -->
 - 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
@@ -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
@@ -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