Spec: Make fontenc understand that greater than is not an inverse question mark.

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  \\
 {4th edition draft}\\
 {\large Version 1.14}}
 
 % For information about Location Markers (and in particular the
 % commands \LMHash and \LMLabel), see the long comment at the
 % end of this file.
 
 \begin{document}
@@ skipping 189 matching lines @@
 \LMHash{}
 If a  declaration $d$ named $n$ is in the namespace induced by a scope $S$, then $d$ {\em hides} any declaration named $n$ that is available in the lexically enclosing scope of $S$.
 
 \commentary {
 A consequence of these rules is that it is possible to hide a type with a method or variable.
 Naming conventions usually prevent such abuses. Nevertheless,the following program is legal:
 }
 
 \begin{dartCode}
 \CLASS{} HighlyStrung \{
-  String() $=>$ "?";
+  String() => "?";
 \}
 \end{dartCode}
 
 \LMHash{}
 Names may be introduced into a scope by  declarations within the scope or  by other mechanisms such as imports or inheritance.
 
 \rationale{
 The interaction of lexical scoping and inheritance is a subtle one.  Ultimately, the question is whether lexical scoping takes precedence over inheritance or vice versa. Dart chooses the former.
 
 Allowing inherited names to take precedence over locally declared names can create unexpected situations as code evolves. Specifically, the behavior of code in a subclass can change without warning  if a new name is introduced in a superclass.  Consider:
 }
 
 \begin{dartCode}
 \LIBRARY{} L1;
 \CLASS{} S \{\}
 
 \LIBRARY{} L2;
 \IMPORT{} `L1.dart';
-foo() =$>$ 42;
-\CLASS{} C \EXTENDS{} S\{ bar() =$>$ foo();\}
+foo() => 42;
+\CLASS{} C \EXTENDS{} S\{ bar() => foo();\}
 \end{dartCode}
 
 \rationale{Now assume a method \code{foo()} is added to \code{S}. }
 
 \begin{dartCode}
 \LIBRARY{} L1;
-\CLASS{} S \{foo() =$>$ 91;\}
+\CLASS{} S \{foo() => 91;\}
 \end{dartCode}
 
 \rationale{
 If inheritance took precedence over the lexical scope, the behavior of \code{C} would change in an unexpected way. Neither the author of \code{S} nor the author of \code{C} are necessarily aware of this. In Dart, if there is a lexically visible method \code{foo()}, it will always be called.
 
 Now consider the opposite scenario. We start with a version of \code{S} that contains \code{foo()}, but do not declare \code{foo()} in library \code{L2}.  Again, there is a change in behavior - but the author of \code{L2} is the one who introduced the discrepancy that effects their code, and the new code is lexically visible. Both these factors make it more likely that the problem will be detected.
 
 These considerations become even more important if one introduces constructs such as nested classes, which might be considered in future versions of the language.
 
 Good tooling should of course endeavor to inform programmers of such situations (discreetly). For example, an identifier that is both inherited and lexically visible could be highlighted (via underlining or colorization). Better yet, tight integration of source control with language aware tools would detect such changes when they occur.
@@ skipping 308 matching lines @@
 \LMHash{}
 All functions have a signature and a body. The signature describes the formal parameters of the function, and possibly its name and return type.  A function body is either:
 \begin{itemize}
 \item A block statement  (\ref{blocks}) containing the statements  (\ref{statements}) executed by the function, optionally marked with one of the modifiers: \ASYNC, \ASYNC* or \SYNC*. In this case, if the last statement of a function is not a return statement (\ref{return}), the statement \code{\RETURN{};} is implicitly appended to the function body.
 
 \rationale{
 Because Dart is optionally typed, we cannot guarantee that a function that does not return a value will not be used in the context of an expression. Therefore, every function must return a value. A \RETURN{} without an expression returns \NULL{}. For generator functions, the situation is more subtle. See further discussion in section \ref{return}.
 }
 
 OR
-\item of the form   \code{=$>$ $e$} which is equivalent to a body of the form \code{\{\RETURN{} $e$;\}} or the form \code{\ASYNC{} =$>$ $e$} which is equivalent to a body of the form \code{\ASYNC{} \{\RETURN{} $e$;\}}. \rationale{The other modifiers do not apply here, because they apply only to generators, discussed below, and generators do not allow the form \code{\RETURN{} $e$}; values are added to the generated stream or iterable using \YIELD{} instead.}
+\item of the form   \code{=> $e$} which is equivalent to a body of the form \code{\{\RETURN{} $e$;\}} or the form \code{\ASYNC{} => $e$} which is equivalent to a body of the form \code{\ASYNC{} \{\RETURN{} $e$;\}}. \rationale{The other modifiers do not apply here, because they apply only to generators, discussed below, and generators do not allow the form \code{\RETURN{} $e$}; values are added to the generated stream or iterable using \YIELD{} instead.}
 
 \end{itemize}
 
 \LMHash{}
 A function is {\em asynchronous} if its body is marked with the \ASYNC{} or \ASYNC* modifier. Otherwise the function is {\em synchronous}. A function is a {\em generator} if its body is marked with the \SYNC* or \ASYNC* modifier.
 
 \commentary{
 Whether a function is synchronous or asynchronous is orthogonal to whether it is a generator or not. Generator functions are a sugar for functions that produce collections in a systematic way, by lazily applying a function that {\em generates} individual elements of a collection. Dart provides such a sugar in both the synchronous case, where one returns an iterable, and in the asynchronous case, where one returns a stream. Dart also allows both synchronous and asynchronous functions that produce a single value.
 }
 
 \LMHash{}
 It is a compile-time error if an \ASYNC, \ASYNC* or \SYNC* modifier is attached to the body of a setter or constructor.
 
 \rationale{
 An asynchronous setter would be of little use, since setters can only be used in the context of an assignment (\ref{assignment}), and an assignment expression always evaluates to the value of the assignment's right hand side. If the setter actually did its work asynchronously, one might imagine that one would return a future that resolved to the assignment's right hand side after the setter did its work. However, this would require dynamic tests at every assignment, and so would be prohibitively expensive.
 
 An asynchronous constructor would, by definition, never return an instance of the class it purports to construct, but instead return a future. Calling such a beast via \NEW{} would be very confusing. If you need to produce an object asynchronously, use a method.
 
 One could allow modifiers for factories. A factory for \code{Future} could be modified by \ASYNC{}, a factory for \code{Stream} could be modified by \ASYNC* and a factory for \code{Iterable} could be modified by \SYNC*. No other scenario makes sense because the object returned by the factory would be of the wrong type. This situation is very unusual so it is not worth making an exception to the general rule for constructors in order to allow it.
 }
 \LMHash{}
-It is a static warning if the declared return type of a function marked \ASYNC{} is not a supertype of \code{Future$<$\mbox{$T$}$>$} for some type $T$.
-It is a static warning if the declared return type of a function marked \SYNC* is not a supertype of \code{Iterable$<$\mbox{$T$}$>$} for some type $T$.
-It is a static warning if the declared return type of a function marked \ASYNC* is not a supertype of \code{Stream$<$\mbox{$T$}$>$} for some type $T$.
+It is a static warning if the declared return type of a function marked \ASYNC{} is not a supertype of \code{Future<\mbox{$T$}>} for some type $T$.
+It is a static warning if the declared return type of a function marked \SYNC* is not a supertype of \code{Iterable<\mbox{$T$}>} for some type $T$.
+It is a static warning if the declared return type of a function marked \ASYNC* is not a supertype of \code{Stream<\mbox{$T$}>} for some type $T$.
 
 \subsection{Function Declarations}
 \LMLabel{functionDeclarations}
 
 \LMHash{}
 A {\em function declaration} is a function that is neither a member of a class nor a function literal. Function declarations include {\em library functions}, which are function declarations
 %(including getters and setters)
 at the top level of a library, and {\em local functions}, which are function declarations declared inside other functions. Library functions are often referred to simply as top-level functions.
 
 \LMHash{}
@@ skipping 316 matching lines @@
 It is a compile-time error if a class has an instance member and a static member  with the same name.
 % It is a compile-time error if a generic (\ref{generics}) class declares a member with the same name as one of its type parameters.
 
 \commentary{Here are simple examples, that illustrate the difference between ``has a member'' and ``declares a member''. For example, \code{B} {\em declares} one member named \code{f}, but {\em has} two such members. The rules of inheritance determine what members a class has.
 }
 
 \begin{dartCode}
 \CLASS{} A \{
   \VAR{} i = 0;
   \VAR{} j;
-  f(x) =$>$ 3;
+  f(x) => 3;
 \}
 
 \CLASS{} B \EXTENDS{} A \{
   int i = 1; //  getter i and setter i= override versions from A
   \STATIC{} j; // compile-time error: static getter \& setter conflict with
   //instance getter \& setter
 
   /* compile-time error: static method conflicts with instance method */
-  \STATIC{} f(x) =$>$ 3;
+  \STATIC{} f(x) => 3;
 \}
 \end{dartCode}
 
 \LMHash{}
 It is a compile time error if a class $C$ declares a member with the same name as $C$. It is a compile time error if a generic class declares a type variable with the same name as the class or any of its members or constructors.
 
 \subsection{Instance Methods}
 \LMLabel{instanceMethods}
 
 \LMHash{}
@@ skipping 35 matching lines @@
       relationalOperator;
       `==';
       bitwiseOperator
     .
  \end{grammar}
 
 \LMHash{}
 An operator declaration is identified using the built-in identifier (\ref{identifierReference}) \OPERATOR{}.
 
 \LMHash{}
