Spec tweak. Fix semicolon escape-grammar where it doesn't match the rest.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \usepackage[T1]{fontenc}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
@@ skipping 2319 matching lines @@
 %By current rules, this is illegal. Make sure we preserve this.
 
 
 %\subsection{Interface Injection}
 %\LMLabel{interfaceInjection}
 
 %An {\em interface injection declaration} causes a pre-existing class $S$ to be considered a subinterface of another interface $I$. It is a static type warning if $S$ is not a structural subtype of $I$. However, the subinterface relations implied by the interface injection declaration are considered to hold by both the typechecker and the runtime, regardless.
 
 %\begin{grammar}
 %classInterfaceInjection:
-      %class qualified typeParameters? interfaces '{\escapegrammar ;}'
+      %class qualified typeParameters? interfaces `{\escapegrammar ;}'
       %  .
 
 
 %interfaceInterfaceInjection:
-      %interface qualified typeParameters? superinterfaces '{\escapegrammar ;}'
+      %interface qualified typeParameters? superinterfaces `{\escapegrammar ;}'
     %.
 %\end{grammar}
 
 %\rationale{Since subinterface relations can be tested dynamically via \IS{}, interface injection is not just a directive to the static checker. The dynamic relations implied must  hold regardless of whether a static typecheck has succeeded, or has been performed at all. This makes sense from the perspective of preserving programmer intent. The injection describes a nominal type relation that the programmer wishes to hold. Just as a supertype mentioned within a class declaration is considered a supertype even though type errors might arise among (say) overridden and overriding methods, so it must be that the relation implied by an injection holds regardless of type errors.
 %In addition, this decision helps to produce meaningful and localized error messages. Any errors are reported at the point of injection rather than at program points that rely on the relation (a well known problem with structural subtyping in OO systems).
 %}
 
 %\Q{When does an interface injection take effect? When the containing library is loaded?
 %What is the scope of such a declaration? Is it global, or only in the scope of the containing library? The scope of such a declaration is global.
 %An injection must be at top level. Who has the right to inject an interface $I$ into another class $C$? Anybody? But since this affects dynamic behavior, is this a weird security issue?
@@ skipping 3247 matching lines @@
 
 \subsection{Local Variable Declaration}
 \LMLabel{localVariableDeclaration}
 
 
 \LMHash{}
 A {\em variable declaration statement }declares a new local variable.
 
  \begin{grammar}
 {\bf localVariableDeclaration:}
-    initializedVariableDeclaration {\escapegrammar';'}
+    initializedVariableDeclaration `{\escapegrammar ;}'
   .
  \end{grammar}
 
 \LMHash{}
  Executing a variable declaration statement of one of the forms  \VAR{} $v = e;$, $T$ $v = e; $, \CONST{}  $v = e;$, \CONST{} $T$ $v = e;$, \FINAL{}  $v = e;$ or \FINAL{} $T$ $v = e;$ proceeds as follows:
 
 \LMHash{}
  The expression $e$ is evaluated to an object $o$. Then, the variable $v$ is set to $o$.
 
 \LMHash{}
@@ skipping 1727 matching lines @@
 
 {\bf typeAlias:}
         metadata  \TYPEDEF{} typeAliasBody
         .
 
 {\bf typeAliasBody:}
         functionTypeAlias
         .
 
 {\bf functionTypeAlias:}
-       functionPrefix  typeParameters? formalParameterList '{\escapegrammar ;}'
+       functionPrefix  typeParameters? formalParameterList `{\escapegrammar ;}'
     .
 
     {\bf functionPrefix:}
     returnType? identifier
     .
 
  \end{grammar}
 
 \LMHash{}
  The effect of a type alias of the form  \code{\TYPEDEF{} $T$ $id (T_1$ $p_1, \ldots, T_n$ $p_n, [T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}])$} declared in a library $L$ is is to introduce the name $id$ into the scope of $L$, bound to the function type $(T_1, \ldots, T_n, [T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}])  \rightarrow T$.  The effect of a type alias of the form   \code{\TYPEDEF{} $T$ $id (T_1$ $p_1, \ldots, T_n$ $p_n, \{T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}\})$} declared in a library $L$ is is to introduce the name $id$ into the scope of $L$, bound to the function type $(T_1, \ldots, T_n, \{T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}\})  \rightarrow T$. . In either case, iff no return type is specified, it is taken to be \DYNAMIC{}. Likewise, if a type annotation is omitted on a formal parameter, it is taken to be \DYNAMIC{}.
@@ skipping 668 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------