converted xml expressions and user defined annotations chapters

6 files changed, 346 insertions, 326 deletions

diff --git a/10-pattern-matching.md b/10-pattern-matching.md
index 1b5cfcb94f..52f22cba62 100644
--- a/10-pattern-matching.md
+++ b/10-pattern-matching.md
@@ -5,23 +5,23 @@ Patterns
 --------
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
-  Pattern         ::=  Pattern1 { `|' Pattern1 }
-  Pattern1        ::=  varid `:' TypePat
-                    |  `_' `:' TypePat
+  Pattern         ::=  Pattern1 { ‘|’ Pattern1 }
+  Pattern1        ::=  varid ‘:’ TypePat
+                    |  ‘_’ ‘:’ TypePat
                     |  Pattern2
-  Pattern2        ::=  varid [`@' Pattern3]
+  Pattern2        ::=  varid [‘@’ Pattern3]
                     |  Pattern3
   Pattern3        ::=  SimplePattern 
                     |  SimplePattern {id [nl] SimplePattern}
-  SimplePattern   ::=  `_'
+  SimplePattern   ::=  ‘_’
                     |  varid
                     |  Literal
                     |  StableId
-                    |  StableId `(' [Patterns] `)'
-                    |  StableId `(' [Patterns `,'] [varid `@'] `_' `*' `)'
-                    |  `(' [Patterns] `)'
+                    |  StableId ‘(’ [Patterns] ‘)’
+                    |  StableId ‘(’ [Patterns ‘,’] [varid ‘@’] ‘_’ ‘*’ ‘)’
+                    |  ‘(’ [Patterns] ‘)’
                     |  XmlPattern