-The following names are allowed for user-defined operators: \code{$<$, $>$, $<$=, $>$=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$,  []=, [], \~{}.}
+The following names are allowed for user-defined operators: \code{<, >, <=, >=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$,  []=, [], \~{}.}
 
 
 \LMHash{}
-It is a compile-time error if the arity of the user-declared operator \code{[]=} is not 2. It is a compile-time error if the arity of a user-declared operator with one of the names:  \code{ $<$, $>$, $<$=, $>$=, ==, -, +,  \~{}/, /, *, \%, $|$, \^{}, \&, $<<$, $>>$, []} is not 1. It is a compile-time error if the arity of the user-declared operator  \code{-} is not 0 or 1.
+It is a compile-time error if the arity of the user-declared operator \code{[]=} is not 2. It is a compile-time error if the arity of a user-declared operator with one of the names:  \code{ <, >, <=, >=, ==, -, +,  \~{}/, /, *, \%, $|$, \^{}, \&, $<<$, $>>$, []} is not 1. It is a compile-time error if the arity of the user-declared operator  \code{-} is not 0 or 1.
 
 \commentary{
 The \code{-} operator is unique in that two overloaded versions are permitted. If the operator has no arguments, it denotes unary minus. If it has an argument, it denotes binary subtraction.
 }
 
 \LMHash{}
 The name of the unary operator \code{-} is \code{unary-}.
 
 \rationale{
 This device allows the two methods to be distinguished for purposes of method lookup, override and reflection.
@@ skipping 124 matching lines @@
 \item  $m$ overrides a concrete member, or
 \item $C$ has a \cd{noSuchMethod()} method distinct from the one declared in class \cd{Object}.
 \end{itemize}
 
 \rationale {
 We wish to warn if one declares a concrete class with abstract members. However,  code like the following should work without warnings:
 }
 
 \begin{dartCode}
  class Base \{
-    int get one =$>$ 1;
+    int get one => 1;
  \}
 
  abstract class Mix \{
     int get one;
-    int get two =$>$ one + one;
+    int get two => one + one;
  \}
 
  class C extends Base with Mix \{ \}
 \end{dartCode}
 
 \rationale{At run time, the concrete method \cd{one} declared in \cd{Base} will be executed, and no problem should arise. Therefore no warning should be issued and so we suppress warnings if a corresponding concrete member exists in the hierarchy. }
 
 \subsection{Instance Variables}
 \LMLabel{instanceVariables}
 
@@ skipping 329 matching lines @@
 \item An abstract class may provide a constant constructor that utilizes the constant constructor of another class.
 \item A redirecting factory constructors avoids the need for forwarders to repeat the default values for formal parameters in their signatures.
 %\item A generic factory class that aggregates factory constructors for types it does not implement can still have its type arguments passed correctly.
 \end{itemize}
 
 %An example of the latter point:
 %}
 
 
 %\begin{dartCode}
