insure type vars are bound properly when executing field initializers. Also correct assoc tablefor …

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.9}}
@@ skipping 740 matching lines @@
 
 \rationale{
 The need for this  restriction is a direct consequence of the fact that naming and privacy are not orthogonal.
 If we allowed named parameters to begin with an underscore, they would be considered private and inaccessible to callers from outside the library where it was defined. If a method outside the library overrode a method with a private optional name, it would not be a subtype of the original method. The static checker would of course flag such situations, but the consequence would be that adding a private named formal would break clients outside the library in a way they could not easily correct. 
 }
 
 \subsection{Type of a Function}
 \LMLabel{typeOfAFunction}
 
 \LMHash{}
-If a function does not declare a return type explicitly, its return type is \DYNAMIC{} (\ref{typeDynamic}).
+If a function does not declare a return type explicitly, its return type is \DYNAMIC{} (\ref{typeDynamic}), unless it is a constructor function, in which case its return type is the immediately enclosing class.
 
 \LMHash{}
 Let $F$ be a function with required formal parameters $T_1$ $p_1 \ldots, T_n$ $p_n$, return type $T_0$ and no optional parameters. Then the type of $F$ is $(T_1 ,\ldots, T_n) \rightarrow T_0$.
 
 \LMHash{}
 Let $F$ be a function with required formal parameters $T_1$ $p_1 \ldots, T_n$ $p_n$, return type $T_0$ and positional optional parameters $T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $ p_{n+k}$. Then the type of $F$ is $(T_1 ,\ldots, T_n, [T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$  $p_{n+k}]) \rightarrow T_0$.
 
 \LMHash{}
 Let $F$ be a function with required formal parameters $T_1$ $p_1 \ldots, T_n$ $p_n$, return type $T_0$ and named optional parameters $T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $ p_{n+k}$. Then the type of $F$ is $(T_1 ,\ldots, T_n, \{T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$  $p_{n+k}\}) \rightarrow T_0$.
 
