interim commit of conversion of types chapter

1 files changed, 530 insertions, 531 deletions

diff --git a/05-types.md b/05-types.md
index 104608da6a..cd28439e71 100644
--- a/05-types.md
+++ b/05-types.md
@@ -1,282 +1,287 @@
 Types
 =====
 
-
-\syntax\begin{lstlisting}
-  Type              ::=  FunctionArgTypes `=>' Type
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+  Type              ::=  FunctionArgTypes ‘=>’ Type
                       |  InfixType [ExistentialClause]
   FunctionArgTypes  ::= InfixType
-                      | `(' [ ParamType {`,' ParamType } ] `)'
-  ExistentialClause ::=  `forSome' `{' ExistentialDcl {semi ExistentialDcl} `}'
-  ExistentialDcl    ::=  `type' TypeDcl 
-                      |  `val' ValDcl
+                      | ‘(’ [ ParamType {‘,’ ParamType } ] ‘)’
+  ExistentialClause ::=  ‘forSome’ ‘{’ ExistentialDcl {semi ExistentialDcl} ‘}’
+  ExistentialDcl    ::=  ‘type’ TypeDcl 
+                      |  ‘val’ ValDcl
   InfixType         ::=  CompoundType {id [nl] CompoundType}
-  CompoundType      ::=  AnnotType {`with' AnnotType} [Refinement]
+  CompoundType      ::=  AnnotType {‘with’ AnnotType} [Refinement]
                       |  Refinement
   AnnotType         ::=  SimpleType {Annotation}
   SimpleType        ::=  SimpleType TypeArgs