-  Patterns        ::=  Pattern {`,' Patterns}
+  Patterns        ::=  Pattern {‘,’ Patterns}
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A pattern is built from constants, constructors, variables and type
@@ -31,23 +31,23 @@ variables in the pattern to the corresponding components of the value
 (or sequence of values).  The same variable name may not be bound more
 than once in a pattern.
 
-\example Some examples of patterns are:
+(@) Some examples of patterns are:
 
-#.  The pattern `ex: IOException` matches all instances of class
-    `IOException`, binding variable \verb@ex@ to the instance.
-#.  The pattern `Some(x)` matches values of the form `Some($v$)`,
-    binding `x` to the argument value $v$ of the `Some` constructor.
-#.  The pattern `(x, _)` matches pairs of values, binding `x` to
-    the first component of the pair. The second component is matched
-    with a wildcard pattern.
-#.  The pattern `x :: y :: xs`{.scala} matches lists of length $\geq 2$,
-    binding `x` to the list's first element, `y` to the list's
-    second element, and `xs` to the remainder.
-#.  The pattern `1 | 2 | 3` matches the integers between 1 and 3.
+    #.  The pattern `ex: IOException` matches all instances of class
+        `IOException`, binding variable \verb@ex@ to the instance.
+    #.  The pattern `Some(x)` matches values of the form `Some($v$)`,
+        binding `x` to the argument value $v$ of the `Some` constructor.
+    #.  The pattern `(x, _)` matches pairs of values, binding `x` to
+        the first component of the pair. The second component is matched
+        with a wildcard pattern.
+    #.  The pattern `x :: y :: xs`{.scala} matches lists of length $\geq 2$,
+        binding `x` to the list's first element, `y` to the list's
+        second element, and `xs` to the remainder.
+    #.  The pattern `1 | 2 | 3` matches the integers between 1 and 3.
 
-Pattern matching is always done in a context which supplies an
-expected type of the pattern. We distinguish the following kinds of
-patterns.
+    Pattern matching is always done in a context which supplies an
+    expected type of the pattern. We distinguish the following kinds of
+    patterns.
 
 ### Variable Patterns
 
@@ -213,26 +213,26 @@ result type is of the form `Option[$S$]`, where $S$ is a subtype of
 `Seq[$T$]` for some element type $T$. 
 This case is further discussed [here](#pattern-seqs).
 
-\example  The `Predef` object contains a definition of an
-extractor object `Pair`:
+(@) The `Predef` object contains a definition of an
+    extractor object `Pair`:
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
-object Pair {
-  def apply[A, B](x: A, y: B) = Tuple2(x, y)
-  def unapply[A, B](x: Tuple2[A, B]): Option[Tuple2[A, B]] = Some(x)
-}
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    object Pair {
+      def apply[A, B](x: A, y: B) = Tuple2(x, y)
+      def unapply[A, B](x: Tuple2[A, B]): Option[Tuple2[A, B]] = Some(x)
+    }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-This means that the name `Pair` can be used in place of `Tuple2` for tuple 
-formation as well as for deconstruction of tuples in patterns.
-Hence, the following is possible:
+    This means that the name `Pair` can be used in place of `Tuple2` for tuple 
+    formation as well as for deconstruction of tuples in patterns.
+    Hence, the following is possible:
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
-val x = (1, 2)
-val y = x match {
-  case Pair(i, s) => Pair(s + i, i * i)
-}
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    val x = (1, 2)
+    val y = x match {
+      case Pair(i, s) => Pair(s + i, i * i)
+    }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 ### Pattern Sequences
 
diff --git a/11-top-level-definitions.md b/11-top-level-definitions.md
index 6d5d17246c..02c7db7bb9 100644
--- a/11-top-level-definitions.md
+++ b/11-top-level-definitions.md
@@ -1,75 +1,81 @@
 Top-Level Definitions
 =====================
 
-\section{Compilation Units}
-
-\syntax\begin{lstlisting}
-  CompilationUnit  ::=  {`package' QualId semi} TopStatSeq
-  TopStatSeq       ::=  TopStat {semi TopStat}
-  TopStat          ::=  {Annotation} {Modifier} TmplDef
-                     |  Import
-                     |  Packaging
-                     |  PackageObject
-                     |
-  QualId           ::=  id {`.' id}
-\end{lstlisting}
+Compilation Units
+-----------------
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+CompilationUnit  ::=  {‘package’ QualId semi} TopStatSeq
+TopStatSeq       ::=  TopStat {semi TopStat}
+TopStat          ::=  {Annotation} {Modifier} TmplDef
+                   |  Import
+                   |  Packaging
+                   |  PackageObject
+                   |
+QualId           ::=  id {‘.’ id}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A compilation unit consists of a sequence of packagings, import
 clauses, and class and object definitions, which may be preceded by a
 package clause.
 
 A compilation unit 
-\begin{lstlisting}
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
 package $p_1$;
 $\ldots$
 package $p_n$;
-$\stats$
-\end{lstlisting}
+$\mathit{stats}$
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 starting with one or more package
 clauses is equivalent to a compilation unit consisting of the
 packaging 
-\begin{lstlisting}
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
 package $p_1$ { $\ldots$
   package $p_n$ {
-    $\stats$
+    $\mathit{stats}$
   } $\ldots$
 }
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Implicitly imported into every compilation unit are, in that order :
-the package \code{java.lang}, the package \code{scala}, and the object
-\code{scala.Predef} (\sref{cls:predef}). Members of a later import in
+the package `java.lang`, the package `scala`, and the object
+[`scala.Predef`](#the-predef-object). Members of a later import in
 that order hide members of an earlier import.
 
-\section{Packagings}\label{sec:packagings}
 
-\syntax\begin{lstlisting}
-  Packaging       ::=  `package' QualId [nl] `{' TopStatSeq `}'
-\end{lstlisting}
+Packagings
+----------
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+Packaging       ::=  ‘package’ QualId [nl] ‘{’ TopStatSeq ‘}’
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A package is a special object which defines a set of member classes,
 objects and packages.  Unlike other objects, packages are not introduced
 by a definition.  Instead, the set of members of a package is determined by
 packagings.
 
-A packaging ~\lstinline@package $p$ { $\ds$ }@~ injects all
-definitions in $\ds$ as members into the package whose qualified name
-is $p$. Members of a package are called {\em top-level} definitions.
-If a definition in $\ds$ is labeled \code{private}, it is
+A packaging `package $p$ { $\mathit{ds}$ }`{.scala} injects all
+definitions in $\mathit{ds}$ as members into the package whose qualified name
+is $p$. Members of a package are called _top-level_ definitions.
+If a definition in $\mathit{ds}$ is labeled `private`{.scala}, it is
 visible only for other members in the package.
 
 Inside the packaging, all members of package $p$ are visible under their
 simple names. However this rule does not extend to members of enclosing
 packages of $p$ that are designated by a prefix of the path $p$.
 
-\example Given the packaging
-\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
 package org.net.prj {
   ...
 }
-\end{lstlisting}
-all members of package \lstinline@org.net.prj@ are visible under their
-simple names, but members of packages \code{org} or \code{org.net} require
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+all members of package `org.net.prj` are visible under their
+simple names, but members of packages `org` or `org.net` require
 explicit qualification or imports.
 
 Selections $p$.$m$ from $p$ as well as imports from $p$
@@ -82,17 +88,18 @@ into a special empty package. That package cannot be named and
 therefore cannot be imported. However, members of the empty package
 are visible to each other without qualification.
 
-\section{Package Objects}
-\label{sec:pkg-obj}
 
-\syntax\begin{lstlisting}
-  PackageObject   ::=  `package' `object' ObjectDef
-\end{lstlisting}
+Package Objects
+---------------
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+PackageObject   ::=  ‘package’ ‘object’ ObjectDef
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A package object ~\lstinline@package object $p$ extends $t$@~ adds the
+A package object `package object $p$ extends $t$` adds the
 members of template $t$ to the package $p$. There can be only one
 package object per package. The standard naming convention is to place
-the definition above in a file named \lstinline@package.scala@ that's
+the definition above in a file named `package.scala` that's
 located in the directory corresponding to package $p$.
 
 The package object should not define a member with the same name as
@@ -101,77 +108,88 @@ there is a name conflict, the behavior of the program is currently
 undefined. It is expected that this restriction will be lifted in a
 future version of Scala.
 
-\section{Package References}
 
-\syntax\begin{lstlisting}
-  QualId           ::=  id {`.' id}
-\end{lstlisting}
+Package References
+------------------
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+QualId           ::=  id {‘.’ id}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 A reference to a package takes the form of a qualified identifier.
 Like all other references, package references are relative. That is, 
 a package reference starting in a name $p$ will be looked up in the
 closest enclosing scope that defines a member named $p$.
 
-The special predefined name \lstinline@_root_@  refers to the
+The special predefined name `_root_` refers to the
 outermost root package which contains all top-level packages.  
 
-\example\label{ex:package-ids}
-Consider the following program:
-\begin{lstlisting}
-package b {
-  class B 
-}
+(@package-ids) Consider the following program:
 
-package a.b {
-  class A {
-    val x = new _root_.b.B
-  }
-}
-\end{lstlisting}  
-Here, the reference \code{_root_.b.B} refers to class \code{B} in the
-toplevel package \code{b}. If the \code{_root_} prefix had been
-omitted, the name \code{b} would instead resolve to the package
-\code{a.b}, and, provided that package does not also
-contain a class \code{B}, a compiler-time error would result.
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    package b {
+      class B 
+    }
+
+    package a.b {
+      class A {
+        val x = new _root_.b.B
+      }
+    }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-\section{Programs}
+    Here, the reference `_root_.b.B` refers to class `B` in the
+    toplevel package `b`. If the `_root_` prefix had been
+    omitted, the name `b` would instead resolve to the package
+    `a.b`, and, provided that package does not also
+    contain a class `B`, a compiler-time error would result.
 
-A {\em program} is a top-level object that has a member method
-\code{main} of type ~\lstinline@(Array[String])Unit@. Programs can be
+
+Programs
+--------
+
+A _program_ is a top-level object that has a member method
+_main_ of type `(Array[String])Unit`. Programs can be
 executed from a command shell. The program's command arguments are are
-passed to the \code{main} method as a parameter of type
-\code{Array[String]}.
+passed to the `main` method as a parameter of type
+`Array[String]`.
 
-The \code{main} method of a program can be directly defined in the
+The `main` method of a program can be directly defined in the
 object, or it can be inherited. The scala library defines a class
-\code{scala.Application} that defines an empty inherited \code{main} method.
+`scala.Application` that defines an empty inherited `main` method.
 An objects $m$ inheriting from this class is thus a program, 
 which executes the initializaton code of the object $m$.
 
-\example The following example will create a hello world program by defining
-a method \code{main} in module \code{test.HelloWorld}.
-\begin{lstlisting}
-package test
-object HelloWord {
-  def main(args: Array[String]) { println("hello world") }
-}
-\end{lstlisting}
-
-This program can be started by the command
-\begin{lstlisting}
-scala test.HelloWorld
-\end{lstlisting}
-In a Java environment, the command
-\begin{lstlisting}
-java test.HelloWorld
-\end{lstlisting}
-would work as well. 
-
-\code{HelloWorld} can also be defined without a \code{main} method 
-by inheriting from \code{Application} instead:
-\begin{lstlisting}
-package test 
-object HelloWord extends Application {
-  println("hello world")
-}
-\end{lstlisting}
+(@) The following example will create a hello world program by defining
+    a method `main` in module `test.HelloWorld`.
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    package test
+    object HelloWord {
+      def main(args: Array[String]) { println("hello world") }
+    }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    This program can be started by the command
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    scala test.HelloWorld
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    In a Java environment, the command
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    java test.HelloWorld
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    would work as well. 
+
+    `HelloWorld` can also be defined without a `main` method 
+    by inheriting from `Application` instead:
+
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+    package test 
+    object HelloWord extends Application {
+      println("hello world")
+    }
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/12-xml-expressions-and-patterns.md b/12-xml-expressions-and-patterns.md
index 2f6756b05f..631d244575 100644
--- a/12-xml-expressions-and-patterns.md
+++ b/12-xml-expressions-and-patterns.md
@@ -1,21 +1,23 @@
 XML Expressions and Patterns
 ============================
 
-{\bf By Burak Emir}\bigskip\bigskip
-
+__By Burak Emir__ \
 
 This chapter describes the syntactic structure of XML expressions and patterns.
 It follows as closely as possible the XML 1.0 specification \cite{w3c:xml},
 changes being mandated by the possibility of embedding Scala code fragments.
 
-\section{XML expressions}
+XML expressions
+---------------
+
 XML expressions are expressions generated by the following production, where the 
 opening bracket `<' of the first element must be in a position to start the lexical
 [XML mode](#xml-mode).
 
-\syntax\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 XmlExpr ::= XmlContent {Element}
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 Well-formedness constraints of the XML specification apply, which
 means for instance that start tags and end tags must match, and
 attributes may only be defined once, with the exception of constraints
@@ -28,14 +30,14 @@ are changed. Scala does not support declarations, CDATA
 sections or processing instructions. Entity references are not
 resolved at runtime.
 
-\syntax\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 Element       ::=    EmptyElemTag
                 |    STag Content ETag                                       
 
-EmptyElemTag  ::=    `<' Name {S Attribute} [S] `/>'                         
+EmptyElemTag  ::=    ‘<’ Name {S Attribute} [S] ‘/>’                         
 
-STag          ::=    `<' Name {S Attribute} [S] `>'                          
-ETag          ::=    `</' Name [S] '>'                                        
+STag          ::=    ‘<’ Name {S Attribute} [S] ‘>’                          
+ETag          ::=    ‘</’ Name [S] ‘>’                                        
 Content       ::=    [CharData] {Content1 [CharData]}
 Content1      ::=    XmlContent
                 |    Reference
@@ -44,14 +46,14 @@ XmlContent    ::=    Element
                 |    CDSect
                 |    PI
                 |    Comment
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 
 If an XML expression is a single element, its value is a runtime
 representation of an XML node (an instance of a subclass of 
-\lstinline@scala.xml.Node@). If the XML expression consists of more
+`scala.xml.Node`). If the XML expression consists of more
 than one element, then its value is a runtime representation of a
 sequence of XML nodes (an instance of a subclass of 
-\lstinline@scala.Seq[scala.xml.Node]@).
+`scala.Seq[scala.xml.Node]`).
 
 If an XML expression is an entity reference, CDATA section, processing 
 instructions or a comments, it is represented by an instance of the 
@@ -59,61 +61,63 @@ corresponding Scala runtime class.
 
 By default, beginning and trailing whitespace in element content is removed, 
 and consecutive occurrences of whitespace are replaced by a single space
-character \U{0020}. This behavior can be changed to preserve all whitespace
+character \\u0020. This behavior can be changed to preserve all whitespace
 with a compiler option.
 
-\syntax\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 Attribute  ::=    Name Eq AttValue                                    
 
-AttValue      ::=    `"' {CharQ | CharRef} `"'
-                |    `'' {CharA | CharRef} `''
+AttValue      ::=    ‘"’ {CharQ | CharRef} ‘"’
+                |    ‘'’ {CharA | CharRef} ‘'’
                 |    ScalaExpr
 
 ScalaExpr     ::=    Block
 
 CharData      ::=   { CharNoRef } $\mbox{\rm\em without}$ {CharNoRef}`{'CharB {CharNoRef} 
                                   $\mbox{\rm\em and without}$ {CharNoRef}`]]>'{CharNoRef}
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 XML expressions may contain Scala expressions as attribute values or
 within nodes. In the latter case, these are embedded using a single opening 
-brace `\{' and ended by a closing brace `\}'. To express a single opening braces 
-within XML text as generated by CharData, it must be doubled. Thus, `\{\{'
-represents the XML text `\{' and does not introduce an embedded Scala
+brace ‘{’ and ended by a closing brace ‘}’. To express a single opening braces 
+within XML text as generated by CharData, it must be doubled. Thus, ‘{{’
+represents the XML text ‘{’ and does not introduce an embedded Scala
 expression.
 
-\syntax\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 BaseChar, Char, Comment, CombiningChar, Ideographic, NameChar, S, Reference
-              ::=  $\mbox{\rm\em ``as in W3C XML''}$
+              ::=  $\mbox{\rm\em “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 $\mbox{\rm\em without}$ ‘<’ | ‘&’
+CharQ         ::=  Char1 $\mbox{\rm\em without}$ ‘"’
+CharA         ::=  Char1 $\mbox{\rm\em without}$ ‘'’
+CharB         ::=  Char1 $\mbox{\rm\em without}$ ‘{’
 
 Name          ::=  XNameStart {NameChar}
 
-XNameStart    ::= `_' | BaseChar | Ideographic 
-                 $\mbox{\rm\em (as in W3C XML, but without }$ `:'
+XNameStart    ::= ‘_’ | BaseChar | Ideographic 
+                 $\mbox{\rm\em (as in W3C XML, but without }$ ‘:’
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+XML patterns
+------------
 
-\end{lstlisting}
-\section{XML patterns}\label{sec:xml-pats}
 XML patterns are patterns generated by the following production, where
-the opening bracket `<' of the element patterns must be in a position
+the opening bracket ‘<’ of the element patterns must be in a position
 to start the lexical [XML mode](#xml-mode).
 
-\syntax\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 XmlPattern  ::= ElementPattern 
-\end{lstlisting}%{ElementPattern}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 Well-formedness constraints of the XML specification apply.
 
-An XML pattern has to be a single element pattern. It %expects the type of , and 
+An XML pattern has to be a single element pattern. It
 matches exactly those runtime
 representations of an XML tree
-that have the same structure as described by the pattern. %If an XML pattern 
-%consists of more than one element, then it expects the type of sequences
-%of runtime representations of XML trees, and matches every sequence whose 
-%elements match the sequence described by the pattern.
-XML patterns may contain Scala patterns(\sref{sec:pattern-match}).
+that have the same structure as described by the pattern.
+XML patterns may contain [Scala patterns](#pattern-matching-expressions).
 
 Whitespace is treated the same way as in XML expressions. Patterns 
 that are entity references, CDATA sections, processing 
@@ -122,16 +126,16 @@ the same.
 
 By default, beginning and trailing whitespace in element content is removed, 
 and consecutive occurrences of whitespace are replaced by a single space
-character \U{0020}. This behavior can be changed to preserve all whitespace
+character \\u0020. This behavior can be changed to preserve all whitespace
 with a compiler option.
 
-\syntax\begin{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
 ElemPattern   ::=    EmptyElemTagP
                 |    STagP ContentP ETagP                                    
 
-EmptyElemTagP ::=    `<' Name [S] `/>'
-STagP         ::=    `<' Name [S] `>'                          
-ETagP         ::=    `</' Name [S]`>'                                        
+EmptyElemTagP ::=    ‘<’  Name [S] ‘/>’
+STagP         ::=    ‘<’  Name [S] ‘>’                          
+ETagP         ::=    ‘</’ Name [S] ‘>’                                        
 ContentP      ::=    [CharData] {(ElemPattern|ScalaPatterns) [CharData]}
 ContentP1     ::=    ElemPattern
                 |    Reference
@@ -139,6 +143,6 @@ ContentP1     ::=    ElemPattern
                 |    PI
                 |    Comment
                 |    ScalaPatterns
-ScalaPatterns ::=    `{' Patterns `}'
-\end{lstlisting}
+ScalaPatterns ::=    ‘{’ Patterns ‘}’
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/13-user-defined-annotations.md b/13-user-defined-annotations.md
index ec83e9fa4f..17af3ca541 100644
--- a/13-user-defined-annotations.md
+++ b/13-user-defined-annotations.md
@@ -1,16 +1,15 @@
 User-Defined Annotations
 ========================
 
-\syntax\begin{lstlisting}
-  Annotation       ::=  `@' SimpleType {ArgumentExprs}
-  ConstrAnnotation ::=  `@' SimpleType ArgumentExprs
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.grammar}
+  Annotation       ::=  ‘@’ SimpleType {ArgumentExprs}
+  ConstrAnnotation ::=  ‘@’ SimpleType ArgumentExprs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 User-defined annotations associate meta-information with definitions.
-A simple annotation has the form \lstinline^@$c$^ or
-\lstinline^@$c(a_1 \commadots a_n)$^.  
+A simple annotation has the form `@$c$` or `@$c(a_1 , \ldots , a_n)$`.
 Here, $c$ is a constructor of a class $C$, which must conform
-to the class \lstinline@scala.Annotation@. 
+to the class `scala.Annotation`. 
 
 Annotations may apply to definitions or declarations, types, or
 expressions.  An annotation of a definition or declaration appears in
@@ -21,151 +20,149 @@ may apply to an entity. The order in which these annotations are given
 does not matter.
 
 Examples:
-\begin{lstlisting}
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
 @serializable class C { ... }         // A class annotation.
 @transient @volatile var m: Int       // A variable annotation
 String @local                         // A type annotation
 (e: @unchecked) match { ... }         // An expression annotation
-\end{lstlisting}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The meaning of annotation clauses is implementation-dependent. On the
-Java platform, the following annotations have a standard meaning.\bigskip
-
-\lstinline^@transient^
-\begin{quote}
-Marks a field to be non-persistent; this is
-equivalent to the \lstinline^transient^
-modifier in Java.
-\end{quote}
-
-\lstinline^@volatile^
-\begin{quote}Marks a field which can change its value
-outside the control of the program; this
-is equivalent to the \lstinline^volatile^
-modifier in Java.
-\end{quote}
-
-\lstinline^@serializable^
-\begin{quote}Marks a class to be serializable; this is
-equivalent to inheriting from the 
-\lstinline^java.io.Serializable^ interface
-in Java.
-\end{quote}
-
-\lstinline^@SerialVersionUID(<longlit>)^
-\begin{quote}Attaches a serial version identifier (a
-\lstinline^long^ constant) to a class.
-This is equivalent to a the following field
-definition in Java:
-\begin{lstlisting}[language=Java]
-  private final static SerialVersionUID = <longlit> 
-\end{lstlisting}
-\end{quote}
-
-\lstinline^@throws(<classlit>)^
-\begin{quote}
-A Java compiler checks that a program contains handlers for checked exceptions
-by analyzing which checked exceptions can result from execution of a method or
-constructor. For each checked exception which is a possible result, the \code{throws}
-clause for the method or constructor must mention the class of that exception
-or one of the superclasses of the class of that exception.
-\end{quote}
-
-\lstinline^@deprecated(<stringlit>)^
-\begin{quote} Marks a definition as deprecated. Accesses to the
-  defined entity will then cause a deprecated warning mentioning the
-  message \code{<stringlit>} to be issued from the compiler.  Deprecated
-  warnings are suppressed in code that belongs itself to a definition
-  that is labeled deprecated.
-\end{quote}
-
-\lstinline^@scala.reflect.BeanProperty^
-\begin{quote}
-When prefixed to a definition of some variable \code{X}, this
-annotation causes getter and setter methods \code{getX}, \code{setX}
-in the Java bean style to be added in the class containing the
-variable. The first letter of the variable appears capitalized after
-the \code{get} or \code{set}. When the annotation is added to the
-definition of an immutable value definition \code{X}, only a getter is
-generated. The construction of these methods is part of
-code-generation; therefore, these methods become visible only once a
-classfile for the containing class is generated.
-\end{quote}
-
-\lstinline^@scala.reflect.BooleanBeanProperty^
-\begin{quote}
-This annotation is equivalent to \code{scala.reflect.BeanProperty}, but
-the generated getter method is named \code{isX} instead of \code{getX}.
-\end{quote}
-
-\lstinline^@unchecked^
-\begin{quote}
-When applied to the selector of a \lstinline@match@ expression,
-this attribute suppresses any warnings about non-exhaustive pattern
-matches which would otherwise be emitted. For instance, no warnings
-would be produced for the method definition below.
-\begin{lstlisting}
-def f(x: Option[Int]) = (x: @unchecked) match {
-  case Some(y) => y
-}
-\end{lstlisting}
-Without the \lstinline^@unchecked^ annotation, a Scala compiler could
-infer that the pattern match is non-exhaustive, and could produce a
-warning because \lstinline@Option@ is a \lstinline@sealed@ class.
-\end{quote}
-
-\lstinline^@uncheckedStable^
-\begin{quote}
-When applied a value declaration or definition, it allows the defined
-value to appear in a path, even if its type is volatile (\sref{volatile-types}).
-For instance, the following member definitions are legal:
-\begin{lstlisting}
-type A { type T }
-type B 
-@uncheckedStable val x: A with B // volatile type 
-val y: x.T                       // OK since `x' is still a path
-\end{lstlisting}
-Without the \lstinline^@uncheckedStable^ annotation, the designator \code{x}
-would not be a path since its type \code{A with B} is volatile. Hence,
-the reference \code{x.T} would be malformed. 
-
-When applied to value declarations or definitions that have non-volatile types, 
-the annotation has no effect. 
-\end{quote}
-
-\lstinline^@specialized^
-\begin{quote}
-When applied to the definition of a type parameter, this annotation causes the compiler
-to generate specialized definitions for primitive types. An optional list of primitive
-types may be given, in which case specialization takes into account only those types.
-For instance, the following code would generate specialized traits for \lstinline@Unit@, 
-\lstinline@Int@ and \lstinline@Double@
-\begin{lstlisting}
-trait Function0[@specialized(Unit, Int, Double) T] {
-  def apply: T
-}
-\end{lstlisting}
-Whenever the static type of an expression matches a specialized variant of a definition,
-the compiler will instead use the specialized version. See \cite{spec-sid} for more details
-of the implementation.
-\end{quote}
+Java platform, the following annotations have a standard meaning.
+
+  * `@transient` \
+  	Marks a field to be non-persistent; this is
+	equivalent to the `transient`
+	modifier in Java.
+
+
+  * `@volatile` \
+	Marks a field which can change its value
+	outside the control of the program; this
+	is equivalent to the `volatile`
+	modifier in Java.
+
+  * `@serializable` \
+    Marks a class to be serializable; this is
+    equivalent to inheriting from the 
+    `java.io.Serializable` interface
+    in Java.
+
+
+  * `@SerialVersionUID(<longlit>)` \
+	Attaches a serial version identifier (a
+	`long` constant) to a class.
+	This is equivalent to a the following field
+	definition in Java:
+
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+	private final static SerialVersionUID = <longlit> 
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+  * `@throws(<classlit>)` \
+	A Java compiler checks that a program contains handlers for checked exceptions
+	by analyzing which checked exceptions can result from execution of a method or
+	constructor. For each checked exception which is a possible result, the 
+	`throws`
+	clause for the method or constructor must mention the class of that exception
+	or one of the superclasses of the class of that exception.
+
+  * `@deprecated(<stringlit>)` \
+	Marks a definition as deprecated. Accesses to the
+	defined entity will then cause a deprecated warning mentioning the
+	message `<stringlit>` to be issued from the compiler.  Deprecated
+	warnings are suppressed in code that belongs itself to a definition
+	that is labeled deprecated.
+
+  * `@scala.reflect.BeanProperty` \
+	When prefixed to a definition of some variable `X`, this
+	annotation causes getter and setter methods `getX`, `setX`
+	in the Java bean style to be added in the class containing the
+	variable. The first letter of the variable appears capitalized after
+	the `get` or `set`. When the annotation is added to the
+	definition of an immutable value definition `X`, only a getter is
+	generated. The construction of these methods is part of
+	code-generation; therefore, these methods become visible only once a
+	classfile for the containing class is generated.
+
+  * `@scala.reflect.BooleanBeanProperty` \
+	This annotation is equivalent to `scala.reflect.BeanProperty`, but
+	the generated getter method is named `isX` instead of `getX`.
+
+  * `@unchecked` \
+	When applied to the selector of a \lstinline@match@ expression,
+	this attribute suppresses any warnings about non-exhaustive pattern
+	matches which would otherwise be emitted. For instance, no warnings
+	would be produced for the method definition below.
+
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+	def f(x: Option[Int]) = (x: @unchecked) match {
+	  case Some(y) => y
+	}
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+	Without the `@unchecked` annotation, a Scala compiler could
+	infer that the pattern match is non-exhaustive, and could produce a
+	warning because `Option` is a `sealed` class.
+
+  * `@uncheckedStable` \
+	When applied a value declaration or definition, it allows the defined
+	value to appear in a path, even if its type is [volatile](#volatile-types).
+	For instance, the following member definitions are legal:
+
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+	type A { type T }
+	type B 
+	@uncheckedStable val x: A with B // volatile type 
+	val y: x.T                       // OK since `x' is still a path
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+	Without the `@uncheckedStable` annotation, the designator `x`
+	would not be a path since its type `A with B` is volatile. Hence,
+	the reference `x.T` would be malformed. 
+
+	When applied to value declarations or definitions that have non-volatile 
+	types, the annotation has no effect. 
+
+
+  * `@specialized` \
+	When applied to the definition of a type parameter, this annotation causes 
+	the compiler
+	to generate specialized definitions for primitive types. An optional list of
+	primitive
+	types may be given, in which case specialization takes into account only 
+	those types.
+	For instance, the following code would generate specialized traits for
+	`Unit`, `Int` and `Double`
+
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.scala}
+	trait Function0[@specialized(Unit, Int, Double) T] {
+	  def apply: T
+	}
+	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+	Whenever the static type of an expression matches a specialized variant of 
+	a definition,
+	the compiler will instead use the specialized version. See \cite{spec-sid} 
+	for more details of the implementation.
 
 
 Other annotations may be interpreted by platform- or
-application-dependent tools. Class \code{scala.Annotation} has two
+application-dependent tools. Class `scala.Annotation` has two
 sub-traits which are used to indicate how these annotations are
 retained. Instances of an annotation class inheriting from trait
-\code{scala.ClassfileAnnotation} will be stored in the generated class
+`scala.ClassfileAnnotation` will be stored in the generated class
 files. Instances of an annotation class inheriting from trait
-\code{scala.StaticAnnotation} will be visible to the Scala type-checker
+`scala.StaticAnnotation` will be visible to the Scala type-checker
 in every compilation unit where the annotated symbol is accessed. An
-annotation class can inherit from both \code{scala.ClassfileAnnotation}
-and \code{scala.StaticAnnotation}. If an annotation class inherits from
-neither \code{scala.ClassfileAnnotation} nor
-\code{scala.StaticAnnotation}, its instances are visible only locally
+annotation class can inherit from both `scala.ClassfileAnnotation`
+and `scala.StaticAnnotation`. If an annotation class inherits from
+neither `scala.ClassfileAnnotation` nor
+`scala.StaticAnnotation`, its instances are visible only locally
 during the compilation run that analyzes them.
 
-Classes inheriting from \code{scala.ClassfileAnnotation} may be
+Classes inheriting from `scala.ClassfileAnnotation` may be
 subject to further restrictions in order to assure that they can be
 mapped to the host environment. In particular, on both the Java and
 the .NET platforms, such classes must be toplevel; i.e.\ they may not
diff --git a/build.sh b/build.sh
index 59d0a8ca77..51f8d45586 100755
--- a/build.sh
+++ b/build.sh
@@ -10,15 +10,16 @@ cat 01-title.md \
     08-expressions.md \
     09-implicit-parameters-and-views.md \
     10-pattern-matching.md \
+    11-top-level-definitions.md \
+    12-xml-expressions-and-patterns.md \
+    13-user-defined-annotations.md \
     15-scala-syntax-summary.md \
     16-references.md > build/ScalaReference.md
 
+#    14-the-scala-standard-library.md \
+
 
 
-#    11-top-level-definitions.md \
-#    12-xml-expressions-and-patterns.md \
-#    13-user-defined-annotations.md \
-#    14-the-scala-standard-library.md \
 
 
 pandoc -f markdown \
diff --git a/resources/style.css b/resources/style.css
index e57e8a4714..54b66f43fe 100644
--- a/resources/style.css
+++ b/resources/style.css
@@ -48,14 +48,14 @@ ol[type="1"] {
 	padding: 0;
 }
 
-ol[type="1"] li {
+ol[type="1"] > li {
 	margin-top: 1em;
 	padding: 1em;
 	background-color: #E5ECF9;
 	border: 1px dashed black;
 }
 
-ol[type="1"] li:before {
+ol[type="1"] > li:before {
 	content: "Example ";
 }