@@ skipping 80 matching lines @@
 
 {\bf staticFinalDeclaration:}
       identifier `=' expression
     .
 
 \end{grammar}
 
 \LMHash{}
 A class has constructors,  instance members and static members. The instance members of a class are its instance methods, getters, setters and instance variables. The static members of a class are its static methods, getters, setters and static variables. The members of a class are its static and instance members.
 
-% A class has a static scope and an instance scope. The enclosing scope of the static scope of a non-generic class is the enclosing scope of the class declaration. The enclosing scope of the static scope of a generic class is the type parameter scope (\ref{}) of the generic class declaration.
-%The enclosing scope of a class' instance scope is the class' static scope.
+A class has several scopes:
+\begin{itemize}
+\item A {\em type-parameter scope}, which is empty if the class is not generic (\ref{generics}).  The enclosing scope of the type-parameter scope of a class is the enclosing scope of the class declaration. 
+\item A {\em static scope}. The enclosing scope of the static scope of a  class is the type parameter scope (\ref{generics}) of the class.
+\item  An {\em instance scope}.
+The enclosing scope of a class' instance scope is the class' static scope.
+\end{itemize}
 
-%The enclosing scope of an instance member declaration is the instance scope of the class in which it is declared.
+The enclosing scope of an instance member declaration is the instance scope of the class in which it is declared.
 
-%The enclosing scope of a static member declaration is the static scope of the class in which it is declared.
+The enclosing scope of a static member declaration is the static scope of the class in which it is declared.
 
 
 \LMHash{}
 Every class has a single superclass  except class \code{Object} which has no superclass. A class may implement a number of interfaces
 %, either 
 by declaring them in its implements clause  (\ref{superinterfaces}).
 % or via interface injection declarations (\ref{interfaceInjection}) outside the class declaration
 
 
 \LMHash{}
@@ skipping 822 matching lines @@
       \EXTENDS{} type
     .
 \end{grammar}
 
 %The superclass clause of a class C is processed within the enclosing scope of the static scope of C.
 %\commentary{
 %This means that in a generic class, the type parameters of the generic are available in the superclass clause.
 %} 
 
 \LMHash{}
+The scope of the \EXTENDS{} and \WITH{} clauses of a class $C$ is the type-parameter scope of $C$.
+
+\LMHash{}
 %It is a compile-time error if  the \EXTENDS{} clause of a class $C$ includes a type expression that does not denote a class available in the lexical scope of $C$. 
 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 \{\}
 
@@ skipping 113 matching lines @@
 A class has a set of direct superinterfaces. This set includes the interface of its superclass and the interfaces specified in the the \IMPLEMENTS{}  clause of the class.
 % and any superinterfaces specified by interface injection (\ref{interfaceInjection}).  \Q{The latter needs to be worded carefully - when do interface injection clauses execute and in what scope?}
 
 \begin{grammar}
 {\bf interfaces:}
       \IMPLEMENTS{} typeList
     .
 \end{grammar}
 
 \LMHash{}
+The scope of the \IMPLEMENTS{} clause of a class $C$ is the type-parameter scope of $C$.
+
+\LMHash{}
 It is a compile-time error if  the \IMPLEMENTS{}  clause of a class $C$ specifies a type variable as a superinterface. It is a compile-time error if  the  \IMPLEMENTS{} clause of a class $C$ specifies an enumerated type (\ref{enums}),  a malformed type or deferred type (\ref{staticTypes}) as a superinterface  It is a compile-time error if the \IMPLEMENTS{} clause of a class $C$ specifies type \DYNAMIC{} as a superinterface. It is a compile-time error if  the  \IMPLEMENTS{} clause of a class $C$ specifies  a type $T$ as a superinterface more than once.
 It is a compile-time error if the superclass of a class $C$ is specified as a superinterface of $C$.
 
 \rationale{
 One might argue that it is harmless to repeat a type in the superinterface list, so why make it an error? The issue is not so much that the situation described in program source is erroneous, but that it is pointless. As such, it is an indication that the programmer may very well have meant to say something else - and that is a mistake that should be called to her or his attention.  Nevertheless, we could simply issue a warning; and perhaps we should and will. That said, problems like these are local and easily corrected on the spot, so we feel justified in taking a harder line. 
 }
 
 \LMHash{}
 It is a compile-time error if the interface of a class $C$ is a superinterface of itself.
 
@@ skipping 300 matching lines @@
     .
 {\bf typeParameters:}
      `<' typeParameter (`,' typeParameter)* `>'
     .
 \end{grammar}
 
 \LMHash{}
 A type parameter $T$ may be suffixed with an \EXTENDS{} clause that specifies the {\em upper bound} for $T$. If no  \EXTENDS{} clause is present, the upper bound is \code{Object}.  It is a static type warning if a type parameter is a supertype of its upper bound. The bounds of type variables are a form of type annotation and have no effect on execution in production mode.
 
 \LMHash{}
+Type parameters are declared in the type-parameter scope of a class.
 The type parameters of a generic $G$ are in scope in the bounds of all of the type parameters of $G$. The type parameters of a generic class declaration $G$ are also in scope in the \EXTENDS{} and \IMPLEMENTS{} clauses of $G$ (if these exist) and in the body of $G$.   However, a type parameter is considered to be a malformed type when referenced by a static member.
 
 \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:
 }
 
@@ skipping 507 matching lines @@
 
 \rationale{ which this prints  'A simple sum: 2 + 2 = 22' rather than 'A simple sum: 2 + 2 = 4'.
 However, the use the concatenation operation is still  discouraged for efficiency reasons. Instead, the recommended Dart idiom is to use string interpolation.
 }
 
 \begin{dartCode}
 print("A simple sum: 2 + 2 =  \$\{2+2\}");
 \end{dartCode}
 
 
-\rationale{String interpolation work well for most cases. The main situation where it is not fully satisfactory is for string literals that are too large to fit on a line. Multiline strings can be useful, but in some cases, we want to visually align the code. This can be expressed by writing smaller strings separated by whitespace, as shown here:}
+\rationale{String interpolation works well for most cases. The main situation where it is not fully satisfactory is for string literals that are too large to fit on a line. Multiline strings can be useful, but in some cases, we want to visually align the code. This can be expressed by writing smaller strings separated by whitespace, as shown here:}
 
 
 
 
 \begin{dartCode}
 'Imagine this is a very long string that does not fit on a line. What shall we do? '
 'Oh what shall we do? '
 'We shall split it into pieces '
 'like so'.
 \end{dartCode}
@@ skipping 577 matching lines @@
 \LMHash{}
 If $T$  is malformed or if $T$ is a type variable a dynamic error occurs. In checked mode, if $T$ or any of its superclasses is malbounded a dynamic error occurs.
  Otherwise, if $q$ is not defined or not accessible, a \code{NoSuchMethodError} is thrown.  If $q$ has  less than $n$ positional parameters or more than $n$ required parameters, or if $q$ lacks any of the keyword parameters $\{ x_{n+1}, \ldots, x_{n+k}\}$ a \code{NoSuchMethodError} is thrown.
 
 \LMHash{}
 Otherwise, if $q$ is a generative constructor (\ref{generativeConstructors}), then:
 
 \commentary{Note that it this point we are assured that the number of actual type arguments match the number of formal type parameters.}
 
 \LMHash{}
-A fresh instance (\ref{generativeConstructors}), $i$,  of class $R$ is allocated. For each instance variable $f$ of $i$,  if the variable declaration of $f$ has an initializer expression $e_f$, then $e_f$ is evaluated to an object $o_f$ and $f$ is bound to $o_f$. Otherwise $f$ is bound to \NULL{}.
+A fresh instance (\ref{generativeConstructors}), $i$,  of class $R$ is allocated. For each instance variable $f$ of $i$,  if the variable declaration of $f$ has an initializer expression $e_f$, then $e_f$ is evaluated, with the type parameters (if any) of $R$ bound to the actual type arguments $V_1, \ldots, V_l$, to an object $o_f$ and $f$ is bound to $o_f$. Otherwise $f$ is bound to \NULL{}.
 
 \commentary{
 Observe that \THIS{} is not in scope in $e_f$. Hence, the initialization cannot depend on other properties of the object being instantiated.
 }
 
 \LMHash{}
 Next,  $q$ is executed  with \THIS{} bound to $i$,  the type parameters (if any) of $R$ bound to the actual type arguments $V_1, \ldots, V_l$ and the formal parameter bindings that resulted from the evaluation of the argument list. The result of the evaluation of $e$ is $i$.
 
 \LMHash{}
 Otherwise, $q$ is a factory constructor (\ref{factories}). Then:
@@ skipping 707 matching lines @@
 \rationale{
 The special treatment of equality in this case facilitates the use of extracted property functions in APIs where callbacks such as event listeners must often be registered and later unregistered. A common example is the DOM API in web browsers.
 }
 
 
 
 
 \commentary{Observations:
 \begin{enumerate}
 \item One cannot closurize a getter or a setter.
-\item One can tell whether one implemented a property via a method or via field/getter, which means that one has to plan ahead as to what construct to use, and that choice is reflected in the interface of the class.
+\item One can tell whether one implemented a property via a method or via a field/getter, which means that one has to plan ahead as to what construct to use, and that choice is reflected in the interface of the class.
 \end{enumerate}
 } 
 
 
  
 \LMHash{}
 The closurization of $\SUPER{}.m$ with respect to superclass $S$ is defined to be equivalent to:
 
 \begin{itemize}
  %\item $(r_1, \ldots, r_n)\{\RETURN{}$ $o.m(r_1, \ldots, r_n);\}$ if $m$ has only required parameters $r_1, \ldots r_n$.
@@ skipping 1098 matching lines @@
 \begin{grammar}
 {\bf forStatement:}
      \AWAIT? \FOR{} `(' forLoopParts `)' statement
     .
 
 {\bf forLoopParts:}forInitializerStatement expression? `{\escapegrammar ;}' expressionList?;
       declaredIdentifier \IN{} expression;
       identifier \IN{} expression
     .
 
-{\bf forInitializerStatement:}localVariableDeclaration `{\escapegrammar ;}';
+{\bf forInitializerStatement:}localVariableDeclaration;
       expression? `{\escapegrammar ;}'
     .
  \end{grammar}
  
 \LMHash{}
  The for statement has three forms - the traditional for loop and two forms of the for-in statement - synchronous and asynchronous.
 
 \subsubsection{For Loop}
 \LMLabel{forLoop}
 
@@ skipping 2009 matching lines @@
 Bitwise Or &  $|$ & Left & 8\\
 \hline
 Relational & $<$, $>$, $<=$, $>=$, \AS{}, \IS{}, \IS{}! &  None & 7\\
 \hline
 Equality &  ==, != & None & 6\\
 \hline
 Logical AND & \&\& & Left & 5\\
 \hline
 Logical Or &  $||$ & Left & 4\\
 \hline
-Conditional &  e1? e2: e3 & None & 3\\
+Conditional &  e1? e2: e3 & Right & 3\\
 \hline
 Cascade & ..  & Left & 2\\
 \hline
 Assignment &  =, *=, /=, +=, -= ,\&=, \^{}= etc.  &  Right &  1\\
 \hline
 \end{tabular}
 }
 %\subsection{Glossary}
 %\LMLabel{glossary}
 
@@ skipping 161 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.
 
 ----------------------------------------------------------------------