-                      |  SimpleType `#' id
+                      |  SimpleType ‘#’ id
                       |  StableId
-                      |  Path `.' `type'
-                      |  `(' Types ')'
-  TypeArgs          ::=  `[' Types `]'
-  Types             ::=  Type {`,' Type}
-\end{lstlisting}
+                      |  Path ‘.’ ‘type’
+                      |  ‘(’ Types ‘)’
+  TypeArgs          ::=  ‘[’ Types ‘]’
+  Types             ::=  Type {‘,’ Type}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We distinguish between first-order types and type constructors, which
 take type parameters and yield types. A subset of first-order types
-called {\em value types} represents sets of (first-class) values.
-Value types are either {\em concrete} or {\em abstract}. 
-
-Every concrete value type can be represented as a {\em class type}, i.e.\ a
-type designator (\sref{sec:type-desig}) that refers to a
-a class or a trait\footnote{We assume that objects and packages also implicitly
-define a class (of the same name as the object or package, but
-inaccessible to user programs).} (\sref{sec:class-defs}), or as a {\em
-compound type} (\sref{sec:compound-types}) representing an
-intersection of types, possibly with a refinement
-(\sref{sec:refinements}) that further constrains the types of its
-members.
-\comment{A shorthand exists for denoting function types (\sref{sec:function-types}).  }
-Abstract value types are introduced by type parameters (\sref{sec:type-params}) 
-and abstract type bindings (\sref{sec:typedcl}). Parentheses in types can be used for
-grouping.
-
-%@M
-Non-value types capture properties of identifiers that are not values
-(\sref{sec:synthetic-types}). For example, a type constructor (\sref{sec:higherkinded-types}) does not directly specify a type of values. However, when a type constructor is applied to the correct type arguments, it yields a first-order type, which may be a value type. 
-
-Non-value types are expressed indirectly in Scala. E.g., a method type is described by writing down a method signature, which in itself is not a real type, although it  gives rise to a corresponding method type (\sref{sec:method-types}). Type constructors are another example, as one can write \lstinline@type Swap[m[_, _], a,b] = m[b, a]@, but there is no syntax to write the corresponding anonymous type function directly.
-
-\section{Paths}\label{sec:paths}\label{sec:stable-ids}
-
-\syntax\begin{lstlisting}
-  Path            ::=  StableId
-                    |  [id `.'] this
-  StableId        ::=  id
-                    |  Path `.' id
-                    |  [id '.'] `super' [ClassQualifier] `.' id
-  ClassQualifier  ::= `[' id `]'
-\end{lstlisting}
+called _value types_ represents sets of (first-class) values.
+Value types are either _concrete_ or _abstract_. 
+
+Every concrete value type can be represented as a _class type_, i.e. a
+[type designator](#type-designators) that refers to a
+a [class or a trait](#class-definitions) [^1], or as a
+[compound type](#compound-types) representing an
+intersection of types, possibly with a [refinement](#compound-types)
+that further constrains the types of its members.
+<!-- 
+A shorthand exists for denoting function types (\sref{sec:function-types}). 
+-->
+Abstract value types are introduced by [type parameters](#type-parameters)
+and [abstract type bindings](#type-declarations-and-type-aliases). 
+Parentheses in types can be used for grouping.
+
+[^1]: We assume that objects and packages also implicitly
+      define a class (of the same name as the object or package, but
+      inaccessible to user programs).
+
+Non-value types capture properties of identifiers that 
+[are not values](#non-value-types). For example, a 
+[type constructor](#type-constructors) does not directly specify a type of 
+values. However, when a type constructor is applied to the correct type 
+arguments, it yields a first-order type, which may be a value type. 
+
+Non-value types are expressed indirectly in Scala. E.g., a method type is 
+described by writing down a method signature, which in itself is not a real 
+type, although it  gives rise to a corresponding [method type](#method-types). 
+Type constructors are another example, as one can write 
+`type Swap[m[_, _], a,b] = m[b, a]`{.scala}, but there is no syntax to write 
+the corresponding anonymous type function directly.
+
+
+Paths
+-----
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+Path            ::=  StableId
+                  |  [id ‘.’] this
+StableId        ::=  id
+                  |  Path ‘.’ id
+                  |  [id ‘.’] ‘super’ [ClassQualifier] ‘.’ id
+ClassQualifier  ::= ‘[’ id ‘]’
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Paths are not types themselves, but they can be a part of named types
 and in that function form a central role in Scala's type system.
 
 A path is one of the following.
-\begin{itemize}
-\item
-The empty path $\epsilon$ (which cannot be written explicitly in user programs).
-\item
-\lstinline@$C$.this@, where $C$ references a class. 
-The path \code{this} is taken as a shorthand for \lstinline@$C$.this@ where 
-$C$ is the name of the class directly enclosing the reference. 
-\item
-\lstinline@$p$.$x$@ where $p$ is a path and $x$ is a stable member of $p$.
-{\em Stable members} are packages or members introduced by object definitions or 
-by value definitions of non-volatile types
-(\sref{sec:volatile-types}). 
 
-\item
-\lstinline@$C$.super.$x$@ or \lstinline@$C$.super[$M\,$].$x$@
-where $C$ references a class and $x$ references a 
-stable member of the super class or designated parent class $M$ of $C$. 
-The prefix \code{super} is taken as a shorthand for \lstinline@$C$.super@ where 
-$C$ is the name of the class directly enclosing the reference. 
-\end{itemize}
-A {\em stable identifier} is a path which ends in an identifier.
+- The empty path ε (which cannot be written explicitly in user programs).
+- `C.this`, where _C_ references a class. 
+  The path `this` is taken as a shorthand for `C.this` where 
+  _C_ is the name of the class directly enclosing the reference. 
+- `p.x` where _p_ is a path and _x_ is a stable member of _p_.
+  _Stable members_ are packages or members introduced by object definitions or 
+  by value definitions of [non-volatile types](#volatile-types).
+- `C.super.x` or `C.super[M].x`
+  where _C_ references a class and _x_ references a 
+  stable member of the super class or designated parent class _M_ of _C_. 
+  The prefix `super`{.scala} is taken as a shorthand for `C.super` where 
+  _C_ is the name of the class directly enclosing the reference. 
+
 
-\section{Value Types}\label{sec:value-types}
+A _stable identifier_ is a path which ends in an identifier.
+
+Value Types
+-----------
 
 Every value in Scala has a type which is of one of the following
 forms.
 
-\subsection{Singleton Types}
-\label{sec:singleton-types}
-\label{sec:type-stability}
+### Singleton Types
 
-\syntax\begin{lstlisting}
-  SimpleType  ::=  Path `.' type
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+SimpleType  ::=  Path ‘.’ type
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A singleton type is of the form \lstinline@$p$.type@, where $p$ is a
-path pointing to a value expected to conform (\sref{sec:expr-typing})
-to \lstinline@scala.AnyRef@.  The type denotes the set of values
-consisting of \code{null} and the value denoted by $p$. 
+A singleton type is of the form `p.type`{.scala}, where _p_ is a
+path pointing to a value expected to [conform](#expression-typing)
+to `scala.AnyRef`{.scala}. The type denotes the set of values
+consisting of `null`{.scala} and the value denoted by _p_. 
 
-A {\em stable type} is either a singleton type or a type which is
-declared to be a subtype of trait \lstinline@scala.Singleton@.
+A _stable type_ is either a singleton type or a type which is
+declared to be a subtype of trait `scala.Singleton`{.scala}.
 
-\subsection{Type Projection}
-\label{sec:type-project}
+### Type Projection
 
-\syntax\begin{lstlisting} 
-  SimpleType  ::=  SimpleType `#' id
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+SimpleType  ::=  SimpleType ‘#’ id
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A type projection \lstinline@$T$#$x$@ references the type member named
-$x$ of type $T$. 
-% The following is no longer necessary:
-%If $x$ references an abstract type member, then $T$ must be a stable type (\sref{sec:singleton-types}). 
+A type projection `T#x`{.scala} references the type member named
+_x_ of type _T_. 
 
-\subsection{Type Designators}
-\label{sec:type-desig}
+<!--
+The following is no longer necessary:
+If $x$ references an abstract type member, then $T$ must be a stable type (\sref{sec:singleton-types}). 
+-->
 
-\syntax\begin{lstlisting}
-  SimpleType  ::=  StableId
-\end{lstlisting}
+### Type Designators
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+SimpleType  ::=  StableId
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A type designator refers to a named value type. It can be simple or
 qualified. All such type designators are shorthands for type projections.
 
-Specifically, the unqualified type name $t$ where $t$ is bound in some
-class, object, or package $C$ is taken as a shorthand for
-\lstinline@$C$.this.type#$t$@. If $t$ is
-not bound in a class, object, or package, then $t$ is taken as a
-shorthand for \lstinline@$\epsilon$.type#$t$@.
-
-A qualified type designator has the form \lstinline@$p$.$t$@ where $p$ is
-a path (\sref{sec:paths}) and $t$ is a type name. Such a type designator is
-equivalent to the type projection \lstinline@$p$.type#$t$@.
-
-\example 
-Some type designators and their expansions are listed below. We assume
-a local type parameter $t$, a value \code{maintable}
-with a type member \code{Node} and the standard class \lstinline@scala.Int@, 
-\begin{lstlisting}
-  t                     $\epsilon$.type#t
-  Int                   scala.type#Int
-  scala.Int             scala.type#Int
-  data.maintable.Node   data.maintable.type#Node
-\end{lstlisting}
-
-\subsection{Parameterized Types}
-\label{sec:param-types}
-
-\syntax\begin{lstlisting}
-  SimpleType      ::=  SimpleType TypeArgs
-  TypeArgs        ::=  `[' Types `]'
-\end{lstlisting}
-
-A parameterized type $T[U_1 \commadots U_n]$ consists of a type
-designator $T$ and type parameters $U_1 \commadots U_n$ where $n \geq
-1$.  $T$ must refer to a type constructor which takes $n$ type
-parameters $a_1 \commadots a_n$.
-
-Say the type parameters have lower bounds $L_1 \commadots L_n$ and
-upper bounds $U_1 \commadots U_n$.  The parameterized type is
-well-formed if each actual type parameter {\em conforms to its
-bounds}, i.e.\ $\sigma L_i <: T_i <: \sigma U_i$ where $\sigma$ is the
-substitution $[a_1 := T_1 \commadots a_n := T_n]$.
-
-\example\label{ex:param-types}
-Given the partial type definitions:
-
-\begin{lstlisting}
-  class TreeMap[A <: Comparable[A], B] { $\ldots$ }
-  class List[A] { $\ldots$ }
-  class I extends Comparable[I] { $\ldots$ }
-  
-  class F[M[_], X] { $\ldots$ }
-  class S[K <: String] { $\ldots$ }
-  class G[M[ Z <: I ], I] { $\ldots$ }
-\end{lstlisting}
-
-the following parameterized types are well formed:
-
-\begin{lstlisting}
-  TreeMap[I, String]
-  List[I]
-  List[List[Boolean]]
-  
-  F[List, Int]
-  G[S, String]
-\end{lstlisting}
-
-\example Given the type definitions of \ref{ex:param-types},
-the following types are ill-formed:
-
-\begin{lstlisting}
-  TreeMap[I]            // illegal: wrong number of parameters
-  TreeMap[List[I], Int] // illegal: type parameter not within bound
-  
-  F[Int, Boolean]       // illegal: Int is not a type constructor
-  F[TreeMap, Int]       // illegal: TreeMap takes two parameters,
-                        //   F expects a constructor taking one
-  G[S, Int]             // illegal: S constrains its parameter to
-                        //   conform to String,
-                        // G expects type constructor with a parameter
-                        //   that conforms to Int
-\end{lstlisting}
-
-\subsection{Tuple Types}\label{sec:tuple-types}
-
-\syntax\begin{lstlisting}
-  SimpleType    ::=   `(' Types ')'
-\end{lstlisting}
-
-A tuple type \lstinline@($T_1 \commadots T_n$)@ is an alias for the
-class ~\lstinline@scala.Tuple$n$[$T_1 \commadots T_n$]@, where $n \geq
-2$.
+Specifically, the unqualified type name _t_ where _t_ is bound in some
+class, object, or package _C_ is taken as a shorthand for
+`C.this.type#t`{.scala}. If _t_ is
+not bound in a class, object, or package, then _t_ is taken as a
+shorthand for `ε.type#t`.
+
+A qualified type designator has the form `p.t` where `p` is
+a [path](#paths) and _t_ is a type name. Such a type designator is
+equivalent to the type projection `p.type#t`{.scala}.
+
+(@) Some type designators and their expansions are listed below. We assume
+    a local type parameter _t_, a value `maintable`
+    with a type member `Node` and the standard class `scala.Int`, 
+
+    --------------------  --------------------------
+    t                     $\epsilon$.type#t
+    Int                   scala.type#Int
+    scala.Int             scala.type#Int
+    data.maintable.Node   data.maintable.type#Node
+    --------------------  --------------------------
+
+
+### Parameterized Types
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+SimpleType      ::=  SimpleType TypeArgs
+TypeArgs        ::=  ‘[’ Types ‘]’
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A parameterized type T[ U~1~ , … , U~n~ ] consists of a type
+designator _T_ and type parameters _U~1~ , … , U~n~_ where 
+_n ≥ 1_. _T_ must refer to a type constructor which takes _n_ type
+parameters _a~1~ , … , s a~n~_.
+
+Say the type parameters have lower bounds _L~1~ , … , L~n~_ and
+upper bounds _U~1~ … U~n~_.  The parameterized type is
+well-formed if each actual type parameter
+_conforms to its bounds_, i.e. _σ L~i~ <: T~i~ <: σ U~i~_ where σ is the
+substitution [ _a~1~_ := _T~1~_ , … , _a~n~_ := _T~n~_ ].
+
+(@param-types) Given the partial type definitions:
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    class TreeMap[A <: Comparable[A], B] { … }
+    class List[A] { … }
+    class I extends Comparable[I] { … }
+    
+    class F[M[_], X] { … }
+    class S[K <: String] { … }
+    class G[M[ Z <: I ], I] { … }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    the following parameterized types are well formed:
+
+    ~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+      TreeMap[I, String]
+      List[I]
+      List[List[Boolean]]
+      
+      F[List, Int]
+      G[S, String]
+    ~~~~~~~~~~~~~~~~~~~~~~
+
+(@) Given the type definitions of (@param-types),
+    the following types are ill-formed:
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    TreeMap[I]            // illegal: wrong number of parameters
+    TreeMap[List[I], Int] // illegal: type parameter not within bound
+    
+    F[Int, Boolean]       // illegal: Int is not a type constructor
+    F[TreeMap, Int]       // illegal: TreeMap takes two parameters,
+                          //   F expects a constructor taking one
+    G[S, Int]             // illegal: S constrains its parameter to
+                          //   conform to String,
+                          // G expects type constructor with a parameter
+                          //   that conforms to Int
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+### Tuple Types
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+SimpleType    ::=   ‘(’ Types ‘)’
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A tuple type (T~1~ , … , T~n~) is an alias for the
+class `scala.Tuple`~n~`[`T~1~`, … , `T~n~`]`, where _n ≥ 2_.
 
 Tuple classes are case classes whose fields can be accessed using
-selectors ~\code{_1}, ..., \lstinline@_$n$@. Their functionality is
-abstracted in a corresponding \code{Product} trait. The $n$-ary tuple
+selectors `_1` , … , `_n`. Their functionality is
+abstracted in a corresponding `Product` trait. The _n_-ary tuple
 class and product trait are defined at least as follows in the
 standard Scala library (they might also add other methods and
 implement other traits).
 
-\begin{lstlisting}
-case class Tuple$n$[+T1, ..., +T$n$](_1: T1, ..., _$n$: T$n$) 
-extends Product$n$[T1, ..., T$n$] {}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+case class Tuple_n[+T1, … , +Tn](_1: T1, … , _n: Tn) 
+extends Product_n[T1, … , Tn] {}
 
-trait Product$n$[+T1, +T2, +T$n$] {
-  override def arity = $n$
+trait Product_n[+T1, … , +Tn] {
+  override def arity = n
   def _1: T1
-  ...
-  def _$n$:T$n$
+  …
+  def _n: Tn
 }
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-\subsection{Annotated Types}
+### Annotated Types
 
-\syntax\begin{lstlisting}
-  AnnotType  ::=  SimpleType {Annotation}
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+AnnotType  ::=  SimpleType {Annotation}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-An annotated type ~$T$\lstinline@ $a_1 \ldots a_n$@
-attaches annotations $a_1 \commadots a_n$ to the type $T$
-(\sref{sec:annotations}).
+An annotated type _T a~1~ , … , a~n~_
+attaches [annotations](#user-defined-annotations) 
+_a~1~ , … , a~n~_ to the type _T_.
 
-\example The following type adds the \code{@suspendable}@ annotation to the type
-\code{String}:
-\begin{lstlisting}
-  String @suspendable
-\end{lstlisting}
+(@) The following type adds the `@suspendable`{.scala} annotation to the type
+    `String`{.scala}:
 
-\subsection{Compound Types}
-\label{sec:compound-types}
-\label{sec:refinements}
-
-\syntax\begin{lstlisting}
-  CompoundType    ::=  AnnotType {`with' AnnotType} [Refinement]
-                    |  Refinement
-  Refinement      ::=  [nl] `{' RefineStat {semi RefineStat} `}'
-  RefineStat      ::=  Dcl
-                    |  `type' TypeDef
-                    |
-\end{lstlisting}
+    ~~~~~~~~~~~~~~~~~~~~ {.scala}
+    String @suspendable
+    ~~~~~~~~~~~~~~~~~~~~
 
-A compound type ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~
-represents objects with members as given in the component types $T_1
-\commadots T_n$ and the refinement \lstinline@{$R\,$}@. A refinement
-\lstinline@{$R\,$}@ contains declarations and type definitions. 
+
+### Compound Types
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+CompoundType    ::=  AnnotType {‘with’ AnnotType} [Refinement]
+                  |  Refinement
+Refinement      ::=  [nl] ‘{’ RefineStat {semi RefineStat} ‘}’
+RefineStat      ::=  Dcl
+                  |  ‘type’ TypeDef
+                  |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A compound type `T1 with … with Tn { R }`
+represents objects with members as given in the component types 
+_T1 , … , Tn_ and the refinement `{ R }`. A refinement
+`{ R }` contains declarations and type definitions. 
 If a declaration or definition overrides a declaration or definition in
-one of the component types $T_1 \commadots T_n$, the usual rules for
-overriding (\sref{sec:overriding}) apply; otherwise the declaration
-or definition is said to be ``structural''\footnote{A reference to a
-structurally defined member (method call or access to a value or
-variable) may generate binary code that is significantly slower than
-an equivalent code to a non-structural member.}. 
+one of the component types _T1 , … , T_n_, the usual rules for
+[overriding](#overriding) apply; otherwise the declaration
+or definition is said to be “structural” [^2].
+
+[^2]: A reference to a structurally defined member (method call or access 
+to a value or variable) may generate binary code that is significantly 
+slower than an equivalent code to a non-structural member.
 
 Within a method declaration in a structural refinement, the type of
 any value parameter may only refer to type parameters or abstract
@@ -286,155 +291,163 @@ definition within the refinement. This restriction does not apply to
 the function's result type.
 
 If no refinement is given, the empty refinement is implicitly added,
-i.e.\  ~\lstinline@$T_1$ with $\ldots$ with $T_n$@~ is a shorthand for
-~\lstinline@$T_1$ with $\ldots$ with $T_n$ {}@.
+i.e.\  `T1 with … with Tn`{.scala} is a shorthand for
+`T1 with … with Tn {}`{.scala}.
 
 A compound type may also consist of just a refinement
-~\lstinline@{$R\,$}@ with no preceding component types. Such a type is
-equivalent to ~\lstinline@AnyRef{$R\,$}@.
-
-\example The following example shows how to declare and use a function which parameter's type contains a refinement with structural declarations.
-\begin{lstlisting}[escapechar=\%]
-  case class Bird (val name: String) extends Object {
-  	def fly(height: Int) = ...
-	...
-  }
-  case class Plane (val callsign: String) extends Object {
-  	def fly(height: Int) = ...
-	...
-  }
-  def takeoff(
-  	    runway: Int,
-        r: { val callsign: String; def fly(height: Int) }) = {
-    tower.print(r.callsign + " requests take-off on runway " + runway)
-    tower.read(r.callsign + " is clear f%%or take-off")
-    r.fly(1000)
-  }
-  val bird = new Bird("Polly the parrot"){ val callsign = name }
-  val a380 = new Plane("TZ-987")
-  takeoff(42, bird)
-  takeoff(89, a380)
-\end{lstlisting}
-Although ~\lstinline@Bird@ and ~\lstinline@Plane@ do not share any parent class other than ~\lstinline@Object@, the parameter ~\lstinline@r@ of function ~\lstinline@takeoff@ is defined using a refinement with structural declarations to accept any object that declares a value ~\lstinline@callsign@ and a ~\lstinline@fly@ function.
+`{ R }` with no preceding component types. Such a type is
+equivalent to `AnyRef{ R }`{.scala}.
+
+(@) The following example shows how to declare and use a function which 
+    parameter's type contains a refinement with structural declarations.
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    case class Bird (val name: String) extends Object {
+    	def fly(height: Int) = …
+  	…
+    }
+    case class Plane (val callsign: String) extends Object {
+    	def fly(height: Int) = …
+  	…
+    }
+    def takeoff(
+    	    runway: Int,
+          r: { val callsign: String; def fly(height: Int) }) = {
+      tower.print(r.callsign + " requests take-off on runway " + runway)
+      tower.read(r.callsign + " is clear for take-off")
+      r.fly(1000)
+    }
+    val bird = new Bird("Polly the parrot"){ val callsign = name }
+    val a380 = new Plane("TZ-987")
+    takeoff(42, bird)
+    takeoff(89, a380)
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    Although `Bird` and `Plane` do not share any parent class other than 
+    `Object`, the parameter _r_ of function `takeoff` is defined using a 
+    refinement with structural declarations to accept any object that declares 
+    a value `callsign` and a `fly` function.
 
  
-\subsection{Infix Types}\label{sec:infix-types}
+### Infix Types
 
-\syntax\begin{lstlisting}
-  InfixType     ::=  CompoundType {id [nl] CompoundType}
-\end{lstlisting}
-An infix type ~\lstinline@$T_1\;\op\;T_2$@~ consists of an infix
-operator $\op$ which gets applied to two type operands $T_1$ and
-$T_2$.  The type is equivalent to the type application $\op[T_1,
-T_2]$.  The infix operator $\op$ may be an arbitrary identifier,
-except for \code{*}, which is reserved as a postfix modifier 
-denoting a repeated parameter type (\sref{sec:repeated-params}). 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+InfixType     ::=  CompoundType {id [nl] CompoundType}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An infix type _T~1~ op T~2~_ consists of an infix
+operator _op_ which gets applied to two type operands _T~1~_ and
+_T~2~_.  The type is equivalent to the type application 
+`op[T₁, T₂]`.  The infix operator _op_ may be an arbitrary identifier,
+except for `*`, which is reserved as a postfix modifier 
+denoting a [repeated parameter type](#repeated-parameters). 
 
 All type infix operators have the same precedence; parentheses have to
-be used for grouping. The associativity (\sref{sec:infix-operations})
+be used for grouping. The [associativity](#prefix-infix-and-postfix-operations)
 of a type operator is determined as for term operators: type operators
-ending in a colon `\lstinline@:@' are right-associative; all other
+ending in a colon ‘:’ are right-associative; all other
 operators are left-associative.
 
-In a sequence of consecutive type infix operations $t_0; \op_1; t_1;
-\op_2 \ldots \op_n; t_n$, all operators $\op_1 \commadots \op_n$ must have the same
+In a sequence of consecutive type infix operations 
+$t_0 \, op \, t_1 \, op_2 \, … \, op_n \, t_n$,
+all operators $\op_1 , … , \op_n$ must have the same
 associativity. If they are all left-associative, the sequence is
-interpreted as $(\ldots(t_0;\op_1;t_1);\op_2\ldots);\op_n;t_n$,
-otherwise it is interpreted as $t_0;\op_1;(t_1;\op_2;(\ldots\op_n;t_n)\ldots)$.
+interpreted as `(… (t_0 op_1 t_1) op_2 …) op_n t_n`,
+otherwise it is interpreted as $t_0 op_1 (t_1 op_2 ( … op_n t_n) …)$.
 
-\subsection{Function Types}
-\label{sec:function-types}
+### Function Types
 
-\syntax\begin{lstlisting}
-  Type              ::=  FunctionArgs `=>' Type
-  FunctionArgs      ::=  InfixType
-                      |  `(' [ ParamType {`,' ParamType } ] `)'
-\end{lstlisting}
-The type ~\lstinline@($T_1 \commadots T_n$) => $U$@~ represents the set of function
-values that take arguments of types $T_1 \commadots T_n$ and yield
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+Type              ::=  FunctionArgs ‘=>’ Type
+FunctionArgs      ::=  InfixType
+                    |  ‘(’ [ ParamType {‘,’ ParamType } ] ‘)’
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The type $(T_1 , \ldots , T_n) \Rightarrow U$ represents the set of function
+values that take arguments of types $T1 , \ldots , Tn$ and yield
 results of type $U$.  In the case of exactly one argument type
-~\lstinline@$T$ => $U$@~ is a shorthand for ~\lstinline@($T\,$) => $U$@.  
-An argument type of the form~\lstinline@=> T@
-represents a call-by-name parameter (\sref{sec:by-name-params}) of type $T$.
+$T \Rightarrow U$ is a shorthand for $(T) \Rightarrow U$.  
+An argument type of the form $\Rightarrow T$
+represents a [call-by-name parameter](#by-name-parameters) of type $T$.
 
 Function types associate to the right, e.g.
-~\lstinline@$S$ => $T$ => $U$@~ is the same as 
-~\lstinline@$S$ => ($T$ => $U$)@.
+`S => T => U` is the same as `S => (T => U)`.
 
-Function types are shorthands for class types that define \code{apply}
+Function types are shorthands for class types that define `apply`
 functions.  Specifically, the $n$-ary function type 
-~\lstinline@($T_1 \commadots T_n$) => U@~ is a shorthand for the class type
-\lstinline@Function$n$[$T_1 \commadots T_n$,$U\,$]@. Such class
+`(T1 , … , Tn) => U` is a shorthand for the class type
+`Function_n[T1 , … , Tn, U]`. Such class
 types are defined in the Scala library for $n$ between 0 and 9 as follows.
-\begin{lstlisting}
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
 package scala 
-trait Function$n$[-$T_1 \commadots$ -$T_n$, +$R$] {
-  def apply($x_1$: $T_1 \commadots x_n$: $T_n$): $R$ 
+trait Function_n[-T1 , … , -Tn, +R] {
+  def apply(x1: T1 , … , xn: Tn): R 
   override def toString = "<function>" 
 }
-\end{lstlisting}
-Hence, function types are covariant (\sref{sec:variances}) in their
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Hence, function types are [covariant](#variance-annotations) in their
 result type and contravariant in their argument types.
 
+### Existential Types
 
-\subsection{Existential Types}
-\label{sec:existential-types}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+Type               ::= InfixType ExistentialClauses
+ExistentialClauses ::= ‘forSome’ ‘{’ ExistentialDcl 
+                       {semi ExistentialDcl} ‘}’
+ExistentialDcl     ::= ‘type’ TypeDcl 
+                    |  ‘val’ ValDcl
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-\syntax\begin{lstlisting}
-  Type               ::= InfixType ExistentialClauses
-  ExistentialClauses ::= `forSome' `{' ExistentialDcl 
-                         {semi ExistentialDcl} `}'
-  ExistentialDcl     ::= `type' TypeDcl 
-                      |  `val' ValDcl
-\end{lstlisting}
-An existential type has the form ~\lstinline@$T$ forSome {$\,Q\,$}@~
-where $Q$ is a sequence of type declarations \sref{sec:typedcl}.
-Let $t_1[\tps_1] >: L_1 <: U_1 \commadots t_n[\tps_n] >: L_n <: U_n$ 
+An existential type has the form `T forSome { Q }`
+where _Q_ is a sequence of 
+[type declarations](#type-declarations-and-type-aliases).
+
+Let $t_1[\mathit{tps}_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}_n] >: L_n <: U_n$ 
 be the types declared in $Q$ (any of the 
-type parameter sections \lstinline@[$\tps_i$]@ might be missing).
-The scope of each type $t_i$ includes the type $T$ and the existential clause $Q$. 
-The type variables $t_i$ are said to be {\em bound} in the type ~\lstinline@$T$ forSome {$\,Q\,$}@.
-Type variables which occur in a type $T$ but which are not bound in $T$ are said
-to be {\em free} in $T$.
+type parameter sections [ _tps~i~_ ] might be missing).
+The scope of each type _t~i~_ includes the type _T_ and the existential clause _Q_. 
+The type variables _t~i~_ are said to be _bound_ in the type `T forSome { Q }`.
+Type variables which occur in a type _T_ but which are not bound in _T_ are said
+to be _free_ in _T_.
 
-A {\em type instance} of ~\lstinline@$T$ forSome {$\,Q\,$}@ 
+%%% iainmcgin: to here
+
+A _type instance_ of ~\lstinline@$T$ forSome {$\,Q\,$}@ 
 is a type $\sigma T$ where $\sigma$ is a substitution over $t_1 \commadots t_n$
 such that, for each $i$, $\sigma L_i \conforms \sigma t_i \conforms \sigma U_i$.
 The set of values denoted by the existential type ~\lstinline@$T$ forSome {$\,Q\,$}@~
 is the union of the set of values of all its type instances.
 
-A {\em skolemization} of ~\lstinline@$T$ forSome {$\,Q\,$}@~ is
+A _skolemization_ of ~\lstinline@$T$ forSome {$\,Q\,$}@~ is
 a type instance $\sigma T$, where $\sigma$ is the substitution
 $[t'_1/t_1 \commadots 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$.
 
-\subsubsection*{Simplification Rules}\label{sec:ex-simpl}
+#### Simplification Rules
 
 Existential types obey the following four equivalences:
-\begin{enumerate}
-\item
-Multiple for-clauses in an existential type can be merged. E.g.,
+
+#. Multiple for-clauses in an existential type can be merged. E.g.,
 ~\lstinline@$T$ forSome {$\,Q\,$} forSome {$\,Q'\,$}@~
 is equivalent to
 ~\lstinline@$T$ forSome {$\,Q\,$;$\,Q'\,$}@.
-\item
-Unused quantifications can be dropped. E.g.,
+#. Unused quantifications can be dropped. E.g.,
 ~\lstinline@$T$ forSome {$\,Q\,$;$\,Q'\,$}@~
 where none of the types defined in $Q'$ are referred to by $T$ or $Q$,
 is equivalent to
 ~\lstinline@$T$ forSome {$\,Q\,$}@.
-\item
-An empty quantification can be dropped. E.g.,
+#. An empty quantification can be dropped. E.g.,
 ~\lstinline@$T$ forSome { }@~ is equivalent to ~\lstinline@$T$@.
-\item
-An existential type ~\lstinline@$T$ forSome {$\,Q\,$}@~ where $Q$ contains
+#. An existential type ~\lstinline@$T$ forSome {$\,Q\,$}@~ where $Q$ contains
 a clause ~\lstinline@type $t[\tps] >: L <: U$@ is equivalent 
 to the type ~\lstinline@$T'$ forSome {$\,Q\,$}@~ where $T'$ results from $T$ by replacing every
 covariant occurrence (\sref{sec:variances}) of $t$ in $T$ by $U$ and by replacing every
 contravariant occurrence of $t$ in $T$ by $L$.
-\end{enumerate}
 
-\subsubsection*{Existential Quantification over Values}\label{sec:val-existential-types}
+
+#### Existential Quantification over Values
 
 As a syntactic convenience, the bindings clause
 in an existential type may also contain
@@ -445,14 +458,14 @@ is treated as a shorthand for the type
 type name and $T'$ results from $T$ by replacing every occurrence of 
 \lstinline@$x$.type@ with $t$.
 
-\subsubsection*{Placeholder Syntax for Existential Types}\label{sec:impl-existential-types}
+#### Placeholder Syntax for Existential Types
 
-\syntax\begin{lstlisting}
-  WildcardType   ::=  `_' TypeBounds
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+WildcardType   ::=  ‘_’ TypeBounds
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Scala supports a placeholder syntax for existential types.
-A {\em wildcard type} is of the form ~\lstinline@_$\;$>:$\,L\,$<:$\,U$@. Both bound
+A _wildcard type_ is of the form ~\lstinline@_$\;$>:$\,L\,$<:$\,U$@. Both bound
 clauses may be omitted. If a lower bound clause \lstinline@>:$\,L$@ is missing, 
 \lstinline@>:$\,$scala.Nothing@~
 is assumed. If an upper bound clause ~\lstinline@<:$\,U$@ is missing, 
@@ -462,10 +475,12 @@ existentially quantified type variable, where the existential quantification is
 A wildcard type must appear as type argument of a parameterized type.
 Let $T = p.c[\targs,T,\targs']$ be a parameterized type where $\targs, \targs'$ may be empty and
 $T$ is a wildcard type ~\lstinline@_$\;$>:$\,L\,$<:$\,U$@. Then $T$ is equivalent to the existential
-type 
-\begin{lstlisting}
-   $p.c[\targs,t,\targs']$ forSome { type $t$ >: $L$ <: $U$ }
-\end{lstlisting}
+type
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+$p.c[\targs,t,\targs']$ forSome { type $t$ >: $L$ <: $U$ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 where $t$ is some fresh type variable. 
 Wildcard types may also appear as parts of infix types
 (\sref{sec:infix-types}), function types (\sref{sec:function-types}),
@@ -473,52 +488,65 @@ or tuple types (\sref{sec:tuple-types}).
 Their expansion is then the expansion in the equivalent parameterized
 type.
 
-\example Assume the class definitions
-\begin{lstlisting}
-class Ref[T]
-abstract class Outer { type T } .
-\end{lstlisting}
-Here are some examples of existential types:
-\begin{lstlisting}
-Ref[T] forSome { type T <: java.lang.Number }
-Ref[x.T] forSome { val x: Outer }
-Ref[x_type # T] forSome { type x_type <: Outer with Singleton }
-\end{lstlisting}
-The last two types in this list are equivalent.
-An alternative formulation of the first type above using wildcard syntax is:
-\begin{lstlisting}
-Ref[_ <: java.lang.Number]
-\end{lstlisting}
-
-\example The type \lstinline@List[List[_]]@ is equivalent to the existential type
-\begin{lstlisting}
-List[List[t] forSome { type t }] . 
-\end{lstlisting}
-
-\example Assume a covariant type
-\begin{lstlisting}
-class List[+T]
-\end{lstlisting}
-The type
-\begin{lstlisting}
-List[T] forSome { type T <: java.lang.Number }
-\end{lstlisting}
-is equivalent (by simplification rule 4 above) to
-\begin{lstlisting}
-List[java.lang.Number] forSome { type T <: java.lang.Number }
-\end{lstlisting}
-which is in turn equivalent (by simplification rules 2 and 3 above) to
-\lstinline@List[java.lang.Number]@.
-
-\section{Non-Value Types}
-\label{sec:synthetic-types}
+(@) Assume the class definitions
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    class Ref[T]
+    abstract class Outer { type T } .
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    Here are some examples of existential types:
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    Ref[T] forSome { type T <: java.lang.Number }
+    Ref[x.T] forSome { val x: Outer }
+    Ref[x_type # T] forSome { type x_type <: Outer with Singleton }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    The last two types in this list are equivalent.
+    An alternative formulation of the first type above using wildcard syntax is:
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    Ref[_ <: java.lang.Number]
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+(@) The type `List[List[_]]` is equivalent to the existential type
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    List[List[t] forSome { type t }] . 
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+(@) Assume a covariant type
+    
+    ~~~~~~~~~~~~~~~ {.scala}
+    class List[+T]
+    ~~~~~~~~~~~~~~~
+
+    The type
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    List[T] forSome { type T <: java.lang.Number }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    is equivalent (by simplification rule 4 above) to
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    List[java.lang.Number] forSome { type T <: java.lang.Number }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    which is in turn equivalent (by simplification rules 2 and 3 above) to
+    `List[java.lang.Number]`.
+
+
+Non-Value Types
+---------------
 
 The types explained in the following do not denote sets of values, nor
 do they appear explicitly in programs. They are introduced in this
 report as the internal types of defined identifiers.
 
-\subsection{Method Types}
-\label{sec:method-types}
+
+### Method Types
 
 A method type is denoted internally as $(\Ps)U$, where $(\Ps)$ is a
 sequence of parameter names and types $(p_1:T_1 \commadots p_n:T_n)$
@@ -539,21 +567,24 @@ Method types do not exist as types of values. If a method name is used
 as a value, its type is implicitly converted to a corresponding
 function type (\sref{sec:impl-conv}).
 
-\example The declarations
-\begin{lstlisting}
-def a: Int
-def b (x: Int): Boolean
-def c (x: Int) (y: String, z: String): String
-\end{lstlisting}
-produce the typings
-\begin{lstlisting}
-a: => Int
-b: (Int) Boolean
-c: (Int) (String, String) String
-\end{lstlisting}
+(@) The declarations
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    def a: Int
+    def b (x: Int): Boolean
+    def c (x: Int) (y: String, z: String): String
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    produce the typings
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    a: => Int
+    b: (Int) Boolean
+    c: (Int) (String, String) String
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+### Polymorphic Method Types
 
-\subsection{Polymorphic Method Types}
-\label{sec:poly-types}
 
 A polymorphic method type is denoted internally as ~\lstinline@[$\tps\,$]$T$@~ where
 \lstinline@[$\tps\,$]@ is a type parameter section 
@@ -565,123 +596,85 @@ conform (\sref{sec:param-types}) to the lower bounds
 ~\lstinline@$L_1 \commadots L_n$@~ and the upper bounds
 ~\lstinline@$U_1 \commadots U_n$@~ and that yield results of type $T$.
 
-\example The declarations
-\begin{lstlisting}
-def empty[A]: List[A]
-def union[A <: Comparable[A]] (x: Set[A], xs: Set[A]): Set[A]
-\end{lstlisting}
-produce the typings
-\begin{lstlisting}
-empty : [A >: Nothing <: Any] List[A]
-union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A]  .
-\end{lstlisting}
+(@) The declarations
 
-\subsection{Type Constructors} %@M
-\label{sec:higherkinded-types}
-A type constructor is represented internally much like a polymorphic method type.
-~\lstinline@[$\pm$ $a_1$ >: $L_1$ <: $U_1 \commadots \pm a_n$ >: $L_n$ <: $U_n$] $T$@~ represents a type that is expected by a type constructor parameter (\sref{sec:type-params}) or an abstract type constructor binding (\sref{sec:typedcl}) with the corresponding type parameter clause.
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    def empty[A]: List[A]
+    def union[A <: Comparable[A]] (x: Set[A], xs: Set[A]): Set[A]
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-\example Consider this fragment of the \lstinline@Iterable[+X]@ class:
-\begin{lstlisting}
-trait Iterable[+X] {
-  def flatMap[newType[+X] <: Iterable[X], S](f: X => newType[S]): newType[S]
-}
-\end{lstlisting}
+    produce the typings
 
-Conceptually, the type constructor \lstinline@Iterable@ is a name for the anonymous type \lstinline@[+X] Iterable[X]@, which may be passed to the \lstinline@newType@ type constructor parameter in \lstinline@flatMap@.
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    empty : [A >: Nothing <: Any] List[A]
+    union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A]  .
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-\comment{
-\subsection{Overloaded Types}
-\label{sec:overloaded-types}
+### Type Constructors
 
-More than one values or methods are defined in the same scope with the
-same name, we model
+A type constructor is represented internally much like a polymorphic method type.
+~\lstinline@[$\pm$ $a_1$ >: $L_1$ <: $U_1 \commadots \pm a_n$ >: $L_n$ <: $U_n$] $T$@~ represents a type that is expected by a type constructor parameter (\sref{sec:type-params}) or an abstract type constructor binding (\sref{sec:typedcl}) with the corresponding type parameter clause.
 
-An overloaded type consisting of type alternatives $T_1 \commadots
-T_n (n \geq 2)$ is denoted internally $T_1 \overload \ldots \overload T_n$.
+(@) Consider this fragment of the `Iterable[+X]`{.scala} class:
+    
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    trait Iterable[+X] {
+      def flatMap[newType[+X] <: Iterable[X], S](f: X => newType[S]): newType[S]
+    }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-\example The definitions
-\begin{lstlisting}
-def println: Unit 
-def println(s: String): Unit = $\ldots$ 
-def println(x: Float): Unit = $\ldots$ 
-def println(x: Float, width: Int): Unit = $\ldots$ 
-def println[A](x: A)(tostring: A => String): Unit = $\ldots$
-\end{lstlisting}
-define a single function \code{println} which has an overloaded
-type.
-\begin{lstlisting}
-println:  => Unit $\overload$
-          (String) Unit $\overload$
-          (Float) Unit $\overload$
-          (Float, Int) Unit $\overload$
-          [A] (A) (A => String) Unit
-\end{lstlisting}
+    Conceptually, the type constructor `Iterable` is a name for the 
+    anonymous type `[+X] Iterable[X]`, which may be passed to the 
+    `newType` type constructor parameter in `flatMap`.
 
-\example The definitions
-\begin{lstlisting}
-def f(x: T): T = $\ldots$ 
-val f = 0
-\end{lstlisting}
-define a function \code{f} which has type ~\lstinline@(x: T)T $\overload$ Int@.
-}
 
-\section{Base Types and Member Definitions}
-\label{sec:base-classes-member-defs}
+Base Types and Member Definitions
+---------------------------------
 
 Types of class members depend on the way the members are referenced.
 Central here are three notions, namely:
-\begin{enumerate}
-\item the notion of the set of base types of a type $T$,
-\item the notion of a type $T$ in some class $C$ seen from some 
-      prefix type $S$,
-\item the notion of the set of member bindings of some type $T$.
-\end{enumerate}
+#. the notion of the set of base types of a type $T$,
+#. the notion of a type $T$ in some class $C$ seen from some 
+   prefix type $S$,
+#. the notion of the set of member bindings of some type $T$.
+
+
 These notions are defined mutually recursively as follows.
 
-1. The set of {\em base types} of a type is a set of class types, 
-given as follows.
-\begin{itemize}
-\item
-The base types of a class type $C$ with parents $T_1 \commadots T_n$ are
-$C$ itself, as well as the base types of the compound type
-~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@.
-\item
-The base types of an aliased type are the base types of its alias.
-\item
-The base types of an abstract type are the base types of its upper bound.
-\item
-The base types of a parameterized type 
-~\lstinline@$C$[$T_1 \commadots T_n$]@~ are the base types
-of type $C$, where every occurrence of a type parameter $a_i$ 
-of $C$ has been replaced by the corresponding parameter type $T_i$.
-\item
-The base types of a singleton type \lstinline@$p$.type@ are the base types of
-the type of $p$.
-\item
-The base types of a compound type 
-~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~ 
-are the {\em reduced union} of the base
-classes of all $T_i$'s. This means: 
-Let the multi-set $\SS$ be the multi-set-union of the
-base types of all $T_i$'s.
-If $\SS$ contains several type instances of the same class, say
-~\lstinline@$S^i$#$C$[$T^i_1 \commadots T^i_n$]@~ $(i \in I)$, then
-all those instances 
-are replaced by one of them which conforms to all
-others. It is an error if no such instance exists. It follows that the reduced union, if it exists,
-produces a set of class types, where different types are instances of different classes.
-\item
-The base types of a type selection \lstinline@$S$#$T$@ are
-determined as follows. If $T$ is an alias or abstract type, the
-previous clauses apply. Otherwise, $T$ must be a (possibly
-parameterized) class type, which is defined in some class $B$.  Then
-the base types of \lstinline@$S$#$T$@ are the base types of $T$
-in $B$ seen from the prefix type $S$.
-\item
-The base types of an existential type \lstinline@$T$ forSome {$\,Q\,$}@ are
-all types \lstinline@$S$ forSome {$\,Q\,$}@ where $S$ is a base type of $T$.
-\end{itemize}
+#. The set of _base types_ of a type is a set of class types, 
+   given as follows.
+
+    - The base types of a class type $C$ with parents $T_1 \commadots T_n$ are
+      $C$ itself, as well as the base types of the compound type
+      ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@.
+    - The base types of an aliased type are the base types of its alias.
+    - The base types of an abstract type are the base types of its upper bound.
+    - The base types of a parameterized type 
+      ~\lstinline@$C$[$T_1 \commadots T_n$]@~ are the base types
+      of type $C$, where every occurrence of a type parameter $a_i$ 
+      of $C$ has been replaced by the corresponding parameter type $T_i$.
+    - The base types of a singleton type \lstinline@$p$.type@ are the base types of
+      the type of $p$.
+    - The base types of a compound type 
+      ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~ 
+      are the _reduced union_ of the base
+      classes of all $T_i$'s. This means: 
+      Let the multi-set $\SS$ be the multi-set-union of the
+      base types of all $T_i$'s.
+      If $\SS$ contains several type instances of the same class, say
+      ~\lstinline@$S^i$#$C$[$T^i_1 \commadots T^i_n$]@~ $(i \in I)$, then
+      all those instances 
+      are replaced by one of them which conforms to all
+      others. It is an error if no such instance exists. It follows that the reduced union, if it exists,
+      produces a set of class types, where different types are instances of different classes.
+    - The base types of a type selection \lstinline@$S$#$T$@ are
+      determined as follows. If $T$ is an alias or abstract type, the
+      previous clauses apply. Otherwise, $T$ must be a (possibly
+      parameterized) class type, which is defined in some class $B$.  Then
+      the base types of \lstinline@$S$#$T$@ are the base types of $T$
+      in $B$ seen from the prefix type $S$.
+    - The base types of an existential type \lstinline@$T$ forSome {$\,Q\,$}@ are
+      all types \lstinline@$S$ forSome {$\,Q\,$}@ where $S$ is a base type of $T$.
 
 2. The notion of a type $T$
 {\em in class $C$ seen from some prefix type
@@ -734,18 +727,21 @@ is defined in some other class $D$, and $S$ is some prefix type,
 then we use ``$T$ seen from $S$'' as a shorthand for
 ``$T$ in $D$ seen from $S$''.
 
-3. The {\em member bindings} of a type $T$ are (1) all bindings $d$ such that
+3. The _member bindings_ of a type $T$ are (1) all bindings $d$ such that
 there exists a type instance of some class $C$ among the base types of $T$
 and there exists a definition or declaration $d'$ in $C$
 such that $d$ results from $d'$ by replacing every
 type $T'$ in $d'$ by $T'$ in $C$ seen from $T$, and (2) all bindings
 of the type's refinement (\sref{sec:refinements}), if it has one.
 
-The {\em definition} of a type projection \lstinline@$S$#$t$@ is the member
+The _definition_ of a type projection \lstinline@$S$#$t$@ is the member
 binding $d_t$ of the type $t$ in $S$. In that case, we also say
-that \lstinline@$S$#$t$@ {\em is defined by} $d_t$.
+that \lstinline@$S$#$t$@ _is defined by_ $d_t$.
 share a to
-\section{Relations between types}
+
+
+Relations between types
+-----------------------
 
 We define two relations between types.
 \begin{quote}\begin{tabular}{l@{\gap}l@{\gap}l}
@@ -755,7 +751,7 @@ in all contexts.
 \em Conformance & $T \conforms U$ & Type $T$ conforms to type $U$.
 \end{tabular}\end{quote}
 
-\subsection{Type Equivalence}
+### Type Equivalence
 \label{sec:type-equiv}
 
 Equivalence $(\equiv)$ between types is the smallest congruence\footnote{ A
@@ -801,7 +797,7 @@ another, the result types as well as variances, lower and upper bounds of
 corresponding type parameters are equivalent.
 \end{itemize}
 
-\subsection{Conformance}
+### Conformance
 \label{sec:conformance}
 
 The conformance relation $(\conforms)$ is the smallest 
@@ -875,7 +871,7 @@ $[a'_1 \commadots a'_n ]$, where an $a_i$ or $a'_i$ may include a variance annot
 \end{itemize}
 
 A declaration or definition in some compound type of class type $C$
-{\em subsumes} another
+_subsumes_ another
 declaration of the same name in some compound type or class type $C'$, if one of the following holds.
 \begin{itemize}
 \item
@@ -899,8 +895,7 @@ $L \conforms t \conforms U$.
 \end{itemize}
 
 The $(\conforms)$ relation forms pre-order between types,
-i.e.\ it is transitive and reflexive. {\em
-least upper bounds} and {\em greatest lower bounds} of a set of types
+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.
 
 \paragraph{Note} The least upper bound or greatest lower bound 
@@ -928,10 +923,10 @@ greatest lower of \code{A} and \code{B}. If there are several
 least upper bounds or greatest lower bounds, the Scala compiler is
 free to pick any one of them.
 
-\subsection{Weak Conformance}\label{sec:weakconformance}
+### Weak Conformance
 
 In some situations Scala uses a more genral conformance relation. A 
-type $S$ {\em weakly conforms} 
+type $S$ _weakly conforms_ 
 to a type $T$, written $S \conforms_w
 T$, if $S \conforms T$ or both $S$ and $T$ are primitive number types
 and $S$ precedes $T$ in the following ordering.
@@ -944,29 +939,33 @@ Long $\conforms_w$ Float
 Float $\conforms_w$ Double
 \end{lstlisting}
 
-A {\em weak least upper bound} is a least upper bound with respect to
+A _weak least upper bound_ is a least upper bound with respect to
 weak conformance.
 
-\section{Volatile Types}
-\label{sec:volatile-types}
+
+Volatile Types
+--------------
+
+
 
 Type volatility approximates the possibility that a type parameter or abstract type instance
 of a type does not have any non-null values.  As explained in
 (\sref{sec:paths}), a value member of a volatile type cannot appear in
 a path.
   
-A type is {\em volatile} if it falls into one of four categories:
+A type is _volatile_ if it falls into one of four categories:
 
 A compound type ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~
 is volatile if one of the following two conditions hold.
-\begin{enumerate}
-\item One of $T_2 \commadots T_n$ is a type parameter or abstract type, or
-\item $T_1$ is an abstract type and and either the refinement $R$ 
-  or a type $T_j$ for $j > 1$ contributes an abstract member
-  to the compound type, or
-\item one of $T_1 \commadots T_n$ is a singleton type.
-\end{enumerate}
-Here, a type $S$ {\em contributes an abstract member} to a type $T$ if
+
+#. One of $T_2 \commadots T_n$ is a type parameter or abstract type, or
+#. $T_1$ is an abstract type and and either the refinement $R$ 
+   or a type $T_j$ for $j > 1$ contributes an abstract member
+   to the compound type, or
+#. one of $T_1 \commadots T_n$ is a singleton type.
+
+
+Here, a type $S$ _contributes an abstract member_ to a type $T$ if
 $S$ contains an abstract member that is also a member of $T$.
 A refinement $R$ contributes an abstract member to a type $T$ if $R$
 contains an abstract declaration which is also a member of $T$.
@@ -981,30 +980,30 @@ type of path $p$ is volatile.
 An existential type ~\lstinline@$T$ forSome {$\,Q\,$}@~ is volatile if
 $T$ is volatile.
 
-\section{Type Erasure}
-\label{sec:erasure}
 
-A type is called {\em generic} if it contains type arguments or type variables.
-{\em Type erasure} is a mapping from (possibly generic) types to
+Type Erasure
+------------
+
+A type is called _generic_ if it contains type arguments or type variables.
+_Type erasure_ is a mapping from (possibly generic) types to
 non-generic types. We write $|T|$ for the erasure of type $T$.
 The erasure mapping is defined as follows.
-\begin{itemize}
-\item The erasure of an alias type is the erasure of its right-hand side. %@M
-\item The erasure of an abstract type is the erasure of its upper bound.
-\item The erasure of the parameterized type \lstinline@scala.Array$[T_1]$@ is
+
+- The erasure of an alias type is the erasure of its right-hand side. %@M
+- The erasure of an abstract type is the erasure of its upper bound.
+- The erasure of the parameterized type \lstinline@scala.Array$[T_1]$@ is
  \lstinline@scala.Array$[|T_1|]$@.
- \item The erasure of every other parameterized type $T[T_1 \commadots T_n]$ is $|T|$.
-\item The erasure of a singleton type \lstinline@$p$.type@ is the 
-      erasure of the type of $p$.
-\item The erasure of a type projection \lstinline@$T$#$x$@ is \lstinline@|$T$|#$x$@.
-\item The erasure of a compound type 
-~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@ is the erasure of the intersection dominator of
+- The erasure of every other parameterized type $T[T_1 \commadots T_n]$ is $|T|$.
+- The erasure of a singleton type \lstinline@$p$.type@ is the 
+  erasure of the type of $p$.
+- The erasure of a type projection \lstinline@$T$#$x$@ is \lstinline@|$T$|#$x$@.
+- The erasure of a compound type 
+  ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@ is the erasure of the intersection dominator of
   $T_1 \commadots T_n$.
-\item The erasure of an existential type ~\lstinline@$T$ forSome {$\,Q\,$}@ 
+- The erasure of an existential type ~\lstinline@$T$ forSome {$\,Q\,$}@ 
       is $|T|$.
-\end{itemize}
 
-The {\em intersection dominator} of a list of types $T_1 \commadots
+The _intersection dominator_ of a list of types $T_1 \commadots
 T_n$ is computed as follows.
 Let $T_{i_1} \commadots T_{i_m}$ be the subsequence of types $T_i$  
 which are not supertypes of some other type $T_j$.