Make it more explicit that `Null` doesn't extend anything but `Object`.

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 2613 matching lines @@
 %\Q{Any methods, such as \code{isNull}?}
 
 \begin{grammar}
 {\bf nullLiteral:}
       \NULL{}
 .
 \end{grammar}
 
 \LMHash{}
 The null object is the sole instance of the built-in class \code{Null}. Attempting to instantiate \code{Null} causes a run-time error. It is a compile-time error for a class to extend, mix in or implement \code{Null}.
-The \code{Null} class declares no methods except those also declared by \code{Object}.
+The \code{Null} class extends the \code{Object} class and declares no methods except those also declared by \code{Object}.
 
 \LMHash{}
 The static type of \NULL{} is the \code{Null} type.
 
 
 \subsection{Numbers}
 \LMLabel{numbers}
 
 \LMHash{}
 A {\em numeric literal} is either a decimal or hexadecimal integer of arbitrary size, or a decimal double.
@@ skipping 4752 matching lines @@
 \end{itemize}
 
 %\Q{Can wacky stuff happen with interface injection, e.g., a direct superinterface becomes indirect? What about side effects - loading order can affect type relationships.
 %}
 
 \LMHash{}
 A type $T$ is more specific than a type $S$, written $T << S$,  if one of the following conditions is met:
 \begin{itemize}
 \item $T$ is $S$.
 \item $T$ is $\bot$.
-\item $T$ is \NULL{} and $S$ is not $\bot$.
+\item $T$ is \code{Null} and $S$ is not $\bot$.
 \item $S$ is \DYNAMIC{}.
 \item $S$ is a direct supertype of $T$.
 \item $T$ is a type parameter and $S$ is the upper bound of $T$.
 \item $T$ is a type parameter and $S$ is \cd{Object}.
 \item $T$ is of the form $I<T_1, \ldots, T_n>$ and $S$ is of the form $I<S_1, \ldots, S_n>$ and:
 $T_i << S_i, 1 \le i \le n$
 \item $T$ and $S$ are both function types, and $T << S$ under the rules of section \ref{functionTypes}.
 \item $T$ is a function type and $S$ is \cd{Function}.
 \item $T << U$ and $U << S$.
 \end{itemize}
 
 \LMHash{}
 $<<$ is a partial order on types.
 $T$ is a subtype of $S$, written $T <: S$, iff $[\bot/\DYNAMIC{}]T << S$.
 
 \rationale{
 Note that $<:$ is not a partial order on types, it is only binary relation on types. This is because $<:$ is not transitive. If it was, the subtype rule would have a cycle. For example:
 $List <: List<String>$ and $List<int> <: List$, but $List<int>$ is not a subtype of $List<String>$.
 Although $<:$ is not a partial order on types, it does contain a partial order, namely $<<$. This means that, barring raw types, intuition about classical subtype rules does apply.
 }
 
+\commentary{
+The \code{Null} type is more specific than all non-$\bot$ types, even though
+it doesn't actually extend or implement those types.
+The other types are effectively treated as if they are {\em nullable},
+which makes \NULL{} assignable to them.
+}
+
 \LMHash{}
 $S$ is a supertype of $T$, written $S :> T$, iff $T$ is a subtype of $S$.
 
 \commentary{The supertypes of an interface are its direct supertypes and their supertypes. }
 
 \LMHash{}
-An interface type $T$ may be assigned to a type $S$, written  $T \Longleftrightarrow S$, iff either $T <: S$, $S <: T$, or either $T$ or $S$ is the \code{Null} type.
+An interface type $T$ may be assigned to a type $S$, written  $T \Longleftrightarrow S$, iff either $T <: S$, $S <: T$.
 
 \rationale{This rule may surprise readers accustomed to conventional typechecking. The intent of the $\Longleftrightarrow$ relation is not to ensure that an assignment is correct. Instead, it aims to only flag assignments that are almost certain to be erroneous, without precluding assignments that may work.
 
 For example, assigning a value of static type Object to a variable with static type String, while not guaranteed to be correct, might be fine if the runtime value happens to be a string.
 }
 
 \subsection{Function Types}
 \LMLabel{functionTypes}
 
 \LMHash{}
@@ skipping 587 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.
 
 ----------------------------------------------------------------------