-%\CLASS{} W$<$T$>$ \IMPLEMENTS{} A$<$T$>$ { W(w) {...} ...}
-%\CLASS{} X$<$T$>$ \IMPLEMENTS{} A$<$T$>$ { X(x) {...} ...}
-%\CLASS{} Y$<$T$>$ \IMPLEMENTS{} A$<$T$>$ { Y(y) {...} ...}
-%\CLASS{} Z$<$T$>$ \IMPLEMENTS{} A$<$T$>$ { Z(z) {...} ...}
+%\CLASS{} W<T> \IMPLEMENTS{} A<T> { W(w) {...} ...}
+%\CLASS{} X<T> \IMPLEMENTS{} A<T> { X(x) {...} ...}
+%\CLASS{} Y<T> \IMPLEMENTS{} A<T> { Y(y) {...} ...}
+%\CLASS{} Z<T> \IMPLEMENTS{} A<T> { Z(z) {...} ...}
 
 
-%\CLASS{} F$<$T$>$ { // note that F does not implement A
-%  \STATIC{} F$<$T$>$ idw(w) $=>$ \NEW{}  W$<$T$>$(w); // illegal - T not in scope in idw
-%  \FACTORY{} F.idx(x) $=>$ \NEW{} X$<$T$>$(x);
-%  \FACTORY{} F.idy(y) $=>$ \NEW{} Y$<$T$>$(y);
-%  \STATIC{} F idz(z) $=>$ \NEW{}  Z(z); // does not capture the type argument
+%\CLASS{} F<T> { // note that F does not implement A
+%  \STATIC{} F<T> idw(w) => \NEW{}  W<T>(w); // illegal - T not in scope in idw
+%  \FACTORY{} F.idx(x) => \NEW{} X<T>(x);
+%  \FACTORY{} F.idy(y) => \NEW{} Y<T>(y);
+%  \STATIC{} F idz(z) => \NEW{}  Z(z); // does not capture the type argument
 %}
 
-%\CLASS{} A$<$T$>${
-%  \FACTORY{} A.idw(w) $=>$ F$<$T$>$.idw(w);
+%\CLASS{} A<T>{
+%  \FACTORY{} A.idw(w) => F<T>.idw(w);
 %// illegal - cannot pass type parameter to static method
-%  \FACTORY{} A.idx(x) $=> \NEW{} $F$<$T$>$.idx(x); // works, but allocates a gratuitous instance of F
-%  \FACTORY{} A.idy(y) = Y$<$T$>$; // works
-%  \FACTORY{} A.idz(z) $=>$ F.idz(z); // wrong - returns Z$<$Dynamic$>$; no way to pass type argument
+%  \FACTORY{} A.idx(x) $=> \NEW{} $F<T>.idx(x); // works, but allocates a gratuitous instance of F
+%  \FACTORY{} A.idy(y) = Y<T>; // works
+%  \FACTORY{} A.idz(z) => F.idz(z); // wrong - returns Z<Dynamic>; no way to pass type argument
 }
 %\end{dartCode}
 
 \LMHash{}
 It is a compile-time error if $k$ is prefixed with the \CONST{} modifier but $k^\prime$ is not a constant constructor (\ref{constantConstructors}).
 
 \LMHash{}
 It is a static warning if the function type of $k^\prime$ is not a subtype of the type of $k$.
 
 \commentary{
@@ skipping 217 matching lines @@
 It is a compile-time error if  the \EXTENDS{} clause of a class $C$ specifies an enumerated type (\ref{enums}), a malformed  type or a deferred type (\ref{staticTypes}) as a superclass.
 % too strict? Do we e want extends List<Undeclared> to work as List<dynamic>?
 
 \commentary{ The type parameters of a generic class are available in the lexical scope of the superclass clause, potentially shadowing classes in the surrounding scope. The following code is therefore illegal and should cause a compile-time error:
 }
 
 \begin{dartCode}
 class T \{\}
 
 /* Compilation error: Attempt to subclass a type parameter */
-class G$<$T$>$ extends T \{\}
+class G<T> extends T \{\}
 
 \end{dartCode}
 
 
 \LMHash{}
 A class $S$ is {\em a superclass} of a class $C$ iff either:
 \begin{itemize}
 \item $S$ is the superclass of $C$, or
 \item $S$ is a superclass of a class $S^{\prime}$ and $S^{\prime}$ is a superclass of $C$.
 \end{itemize}
@@ skipping 395 matching lines @@
 The declaration of an enum of the form \code{metadata \ENUM{} E \{ id$_0$, \ldots id$_{n-1}$\};}
 has the same effect as a class declaration
 
 \begin{dartCode}
 metadata \CLASS{} E \{
   \FINAL{} int index;
   \CONST{} E(\THIS{}.index);
   \STATIC{} \CONST{} E id$_0$ = \CONST{} E(0);
   $\ldots$
   \STATIC{} \CONST{} E id$_{n-1}$ = const E(n - 1);
-  \STATIC{} \CONST{} List$<$E$>$ values = const $<$E$>$[id$_0 \ldots $ id$_{n-1}$];
-  String toString() =$>$ \{ 0: `E.id$_0$', $\ldots$, n-1: `E.id$_{n-1}$'\}[index]
+  \STATIC{} \CONST{} List<E> values = const <E>[id$_0 \ldots $ id$_{n-1}$];
+  String toString() => \{ 0: `E.id$_0$', $\ldots$, n-1: `E.id$_{n-1}$'\}[index]
 \}
 \end{dartCode}
 
 \commentary {
 It is also a compile-time error to subclass, mix-in or implement an enum or to explicitly instantiate an enum.  These restrictions are given in normative form in sections \ref{superclasses}, \ref{superinterfaces}, \ref{mixinApplication} and \ref{instanceCreation} as appropriate.
 }
 
 \section{Generics}
 \LMLabel{generics}
 
@@ skipping 19 matching lines @@
 
 \rationale{
 The restriction is necessary since a type variable has no meaning in the context of a static member, because statics are shared among all instantiations of a generic. However, a type variable may be referenced from an instance initializer, even though \THIS{} is not available.
 }
 
 \commentary{
 Because type parameters are in scope in their bounds, we support F-bounded quantification (if you don't know what that is, don't ask). This enables typechecking code such as:
 }
 
 \begin{dartCode}
-\INTERFACE{} Ordered$<$T$>$ \{
-  operator $>$ (T x);
+\INTERFACE{} Ordered<T> \{
+  operator > (T x);
 \}
 
-\CLASS{} Sorter$<$T \EXTENDS{} Ordered$<$T$>>$ \{
-   sort(List$<$T$>$ l) {... l[n] $<$ l[n+1] ...}
+\CLASS{} Sorter<T \EXTENDS{} Ordered<T$>>$ \{
+   sort(List<T> l) {... l[n] < l[n+1] ...}
 \}
 
 \end{dartCode}
 
 \commentary{
 Even where type parameters are in scope there are numerous restrictions at this time:
 \begin{itemize}
 \item A type parameter cannot be used to name a constructor in an instance creation expression (\ref{instanceCreation}).
 \item A type parameter cannot be used as a superclass or superinterface (\ref{superclasses}, \ref{superinterfaces}, \ref{interfaceSuperinterfaces}).
 \item A type parameter cannot be used as a generic type.
 \end{itemize}
 
 The normative versions of these  are given in the appropriate sections of this specification. Some of these restrictions may be lifted in the future.
 }
 
 %The {\em induced type set}, $S$, of a parameterized type $T$ is the set consisting of
 %\begin{itemize}
 %\item The supertypes of any type in $S$.
 %\item The type arguments of any parameterized type in $S$.
 %\end{itemize}
 
 %Let $P$ be the instantiation of a generic type with its own type parameters. It is a compile-time error if the induced type set of $P$ is not finite.
 
 %\rationale {A typical recursive type declaration such as}
 
 %\begin{dartCode}
-%\CLASS{} B$<$S$>$ \{\}
-%\CLASS{} D$<$T$>$ \EXTENDS{} B$<$D$<$T$>>$ \{\}
+%\CLASS{} B<S> \{\}
+%\CLASS{} D<T> \EXTENDS{} B<D<T$>>$ \{\}
 %\end{dartCode}
 
 %\rationale{
-%poses no problem under this rule. The instantiation \cd{D$<$T$>$} has an induced
-%set consisting of: \cd{B$<$D$<$T$>>$, Object, D$<$T$>$, T}. However, the following variant
+%poses no problem under this rule. The instantiation \cd{D<T>} has an induced
+%set consisting of: \cd{B<D<T$>>$, Object, D<T>, T}. However, the following variant
 %}
 
 %\begin{dartCode}
-%\CLASS{} B$<$S$>$ \{\}
-%\CLASS{} D$<$T$>$ \EXTENDS{} B$<$D$<$D$<$T$>>>$ \{\}
+%\CLASS{} B<S> \{\}
+%\CLASS{} D<T> \EXTENDS{} B<D<D<T$>>>$ \{\}
 %\end{dartCode}
 
 %\rationale{
-%is disallowed. Consider again the instantiation \cd{D$<$T$>$}. It leads to the
-%superclass \cd{B$<$D$<$D$<$T$>>>$}, and so adds \cd{D$<$D$< $T$>>$} to the induced set. The latter in turn leads to  \cd{B$<$D$<$D$<$D$<$T$>>>>$} and \cd{D$<$D$<$D$<$T$>>>$}
+%is disallowed. Consider again the instantiation \cd{D<T>}. It leads to the
+%superclass \cd{B<D<D<T$>>>$}, and so adds \cd{D<D$< $T$>>$} to the induced set. The latter in turn leads to  \cd{B<D<D<D<T$>>>>$} and \cd{D<D<D<T$>>>$}
 %and so on ad infinitum.}
 
 %\commentary{
 %The above requirement does not preclude the use of arbitrary recursive types in the body of a generic class. }
 %A generic has a type parameter scope. The enclosing scope of a type parameter scope of a generic G  is the enclosing scope of G.
 
 
 %class T {...}
 
 %class G<T> extends T;
@@ skipping 178 matching lines @@
 \item A constant constructor invocation (\ref{const}) that is not qualified by a deferred prefix.
 \item A constant list literal (\ref{lists}).
 \item A constant map literal (\ref{maps}).
 \item A simple or qualified identifier denoting a top-level function (\ref{functions}) or a static method (\ref{staticMethods}) that is not qualified by a deferred prefix.
 \item A parenthesized expression \code{($e$)} where $e$ is a constant expression.
 \item An expression of the form \code{identical($e_1$, $e_2$)} where $e_1$ and $e_2$ are constant expressions  and \code{identical()} is statically bound to the predefined dart function   \code{identical()} discussed above (\ref{objectIdentity}).
 \item An expression of one of the forms  \code{$e_1$ == $e_2$} or  \code{$e_1$ != $e_2$} where $e_1$ and $e_2$ are constant expressions that evaluate to a numeric, string or boolean value or to \NULL{}.
 \item An expression of one of the forms \code{!$e$}, \code{$e_1$ \&\& $e_2$} or \code{$e_1 || e_2$}, where  $e$, $e_1$ and $e_2$ are constant expressions that evaluate to a boolean value.
 \item An expression of one of the forms \~{}$e$, $e_1$ \^{} $e_2$, \code{$e_1$ \& $e_2$}, $e_1 | e_2$, $e_1 >> e_2$ or $e_1 <<  e_2$, where  $e$, $e_1$ and $e_2$ are constant expressions that evaluate to an integer value  or to \NULL{}.
 \item An expression of the form \code{$e_1 + e_2$} where $e_1$ and $e_2$ are constant expressions that evaluate to a numeric or string value or to \NULL{}.
-\item An expression of one of the forms \code{$-e$}, \code{$e_1$ - $e_2$}, \code{$e_1$ * $e_2$}, \code{$e_1$ / $e_2$,} \code{$e_1$ \~{}/ $e_2$},  \code{$e_1  >  e_2$}, \code{$e_1  <  e_2$}, \code{$e_1$ $>$= $e_2$}, \code{$e_1$ $<$= $e_2$} or \code{$e_1$ \% $e_2$},  where $e$, $e_1$ and $e_2$ are constant expressions that evaluate to a numeric value  or to \NULL{}.
+\item An expression of one of the forms \code{$-e$}, \code{$e_1$ - $e_2$}, \code{$e_1$ * $e_2$}, \code{$e_1$ / $e_2$,} \code{$e_1$ \~{}/ $e_2$},  \code{$e_1  >  e_2$}, \code{$e_1  <  e_2$}, \code{$e_1$ >= $e_2$}, \code{$e_1$ <= $e_2$} or \code{$e_1$ \% $e_2$},  where $e$, $e_1$ and $e_2$ are constant expressions that evaluate to a numeric value  or to \NULL{}.
 \item An expression of the form \code{$e_1$?$e_2$:$e3$} where $e_1$, $e_2$ and $e_3$ are constant expressions and $e_1$ evaluates to a boolean value.
 \item An expression of the form \code{$e_1 ?? e_2$} where $e_1$ and $e_2$ are constant expressions.
 \item An expression of the form \code{$e$.length} where $e$ is a constant expression that evaluates to a string value.
 \end{itemize}
 
 % null in all the expressions
 
 % designed so constants do not depend on check diode being on or not.
 
 \LMHash{}
@@ skipping 672 matching lines @@
 
 In any other circumstance, $flatten(T) = T$.
 
 
 
 \rationale{
 We collapse multiple layers of futures into one. If $e$ evaluates to a future $f$, the future will not invoke its \code{then()} callback until f completes to a non-future value, and so the result of an await is never a future, and the result of an async function will never have type \code{Future$<X>$} where $X$ itself is an invocation of \code{Future}.
 
 The  exception to that would be a type $X$ that extended or implemented \code{Future}. In that case, only one unwrapping takes place. As an example of why this is done, consider
 
-\cd{\CLASS{} C$<$T$>$  \IMPLEMENTS{}  Future$<$C$<$C$<$T$>>>$ \ldots }
+\cd{\CLASS{} C<T>  \IMPLEMENTS{}  Future<C<C<T$>>>$ \ldots }
 
 Here, a naive definition of $flatten$ diverges; there is not even a fixed point. A more sophisticated definition of $flatten$ is possible, but the existing rule deals with most realistic examples while remaining relatively simple to understand.
 
 }
 
 
 \LMHash{}
 The static type of a function literal of the form
 
 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k} = d_k\}) => e$
@@ skipping 338 matching lines @@
 \}
 
 \CONST{} A("x"); // compile-time error
 \CONST{} A(5); // legal
 
 
 \CLASS{} IntPair \{
  \CONST{} IntPair(\THIS{}.x, \THIS{}.y);
  \FINAL{} int x;
  \FINAL{} int y;
- \OPERATOR *(v) $=>$ \NEW{} IntPair(x*v, y*v);
+ \OPERATOR *(v) => \NEW{} IntPair(x*v, y*v);
 \}
 
 \CONST{} A(\CONST{} IntPair(1,2)); // compile-time error: illegal in a subtler way
 \end{dartCode}
 
 \commentary{
 Due to the rules governing constant constructors, evaluating the constructor \code{A()} with the argument \code{"x"} or the argument \code{\CONST{} IntPair(1, 2)} would cause it to throw an exception, resulting in a compile-time error.
 }
 
 
@@ skipping 371 matching lines @@
 \item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
 
 and the result of the latter invocation is the result of evaluating $i$.
 
 \rationale {
 It is possible to bring about such a situation by overriding \code{noSuchMethod()} with the wrong number of arguments:}
 
 \begin{code}
 \CLASS{} Perverse \{
-    noSuchMethod(x,y) =$>$ x + y;
+    noSuchMethod(x,y) => x + y;
 \}
 
 \NEW{} Perverse.unknownMethod();
 \end{code}
 
 \commentary{Notice that the wording carefully avoids re-evaluating the receiver $o$ and the arguments $a_i$. }
 
 \LMHash{}
 Let $T$ be the  static type of $o$. It is a static type warning if $T$ does not have an accessible  (\ref{privacy}) instance member named $m$ unless  either:
 \begin{itemize}
 \item
 $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}.  Or
 \item  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ has a static getter named $m$.
 \item $T$ is \code{Function} and $m$ is \CALL. \rationale {The type \code{Function} is treated as if it has a \code{call} method for any possible signature of \CALL. The expectation is that any concrete subclass of \code{Function} will implement \CALL. Note that a warning will be issue if this is not the case. Furthermore, any use of \CALL{} on a subclass of \code{Function} that fails to implement \CALL{} will also provoke a warning, as this exemption is limited to type \code{Function}, and does not apply to its subtypes.
 }
 \end{itemize}
 
 \LMHash{}
-If $T.m$ exists, it  is a static type warning if the type $F$ of $T.m$ may not be assigned to a function type. If $T.m$ does not exist, or if $F$ is not a function type, the static type of $fi$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of  $F$.
+If $T.m$ exists, it  is a static type warning if the type $F$ of $T.m$ may not be assigned to a function type. If $T.m$ does not exist, or if $F$ is not a function type, the static type of $i$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of  $F$.
 
 \LMHash{}
 It is a compile-time error to invoke any of the methods of class \cd{Object} on a prefix object (\ref{imports}) or on a constant type literal that is  immediately followed by the token `.'.
 
 
 \subsubsection{Cascaded Invocations}
 \LMLabel{cascadedInvocations}
 
 \LMHash{}
 A {\em cascaded method invocation} has the form \code{$e$..\metavar{suffix}}
@@ skipping 226 matching lines @@
 \end{itemize}
 
 
 \subsubsection{Ordinary Member Closurization}
 \LMLabel{ordinaryMemberClosurization}
 
 \LMHash{}
 Let $o$ be an object, and let $u$ be a fresh final variable bound to $o$.
 The {\em closurization of method $f$ on object $o$} is defined to be equivalent to:
 \begin{itemize}
-%\item $(a) \{\RETURN{}$ $u$ $op$ $a;$\} if $f$ is named $op$ and $op$ is one of  \code{$<$, $>$, $<$=, $>$=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$} (this precludes closurization of unary -).
+%\item $(a) \{\RETURN{}$ $u$ $op$ $a;$\} if $f$ is named $op$ and $op$ is one of  \code{<, >, <=, >=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$} (this precludes closurization of unary -).
 %\item $() \{\RETURN{}$ \~{} $u;$\} if $f$ is named \~{}.
 %\item $(a) \{\RETURN{}$ $u[a];$\} if $f$ is named $[]$.
 %\item $(a, b) \{\RETURN{}$ $u[a] = b;$\} if $f$ is named $[]=$.
 \item
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 = d_1, \ldots , p_k = d_k\})$ \{
   \RETURN{} $ u.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
 \}
 \end{dartCode}
 if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
@@ skipping 20 matching lines @@
 }
 
 \subsubsection{Super Closurization}
 \LMLabel{superClosurization}
 
 \LMHash{}
 The {\em closurization of method $f$ with respect to superclass $S$} is defined to be equivalent to:
 
 \LMHash{}
 \begin{itemize}
-%\item $(a) \{\RETURN{}$ \SUPER{} $op$ $a;$\} if $f$ is named $op$ and $op$ is one of  \code{$<$, $>$, $<$=, $>$=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$}.
+%\item $(a) \{\RETURN{}$ \SUPER{} $op$ $a;$\} if $f$ is named $op$ and $op$ is one of  \code{<, >, <=, >=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$}.
 %\item $() \{\RETURN{}$ \~{}\SUPER;\} if $f$ is named \~{}.
 %\item $(a) \{\RETURN{}$ $\SUPER[a];$\} if $f$ is named $[]$.
 %\item $(a, b) \{\RETURN{}$ $\SUPER[a] = b;$\} if $f$ is named $[]=$.
 \item
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 = d_1, \ldots , p_k = d_k\})$ \{
   \RETURN{} \SUPER$.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
 \}
 \end{dartCode}
 if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
@@ skipping 1255 matching lines @@
 \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{}
  A variable declaration statement of the form \VAR{} $v;$ is equivalent to \VAR{} $v = \NULL{};$. A variable declaration statement of the form $T$ $v;$ is equivalent to $T$ $v = \NULL{};$.
 
 \commentary{
-This holds regardless of the type $T$. For example, \code{int i;} does not cause \code{i} to be initialized to zero. Instead, \code{i} is initialized to \NULL{}, just as if we had written \VAR{} \code{i;} or \code{Object i;} or \code{Collection$<$String$>$ i;}.
+This holds regardless of the type $T$. For example, \code{int i;} does not cause \code{i} to be initialized to zero. Instead, \code{i} is initialized to \NULL{}, just as if we had written \VAR{} \code{i;} or \code{Object i;} or \code{Collection<String> i;}.
 }
 
 \rationale{
 To do otherwise would undermine the optionally typed nature of Dart, causing type annotations to modify program behavior.
 }
 
 %A variable declaration statement of one of the forms $T$ $v;$, $T$ $v = e;$, \CONST{} $T$ $v = e;$,  or \FINAL{} $T$ $v = e;$ causes a new getter named $v$ with static return type $T$ to be added to the innermost enclosing scope at the point following the variable declaration statement. The result of executing this getter is the value stored in $v$.
 
 %A variable declaration statement \VAR{} $v;$, \VAR{} $v = e;$, \CONST{}  $v = e;$ or  \FINAL{}  $v = e;$ causes a new getter named $v$ with static return type  \DYNAMIC{} to be added to the innermost enclosing scope at the point following the variable declaration statement. The result of executing this getter  is the value stored in $v$.
 
@@ skipping 19 matching lines @@
  \end{grammar}
 
 \LMHash{}
 A function declaration statement of one of the forms $id$ $signature$ $\{ statements \}$ or $T$ $id$ $signature$ $\{ statements \}$ causes a new function named $id$ to be added to the innermost enclosing scope. It is a compile-time error to reference a local function before its declaration.
 
 
 \commentary{ This implies that local functions can be directly recursive, but not mutually recursive. Consider these examples:
 }
 
 \begin{dartCode}
-f(x) =$>$ x++;  // a top level function
+f(x) => x++;  // a top level function
 top() \{ // another top level function
   f(3); // illegal
-  f(x) $=>$ x $>$ 0? x*f(x-1): 1;  // recursion is legal
-  g1(x) $=>$ h(x, 1); // error: h is not declared yet
-  h(x, n) $=>$ x $>$ 1? h(x-1, n*x): n; // again, recursion is fine
-  g2(x) $=>$ h(x, 1); // legal
+  f(x) => x > 0? x*f(x-1): 1;  // recursion is legal
+  g1(x) => h(x, 1); // error: h is not declared yet
+  h(x, n) => x > 1? h(x-1, n*x): n; // again, recursion is fine
+  g2(x) => h(x, 1); // legal
 
-  p1(x) $=>$ q(x,x); // illegal
-  q1(a, b)$ =>$ a $>$ 0 ? p1(a-1): b; // fine
+  p1(x) => q(x,x); // illegal
+  q1(a, b)$ =>$ a > 0 ? p1(a-1): b; // fine
 
-  q2(a, b) $=>$ a $>$ 0 ? p2(a-1): b; // illegal
-  p1(x) $=>$ q2(x,x); // fine
+  q2(a, b) => a > 0 ? p2(a-1): b; // illegal
+  p1(x) => q2(x,x); // fine
 \}
 \end{dartCode}
 
 \commentary{
 There is no way to write a pair of mutually recursive local functions, because one always has to come before the other is declared. These cases are quite rare, and can always be managed by defining a pair of variables first, then assigning them appropriate closures:
 }
 
 \begin{dartCode}
 top2() \{ // a top level function
  \VAR{} p, q;
-  p = (x) $=>$ q(x,x);
-  q = (a, b) $=>$ a $>$ 0 ? p(a-1): b;
+  p = (x) => q(x,x);
+  q = (a, b) => a > 0 ? p(a-1): b;
 
 \}
 \end{dartCode}
 
 \rationale{
 The  rules for local functions differ slightly from those for local variables in that a function can be accessed within its declaration but a variable can only be accessed after its declaration. This is because recursive functions are useful whereas recursively defined variables are almost always errors.  It therefore makes sense to harmonize the rules for local functions with those for functions in general rather than with the rules for local variables.
 }
 
 % elaborate on function identity and equality, runtime type. Likewsie in function expressions (closures) and declarations
 
@@ skipping 626 matching lines @@
 
 \commentary{
 In the simplest case, the immediately enclosing function is an ordinary, synchronous non-generator, and upon function termination, the current return value is given to the caller.  The other possibility is that the function is marked \ASYNC{}, in which case the current return value is used to complete the future associated with the function invocation. Both these scenarios are specified in section \ref{functionInvocation}.
 The enclosing function cannot be marked as generator (i.e, \ASYNC* or \SYNC*), since generators are not allowed to contain a statement of the form \code{\RETURN{} $e$;} as discussed below.
 }
 
 \LMHash{}
 Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.
 
 \LMHash{}
-It is a static type warning if the body of $f$ is marked \ASYNC{} and the type \code{Future$<$flatten(T)$>$} (\ref{functionExpressions}) may not be assigned to the declared return type of $f$.    Otherwise, it is a static type warning if $T$ may not be assigned to the declared return type of $f$.
+It is a static type warning if the body of $f$ is marked \ASYNC{} and the type \code{Future<flatten(T)>} (\ref{functionExpressions}) may not be assigned to the declared return type of $f$.    Otherwise, it is a static type warning if $T$ may not be assigned to the declared return type of $f$.
 
 \LMHash{}
 Let $S$ be the runtime type of $o$. In checked mode:
 \begin{itemize}
-\item  If the body of $f$ is marked \ASYNC{} (\ref{functions}) it is a dynamic type error if $o$ is not \NULL{} (\ref{null}) and \code{Future$<$flatten(S)$>$} is not a subtype of the actual return type  (\ref{actualTypeOfADeclaration}) of $f$.
+\item  If the body of $f$ is marked \ASYNC{} (\ref{functions}) it is a dynamic type error if $o$ is not \NULL{} (\ref{null}) and \code{Future<flatten(S)>} is not a subtype of the actual return type  (\ref{actualTypeOfADeclaration}) of $f$.
 \item Otherwise, it is a dynamic type error if $o$ is not \NULL{} and the runtime type of $o$ is not a subtype of the actual return type of $f$.
 \end{itemize}
 
 \LMHash{}
 It is a compile-time error if a return statement of the form \code{\RETURN{} $e$;} appears in a generative constructor (\ref{generativeConstructors}).
 
 \rationale{
 It is quite easy to forget to add the factory prefix for a constructor, accidentally converting a factory into a generative constructor. The static checker may detect a type mismatch in some, but not all, of these cases. The rule above helps catch such errors, which can otherwise be very hard to recognize. There is no real downside to it, as returning a value from a generative constructor is meaningless.
 }
 
 \LMHash{}
 It is a compile-time error if a return statement of the form \code{\RETURN{} $e$;} appears in a generator function.
 
 \rationale{
 In the case of a generator function, the value returned by the function is the iterable or stream associated with it, and individual elements are added to that iterable using yield statements, and so returning a value makes no sense.
 }
 
 \LMHash{}
 Let $f$ be the function immediately enclosing a return statement of the form \RETURN{}; It is a static warning  $f$ is neither a generator nor a generative constructor and either:
 \begin{itemize}
 \item  $f$ is synchronous and the return type of $f$ may not be assigned to \VOID{} (\ref{typeVoid}) or,
-\item  $f$ is asynchronous and the return type of $f$ may not be assigned to \code{Future$<$Null$>$}.
+\item  $f$ is asynchronous and the return type of $f$ may not be assigned to \code{Future<Null>}.
 \end{itemize}
 
  \commentary{
-Hence, a static warning will not be issued if $f$ has no declared return type, since the return type would be  \DYNAMIC{} and  \DYNAMIC{} may be assigned to \VOID{} and to \code{Future$<$Null$>$}. However, any synchronous non-generator function that declares a return type must return an expression explicitly.
+Hence, a static warning will not be issued if $f$ has no declared return type, since the return type would be  \DYNAMIC{} and  \DYNAMIC{} may be assigned to \VOID{} and to \code{Future<Null>}. However, any synchronous non-generator function that declares a return type must return an expression explicitly.
 }
 \rationale{This helps catch situations where users forget to return a value in a return statement.}
 
-\rationale{ An asynchronous non-generator always returns a future of some sort. If no expression is given, the future will be completed with \NULL{} and this motivates the requirement above.} \commentary{Leaving the return type of a function marked \ASYNC{}  blank will be interpreted as \DYNAMIC{} as always, and cause no type error. Using \code{Future} or \code{Future$<$Object$>$} is acceptable as well, but any other type will cause a warning, since \NULL{} has no subtypes.}
+\rationale{ An asynchronous non-generator always returns a future of some sort. If no expression is given, the future will be completed with \NULL{} and this motivates the requirement above.} \commentary{Leaving the return type of a function marked \ASYNC{}  blank will be interpreted as \DYNAMIC{} as always, and cause no type error. Using \code{Future} or \code{Future<Object>} is acceptable as well, but any other type will cause a warning, since \NULL{} has no subtypes.}
 
 \LMHash{}
 A return statement with no expression, \code{\RETURN;} is executed as follows:
 
 \LMHash{}
 If the immediately enclosing function $f$ is a generator, then:
 \begin{itemize}
 \item
 The current return value is set to \NULL{}.
 \item
@@ skipping 139 matching lines @@
 The current call to \code{moveNext()} returns \TRUE.
 \end{itemize}
 
 \LMHash{}
 It is a compile-time error if a yield statement appears in a function that is not a generator function.
 
 \LMHash{}
 Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.  It is a static type warning if either:
 \begin{itemize}
 \item
- the body of $f$ is marked \ASYNC* and the type \code{Stream$<$T$>$} may not be assigned to the declared return type of $f$.
+ the body of $f$ is marked \ASYNC* and the type \code{Stream<T>} may not be assigned to the declared return type of $f$.
  \item
- the body of $f$ is marked \SYNC* and the type \code{Iterable$<$T$>$} may not be assigned to the declared return type of $f$.
+ the body of $f$ is marked \SYNC* and the type \code{Iterable<T>} may not be assigned to the declared return type of $f$.
  \end{itemize}
 
 
  \subsubsection{ Yield-Each}
  \LMLabel{yieldEach}
 
 \LMHash{}
  The {\em yield-each statement} adds a series of values to the result of a generator function (\ref{functions}).
 
  \begin{grammar}
@@ skipping 512 matching lines @@
 
 \subsection{Scripts}
 \LMLabel{scripts}
 
 \LMHash{}
 A {\em script} is a library whose exported namespace  (\ref{exports}) includes a top-level member named  \code{main}. It is a static warning if the static type of \code{main} is not assignable to a function type or is a function type with more than two required parameters.
 
 A script $S$ may be executed as follows:
 
 \LMHash{}
-First, $S$ is compiled as a library as specified above. Then, the top-level function \code{main} that is in the exported namespace of $S$ is invoked. If \code{main} has no positional parameters, it is invoked with no arguments. Otherwise if \code{main} has exactly one positional parameter, it is invoked with a single actual argument whose runtime type implements \code{List$<$String$>$}.  Otherwise \code{main} is invoked with the following two actual arguments:
+First, $S$ is compiled as a library as specified above. Then, the top-level function \code{main} that is in the exported namespace of $S$ is invoked. If \code{main} has no positional parameters, it is invoked with no arguments. Otherwise if \code{main} has exactly one positional parameter, it is invoked with a single actual argument whose runtime type implements \code{List<String>}.  Otherwise \code{main} is invoked with the following two actual arguments:
 \begin{enumerate}
-\item An object whose runtime type implements \code{List$<$String$>$}.
+\item An object whose runtime type implements \code{List<String>}.
 \item The initial message of the current isolate $i$ as determined by the invocation of \code{Isolate.spawnUri} that spawned $i$.
 \end{enumerate}
 
 \LMHash{}
 It is a run time error if $S$ does not declare or export either:
 \begin{itemize}
 \item  A top-level function named  \code{main}, or
 \item A top-level getter named  \code{main} that returns a function.
 \end{itemize}
 
@@ skipping 153 matching lines @@
 %It is a dynamic type error if a malformed type is used in a subtype test.
 In checked mode, it is a dynamic type error if a deferred, malformed or malbounded (\ref{parameterizedTypes})
 type is used in a subtype test.
 
 %In production mode, an undeclared type is treated as an instance of type \DYNAMIC{}.
 
 \commentary{Consider the following program}
 
 \begin{dartCode}
 \TYPEDEF{} F(bool x);
-f(foo x) $=>$ x;
+f(foo x) => x;
 main() \{
   if (f is F) \{
     print("yoyoma");
   \}
 \}
 \end{dartCode}
 
 \commentary{
 The type of the formal parameter of $f$ is $foo$, which is undeclared in the lexical scope. This will lead to a static type warning. At runtime the program will print \cd{yoyoma}, because $foo$ is treated as \DYNAMIC{}.
 %fail when executing the type test on the first line of $main()$ because it leads to a subtype comparison involving a malformed type ($foo$).
@@ skipping 11 matching lines @@
 \commentary{
 Since $i$ is not a type, a static warning will be issue at the declaration of $j$. However, the program can be executed without incident in production mode because he undeclared type $i$ is treated as \DYNAMIC{}. However, in checked mode, the implicit subtype test at the assignment will trigger an error at runtime.
 }
 
 
 \commentary{
 Here is an example involving malbounded types:
 }
 
 \begin{dartCode}
-\CLASS{} I$<$T \EXTENDS{} num$>$ \{\}
+\CLASS{} I<T \EXTENDS{} num> \{\}
 \CLASS{} J \{\}
 
-\CLASS{} A$<$T$>$ \IMPLEMENTS{} J,  I$<$T$>$ // type warning: T is not a subtype of num
+\CLASS{} A<T> \IMPLEMENTS{} J,  I<T> // type warning: T is not a subtype of num
 \{ ...
 \}
 \end{dartCode}
 
 \commentary{Given the declarations above, the following}
 
 \begin{dartCode}
-I x = \NEW{} A$<$String$>$();
+I x = \NEW{} A<String>();
 \end{dartCode}
 
 \commentary{
-will cause a dynamic type error in checked mode, because the assignment requires a subtype test A$<$String$>$ $<$: I. To show that this holds, we need to show that A$<$String$>$  $<<$ I$<$String$>$, but I$<$String$>$ is a malbounded type, causing the dynamic error.  No error is thrown in production mode. Note that
+will cause a dynamic type error in checked mode, because the assignment requires a subtype test A<String> <: I. To show that this holds, we need to show that A<String>  $<<$ I<String>, but I<String> is a malbounded type, causing the dynamic error.  No error is thrown in production mode. Note that
 }
 
 \begin{dartCode}
-J x = \NEW{} A$<$String$>$();
+J x = \NEW{} A<String>();
 \end{dartCode}
 
 \commentary{
-does not cause a dynamic error, as there is no need to test against \code{I$<$String$>$} in this case.
+does not cause a dynamic error, as there is no need to test against \code{I<String>} in this case.
 Similarly, in production mode
 }
 
 \begin{dartCode}
-A x = \NEW{} A$<$String$>$();
+A x = \NEW{} A<String>();
 bool b = x is I;
 \end{dartCode}
 
 \commentary{
 \code{b} is bound to \TRUE, but in checked mode the second line causes a dynamic type error.
 }
 
 
 
 \subsection{Type Declarations}
@@ skipping 504 matching lines @@
 Additive & +, - & Left & 13\\
 \hline
 Shift &  $<<$, $>>$&  Left & 12\\
 \hline
 Bitwise AND & \& & Left & 11\\
 \hline
 Bitwise XOR & \^{} & Left & 10\\
 \hline
 Bitwise Or &  $|$ & Left & 9\\
 \hline
-Relational & $<$, $>$, $<=$, $>=$, \AS{}, \IS{}, \IS{}! &  None & 8\\
+Relational & <, >, $<=$, $>=$, \AS{}, \IS{}, \IS{}! &  None & 8\\
 \hline
 Equality &  ==, != & None & 7\\
 \hline
 Logical AND & \&\& & Left & 6\\
 \hline
 Logical Or &  $||$ & Left & 5\\
 \hline
 If-null & ?? & Left & 4\\
 \hline
 Conditional &  e1? e2: e3 & Right & 3\\
@@ skipping 171 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.
 
 ----------------------------------------------------------------------