Working insertion of hash values; added a few labels in spec

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification \\
 {\large Version 1.6}}
@@ skipping 268 matching lines @@
 
 \rationale{Libraries do not reference each other by name and so the idea of a private library is meaningless.
 Thus, if the name of a library begins with an underscore, it has no effect on the accessibility of the library or its members.
 }
 
 \rationale{Privacy is, at this point, a static notion tied to a particular piece of code (a library). It is designed to support software engineering concerns rather than security concerns. Untrusted code should always run in an another isolate.  It is possible that libraries will become first class objects and privacy will be a dynamic notion tied to a library instance.
 
 Privacy is indicated by the name of a declaration - hence privacy and naming are not orthogonal. This has the advantage that both humans and machines can recognize access to private declarations at the point of use without knowledge of the context from which the declaration is derived.}
 
 \subsection{Concurrency}
+\LMLabel{concurrency}
 
 \LMHash{}
 Dart code is always single threaded. There is no shared-state concurrency in Dart. Concurrency is supported via actor-like entities called {\em isolates}.
 
 \LMHash{}
 An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (\ref{sendingMessages}). No state is ever shared between isolates. Isolates are created by spawning (\ref{spawningAnIsolate}). 
 
 
 \section{Errors and Warnings}
 \LMLabel{errorsAndWarnings}
@@ skipping 411 matching lines @@
 {\bf simpleFormalParameter:}declaredIdentifier;
       metadata identifier
     .
 
 {\bf fieldFormalParameter:}
    metadata finalConstVarOrType? \THIS{} `{\escapegrammar .}' identifier formalParameterList?
    .
 \end{grammar}
 
 %\subsubsection{Rest Formals}
+%\LMLabel{restFormals}
 
 %A rest formal $R$ must be the last parameter in a formal parameter list.  If a  type $T$ is specified for $R$, it signifies that the type of $R$ is $T[]$. 
 
 %\begin{grammar}
 %restFormalParameter:
 %      finalConstVarOrType? '{\escapegrammar ...}' identifier
  %\end{grammar}
 
 \subsubsection{Optional Formals}
 \LMLabel{optionalFormals}
@@ skipping 530 matching lines @@
      `{\escapegrammar :}' \THIS{} (`{\escapegrammar .}' identifier)? arguments
     .
 \end{grammar}
 
 % Need to specify exactly how executing a redirecting constructor works
 
 
 %\Q{We now have generative constructors with no bodies as well.}
 
 \paragraph{Initializer Lists}
+\LMLabel{initializerLists}
 
 \LMHash{}
 An initializer list begins with a colon, and consists of a comma-separated list of individual {\em initializers}. There are two kinds of initializers.
 \begin{itemize}
 \item A {\em superinitializer} identifies a {\em superconstructor} - that is, a specific  constructor of the superclass.  Execution of the superinitializer causes the initializer list of the superconstructor to be executed.
 
 \item An {\em instance variable initializer} assigns a value to an individual instance variable. 
 \end{itemize}
 
 \begin{grammar}
@@ skipping 2358 matching lines @@
 The implication of this definition, and the other definitions involving the method \code{call()}, is that user defined types can be used as function values provided they define a \CALL{} method. The method \CALL{} is special in this regard. The signature of the \CALL{} method determines the signature used when using the object via the built-in invocation syntax.
 }
 
 \LMHash{}
 It is a static warning if the static type $F$ of $e_f$ may not be assigned to a function type.  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$.  
 %\item Let $T_i$ be the static type of $a_i, i \in 1 .. n+k$. It is a static warning if $F$ is not a supertype of  $(T_1, \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \to \bot$.
 %\end{itemize}
 
 \subsection{ Lookup}
+\LMLabel{lookup}
 
 \subsubsection{Method Lookup}
 \LMLabel{methodLookup}
 
 \LMHash{}
 The result of a lookup of a method $m$ in object $o$ with respect to library $L$ is the result of  a lookup of method $m$ in class $C$ with respect to library $L$, where $C$ is the class of $o$.
 
 \LMHash{}
 The result of  a lookup of method $m$ in class $C$ with respect to library $L$ is:
 If $C$ declares a concrete instance method named $m$ that is accessible to $L$,  then that method is the result of the lookup. Otherwise, if $C$ has a superclass $S$, then the result of the lookup is the result of looking up $m$  in $S$ with respect to $L$. Otherwise, we say that the method lookup has failed.
@@ skipping 3451 matching lines @@
 The scope of a documentation comment immediately preceding the declaration of a class $C$ is the instance scope of $C$, excluding any names introduced via the import namespace of the enclosing library.
 
 \LMHash{}
 The scope of a documentation comment immediately preceding the declaration of a function $f$  is the  scope in force at the very beginning of the body of $f$,  excluding any names introduced via the import namespace of the enclosing library.
 
 
 
 
 
 %\subsection{Grammar}
+%\LMLabel{grammar}
 \subsection{Operator Precedence}
 \LMLabel{operatorPrecedence}
 
 \LMHash{}
 Operator precedence is given implicitly by the grammar.
 
 \commentary{The following non-normative table may be helpful
 \newline
 
 \begin{tabular}{| r | r | r | r |}
@@ skipping 26 matching lines @@
 \hline
 Conditional &  e1? e2: e3 & None & 3\\
 \hline
 Cascade & ..  & Left & 2\\
 \hline
 Assignment &  =, *=, /=, +=, -= ,\&=, \^{}= etc.  &  Right &  1\\
 \hline
 \end{tabular}
 }
 %\subsection{Glossary}
+%\LMLabel{glossary}
 
 %\bibliographystyle{alpha}
 %\bibliography{/users/gilad/research/bibs/master}
 \section*{Appendix: Naming Conventions}
+\LMLabel{namingConventions}
 
 \commentary{
 The following naming conventions are customary in Dart programs. 
 \begin{itemize}
 \item The names of compile time constant variables never use lower case letters. If they consist of multiple words, those words are separated by underscores. Examples: PI,  I\_AM\_A\_CONSTANT.
 \item The names of functions (including getters, setters, methods and local or library functions) and non-constant variables begin with a lowercase letter. If the name consists of multiple words, each  word (except the first) begins with an uppercase letter.  No other uppercase letters are used. Examples: camlCase, dart4TheWorld
 \item The names of types (including classes and type aliases) begin with an upper case letter.  If the name consists of multiple words, each  word  begins with an uppercase letter.  No other uppercase letters are used. Examples: CamlCase, Dart4TheWorld.
 \item The names of type variables are short (preferably single letter). Examples: T, S, K, V , E.
 \item The names of libraries or library prefixes never use upper case letters. If they consist of multiple words, those words are separated by underscores. Example: my\_favorite\_library.
 \end{itemize}
@@ skipping 147 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.
 
 ----------------------------------------------------------------------