Mixin DEP changes

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 \\
+\title{Dart Programming Language  Specification (Mixin DEP)\\
 {\large Version 1.10}}
 
 % 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}
 \maketitle
 \tableofcontents
 
@@ skipping 1985 matching lines @@
 % Need warnings if overrider conflicts with overriddee either because signatures are incompatible or because done is a method and one is a getter or setter.
 
 \section{Mixins}
 \LMLabel{mixins} 
 
 
 \LMHash{}
 A mixin describes the difference between a class and its superclass. A mixin is always derived from an existing class declaration. 
 
 \LMHash{}
-It is a compile-time error if a declared or derived mixin refers to \SUPER{}. It is a compile-time error if a declared or derived mixin explicitly declares a constructor. It is a compile-time error if a mixin is derived from a class whose superclass is not \code{Object}.
+It is a compile-time error if a declared or derived mixin explicitly declares a constructor. 
 
 \rationale{
 These restrictions are temporary.  We expect to remove them in later versions of Dart.
 
-The restriction on the use of \SUPER{} avoids the problem of rebinding \SUPER{} when the mixin is bound to difference superclasses.
-
 The restriction on constructors simplifies the construction of mixin applications because the process of creating instances is simpler.
-
-The restriction on the superclass means that the type of a class  from which a mixin is derived is always implemented by any class that mixes it in. This allows us to defer the question of whether and how to express the type of the mixin independently of its superclass and super interface types.
-
-Reasonable answers exist for all these issues, but their implementation is non-trivial.
 }
 
 \subsection{Mixin Application}
 \LMLabel{mixinApplication}
 
 \LMHash{}
 A mixin may be applied to a superclass, yielding a new class. Mixin application occurs when a mixin is mixed into a class declaration via its \WITH{} clause.  The mixin application may be used to extend a class per section (\ref{classes}); alternately, a class may be defined as a mixin application as described in this section.   It is a compile-time error if the \WITH{} clause of a mixin application $C$ includes a deferred type expression.
 
 
 \begin{grammar}
@@ skipping 33 matching lines @@
 
 \commentary{
 If, for example, $M$ declares an instance member $im$ whose type is at odds with the type of a member of the same name in $S$, this will result in a static warning just as if we had defined $K$ by means of an ordinary class declaration extending $S$, with a body that included $im$.
 
 }
 
 \LMHash{}
 The effect of a class definition of the form \code{\CLASS{} $C$ = $M$; } or the form 
  \code{\CLASS{} $C<T_1, \ldots, T_n>$ = $M$; } in library $L$  is to introduce the name $C$ into the scope of $L$, bound to the class (\ref{classes}) defined by the mixin application $M$. The name of the class is also set to $C$. Iff the  class is prefixed by the built-in identifier \ABSTRACT{}, the class being defined is an abstract class.
  
+ Let $M_A$ be a mixin derived from a class $M$ with direct superclass $S$.
+
+Let $A$ be an application of $M_A$. It is a static warning if the superclass of $A$ is not a subtype of $S$.

[eernst, 2015/06/23 15:45:03]

Maybe these two occurrences of $S$ should be changed to $S_{static}$ for
consistency with the other references to the declared superclass of a class used
as a mixin.

[gbracha, 2015/06/23 19:53:47]

It doesn't matter much as there is no question of a static vs. dynamic
distinction in this context, but sure.

+
+Let $C$ be a class declaration that includes $M_A$ in a with clause. It is a static warning if $C$ does not implement, directly or indirectly, all the direct superinterfaces of $M$.

[Lasse Reichstein Nielsen, 2015/06/23 08:06:23]

Does this need a `@proxy` exception too? That is, "... unless C, or one of its
super-interfaces, is annotated with the value of the `proxy` constant in the
dart:core library."

[gbracha, 2015/06/23 19:53:47]

Short answer: No.

Long answer:

For whatever dark historical reasons, @proxy controls warnings given on *usage*
of undefined members. Missing *declarations* are subject to other controls -
they are disabled if the class is abstract or has a non-trivial (i.e., no the
one from Object) noSuchMethod (which an @proxy class usually does). 

So the question would be whether there should be language about the concreteness
of C, or whether it has noSuchMethod etc.  Even then, my answer is negative.
This requirement is about declaring that C implements these interfaces - not
about whether it has specific methods. That is (or atelast, should be)  covered
elsewhere, under the blanket requirement that the expansion of the class, K,
should be legal.

+ 
 
 \subsection{Mixin Composition}
 \LMLabel{mixinComposition}
 
 \rationale{
 Dart does not directly support mixin composition, but the concept is useful when defining how the superclass of a class with a mixin clause is created.
 }
 
 \LMHash{}
 The {\em composition of two mixins}, $M_1<T_1 \ldots T_{k_{M_1}}>$ and $M_2<U_1  \ldots U_{k_{M_2}}>$, written $M_1<T_1 \ldots T_{k_{M_1}}> * M_2<U_1  \ldots U_{k_{M_2}}>$ defines an anonymous mixin such that for any class $S<V_1 \ldots V_{k_S}>$, the application of 
@@ skipping 1636 matching lines @@
 \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.
+If $C$ declares a concrete instance method named $m$ that is accessible to $L$,  then that method is the result of the lookup, and we say that the method was {\em looked up in $C$}. 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.

[eernst, 2015/06/23 15:45:03]

Would it be better to find all occurrences of 'superclass $S$' and similar
phrases, and change the $S$ to $S_{dynamic}$ or $S_{static}$ as appropriate, or
would that information always be present in the context anyway? ("Use 'dynamic'
when the topic is lookup, use 'static' when the topic is type checking"). Here,
it would be $S_{dynamic}$.

[gbracha, 2015/06/23 19:53:48]

Lasse made a similar comment for one specific case in the mixin text. I changed
it, even though I felt it was not really necessary because it is clear from
context.  It does seem to get out of control if we start fretting over this
everywhere.

 
 \rationale {
 The motivation for skipping abstract members during lookup is largely to allow smoother mixin composition. 
 }
 
 
 \subsubsection{ Getter and Setter Lookup}
 \LMLabel{getterAndSetterLookup}
 
 \LMHash{}
 The result of a lookup of a getter (respectively setter) $m$ in object $o$  with respect  to  library $L$ is the result of looking up getter (respectively setter) $m$ in class $C$ with respect to $L$, where $C$ is the class of $o$.
 
 \LMHash{}
 The result of a lookup of a getter (respectively setter) $m$ in class $C$  with respect to library $L$ is:
-If $C$ declares a concrete instance getter (respectively setter) named $m$  that is accessible to $L$,  then that getter (respectively setter) 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 getter (respectively setter) $m$ in $S$ with respect to $L$. Otherwise, we say that the lookup has failed.
+If $C$ declares a concrete instance getter (respectively setter) named $m$  that is accessible to $L$,  then that getter (respectively setter) is the result of the lookup, and we say that the getter (respectively setter) was {\em looked up in $C$}. Otherwise, if $C$ has a superclass $S$, then the result of the lookup is the result of looking up getter (respectively setter) $m$ in $S$ with respect to $L$. Otherwise, we say that the lookup has failed.
 
 \rationale {
 The motivation for skipping abstract members during lookup is largely to allow smoother mixin composition. 
 }
 
 
 \subsection{ Top level Getter Invocation}
 \LMLabel{topLevelGetterInvocation}
 
 \LMHash{}
@@ skipping 150 matching lines @@
 
 \LMHash{}
 A super method invocation $i$ has the form 
 
 $\SUPER{}.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
 Evaluation of $i$ proceeds as follows:
 
 \LMHash{}
-First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated  yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $S$ be the superclass of the immediately enclosing class, and let $f$ be the result of looking up method (\ref{methodLookup})  $m$ in $S$  with respect to the current library $L$. 
+First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated  yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up (\ref{methodLookup}). Let $S_{dynamic}$ be the superclass of $C$, and let $f$ be the result of looking up method (\ref{methodLookup})  $m$ in $S_{dynamic}$  with respect to the current library $L$. 

[Lasse Reichstein Nielsen, 2015/06/19 09:36:27]

This requires the lookup-class of a method to be remembered from the time it is
looked up to the time this code executes.
Even if the method is extracted.

So:
 class C {foo()=>42;}
 class M extends C { foo()=>super.foo(); }
 class A implements C {foo()=>37;}
 class AM = A with M;
 class X extends AM { foo() => 42;
                      get superFoo => super.foo; };
Then I do:
  var f = new X().superFoo;  // This closure knows that it was looked up in AM
(not X, not M).

It's a kind of hidden data channel between lookup and execution that isn't
explained anywhere else.
It might be easy enough to implement, but it sounds complicated :)

[eernst, 2015/06/23 15:45:03]

$S_{dynamic}$ seems to imply that the given class can be chosen at runtime; but
it's a compile time constant for a non-mixin, and for a mixin, for every mixin
application, the result is a class which is created at compile-time, and hence
the superclass is also fixed at compile-time.

Maybe it would make sense to use a terminology which allows for variability
without explicitly referring to runtime; how about using a plain $S$ and add
commentary mentioning that $S$ can be unknown at the location where the
expression \SUPER.m(..) is located?

A similar consideration would apply everywhere where $S_{dynamic}$ is
introduced. (It might also be helpful for readers, because $S_{dynamic}$ occurs
20 times on a range of 13 pages, and it is not immediately obvious why the
'dynamic' tag has been added to this class if the reader isn't already thinking
about mixins).

[eernst, 2015/06/23 15:45:03]

Actually, the method would be 'looked up in' the class where it is found, not
the one where the lookup started. This, I think, means that it is a property of
the method as such ("in which class is this method implementation declared?"),
and super.foo is looked up in M.

[gbracha, 2015/06/23 19:53:48]

It's easy if the implementation copies down methods with supercalls (as in the
VM, or Strongtalk). It's a bit harder if the super lookup is done dynamically
(you need as special lookup) and the real problem is when you have repeated
applications of the same  mixin in the same superclass chain.


BTW, f is not a closure in your example, but

var g = new  X()#superFoo 

is. But I don't see that it makes a difference. The key point is that the method
needs to (conceptually) know what *mixin* it was defined in and what *class* it
was looked up in.  See the issue raised by sra for DDC on the github repo for
this DEP.

[gbracha, 2015/06/23 19:53:48]

It's constant until you have dynamic mixin application :-)

[Lasse Reichstein Nielsen, 2015/06/24 12:16:10]

The result of doing super.foo in the X.superFoo getter is the closurization of
AM.foo, so I'm fairly sure it's an extracted closure and it was found in AM (M
is not in the superclass chain of X at all).

I guess the implementation is simple - a closure contains the instance, the
class that the method was found on and the method declaration. In this case
that's an X object, the AM class and the M.foo method declaration. The class is
used only for "super.*" lookups, the instance for "this" and the method
declaration is the code.

 Let $p_1 \ldots p_h$ be the required parameters of $f$,  let $p_1 \ldots p_m$ be the positional parameters of $f$ and let $p_{h+1}, \ldots, p_{h+l}$ be the optional parameters declared by $f$.

[Lasse Reichstein Nielsen, 2015/06/19 09:36:27]

This seems to assume that $f$ is found.
How about:
 class C {foo()=>42;}
 class M extends C { foo()=>super.foo(); }
 abstract class A implements C {}
 class AM = A with M;

Then the superclass of AM is A, and the super.foo() call will look up "foo" in
"A" and fail. Then you can't talk about the required parameters yet.
(That may not be related to this change though, I think it could also be absent
before? Maybe this paragraph just needs to be prefixed with "If the lookup
succeeded,")

[gbracha, 2015/06/23 19:53:48]

Yes, this assumes that other lookup failures are handled somehow. It should
probably be prefixed as you say. There are probably other such cases. None of
which relate to this CL in particular.

 
 \LMHash{}
 If  $n < h$, or $n > m$, the method lookup has failed. Furthermore, each $x_i, n+1 \le i \le n+k$,  must have a corresponding named parameter in the set $\{p_{m+1}, \ldots, p_{h+l}\}$ or the method lookup also fails.  Otherwise method lookup has succeeded.
 
 \LMHash{}
 If the method lookup succeeded, the body of $f$ is executed with respect to the bindings that resulted from the evaluation of the argument list, and with \THIS{} bound to the current value of \THIS{}. The value of $i$ is the value returned after $f$ is executed.
 
 \LMHash{}
-If the method lookup has failed, then let $g$ be the result of looking up getter (\ref{getterAndSetterLookup}) $m$ in $S$ with respect to $L$. If the getter lookup succeeded, let $v_g$ be the value of the getter invocation $\SUPER{}.m$. Then the value of $i$ is the result of invoking 
-the static method \code{Function.apply()} with arguments $v.g, [o_1, \ldots , o_n], \{x_{n+1}: o_{n+1}, \ldots , x_{n+k}: o_{n+k}\}$.
+If the method lookup has failed, then let $g$ be the result of looking up getter (\ref{getterAndSetterLookup}) $m$ in $S_{dynamic}$ with respect to $L$. If the getter lookup succeeded, let $v_g$ be the value of the getter invocation $\SUPER{}.m$. Then the value of $i$ is the result of invoking 
+the static method \code{Function.apply()} with arguments $v_g, [o_1, \ldots , o_n], \{x_{n+1}: o_{n+1}, \ldots , x_{n+k}: o_{n+k}\}$.
  
 \LMHash{}
 If  getter lookup has also failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
 \begin{itemize}
 \item  \code{im.isMethod} evaluates to \code{\TRUE{}}.
 \item  \code{im.memberName} evaluates to the symbol \code{m}.
 \item \code{im.positionalArguments} evaluates to an immutable list with the same  values as  \code{[$o_1, \ldots, o_n$]}.
 \item \code{im.namedArguments} evaluates to an immutable map with the same keys and values as \code{\{$x_{n+1}: o_{n+1}, \ldots, x_{n+k} : o_{n+k}$\}}.
 \end{itemize}
-Then the method \code{noSuchMethod()} is looked up in $S$ and invoked on \THIS{} with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
+Then the method \code{noSuchMethod()} is looked up in $S_{dynamic}$ and invoked on \THIS{} with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
 \item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
 \item  \code{im'.memberName} evaluates to \code{\#noSuchMethod}.
 \item \code{im'.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
 \item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
 
 and the result of this latter invocation is the result of evaluating $i$.
 
 
 \LMHash{}
 It is a compile-time error if a super method invocation occurs in a top-level function or variable initializer, in an instance variable initializer or initializer list, in class \code{Object}, in a factory constructor or in a static method or variable initializer.
 
 \LMHash{}
-It is a static type warning if $S$ does not have an accessible (\ref{privacy}) instance member named $m$ unless $S$ or a superinterface of $S$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. If $S.m$ exists, it  is a static type warning if the type $F$ of $S.m$ may not be assigned to a function type. If $S.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$.  
+Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible (\ref{privacy}) instance member named $m$ unless $S_{static}$ or a superinterface of $S_{static}$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. If $S_{static}.m$ exists, it  is a static type warning if the type $F$ of $S_{static}.m$ may not be assigned to a function type. If $S_{static}.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$.  

[eernst, 2015/06/23 15:45:03]

Looking at this again, it does make a lot of sense to talk about $S_{dynamic}$
vs. $S_{static}$ (except that 'static' is terribly ambiguous) when
distinguishing method lookup vs. type checking. So maybe it's the best choice
after all. ;-)

[gbracha, 2015/06/23 19:53:47]

Not sure if you're agreeing with me or not. I'll assume you are, as that is
always the right thing to do :-)

 % The following is not needed because it is specified in 'Binding Actuals to Formals"
 %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$.
 
 
 
 
 \subsubsection{Sending Messages}
 \LMLabel{sendingMessages}
 
 \LMHash{}
@@ skipping 94 matching lines @@
 \end{itemize}
 
 
 \subsubsection{Super Getter Access and Method Closurization}
 \LMLabel{superGetterAccessAndMethodClosurization}
 
 \LMHash{}
 Evaluation of a property extraction $i$ of the form $\SUPER.m$ proceeds as follows:
 
 \LMHash{}
- Let $S$ be the superclass of the immediately enclosing class. Let $f$ be the result of looking up method $m$ in $S$ with respect to the current library $L$.  If method lookup succeeds then $i$ evaluates to the closurization of method $f$ with respect to superclass $S$ (\ref{superClosurization}).  
+Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. Let $f$ be the result of looking up method $m$ in $S_{dynamic}$ with respect to the current library $L$.  If method lookup succeeds then $i$ evaluates to the closurization of method $f$ with respect to superclass $S_{dynamic}$ (\ref{superClosurization}).  
  
 \LMHash{}
- Otherwise, $i$ is a getter invocation.  Let $f$ be the result of  looking up getter $m$ in $S$  with respect to $L$.  The body of $f$  is executed with \THIS{} bound to the current value of  \THIS{}.  The value of $i$ is the result returned by the call to the getter function. 
+ Otherwise, $i$ is a getter invocation.  Let $f$ be the result of  looking up getter $m$ in $S_{dynamic}$  with respect to $L$.  The body of $f$  is executed with \THIS{} bound to the current value of  \THIS{}.  The value of $i$ is the result returned by the call to the getter function. 
 
 \LMHash{}
 If the getter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
 \begin{itemize}
 \item  \code{im.isGetter} evaluates to \code{\TRUE{}}.
 \item  \code{im.memberName} evaluates to the symbol \code{m}.
 \item \code{im.positionalArguments} evaluates to the value of \code{\CONST{} []}.
 \item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
-Then the method \code{noSuchMethod()} is looked up in $S$ and invoked  with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
+Then the method \code{noSuchMethod()} is looked up in $S_{dynamic}$ and invoked  with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
 \item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
 \item  \code{im'.memberName} evaluates to \code{\#noSuchMethod}.
 \item \code{im'.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
 \item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
 and the result of this latter invocation is the result of evaluating $i$.
 
 \LMHash{}
-It is a static type warning if $S$ does not have an accessible instance method or getter named $m$.  
+Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible instance method or getter named $m$.  

[Lasse Reichstein Nielsen, 2015/06/19 09:36:27]

Will this method be concrete, or can an abstract method satisfy this requirement
as written?

[gbracha, 2015/06/23 19:53:47]

(1) This has nothing to do with this CL; it has to do with tear-offs in general.
(2) This is where we should be thinking about @proxy!
(3) Abstract methods are fine (to finally answer the question). Of course, the
abstract method will not be found  during lookup, but for typechecking purposes 
we assume that a concrete method should be introduced.

 
 The static type of $i$ is:
 \begin{itemize}
-\item The declared return type of $S.m$, if $S$ has an accessible instance getter named $m$.
-\item The static type of function $S.m$ if $S$ has an accessible instance method named $m$.
+\item The declared return type of $S_{static}.m$, if $S_{static}$ has an accessible instance getter named $m$.
+\item The static type of function $S_{static}.m$ if $S_{static}$ has an accessible instance method named $m$.
 \item The type  \DYNAMIC{} otherwise. 
 \end{itemize}
 
 
 \subsubsection{General Closurization}
 \LMLabel{generalClosurization}
 
 \LMHash{}
 Evaluation of a property extraction $i$ of the form $e\#m$ proceeds as follows:
 
@@ skipping 88 matching lines @@
 The static type of $i$ is the type of the constructor function $T()$, if $T$ denotes a class in the surrounding scope with an anonymous constructor $T()$. Otherwise the static type of $i$ is \DYNAMIC{}.
 
 \subsubsection{General Super Property Extraction}
 \LMLabel{generalSuperPropertyExtraction}
 
 
 \LMHash{}
 Evaluation of a property extraction $i$ of the form \SUPER$\#m$ proceeds as follows:
 
  \LMHash{}
-Let $S$ be the superclass of the immediately enclosing class.
+Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. Let $S_{dynamic}$ be the superclass of the $C$.

[eernst, 2015/06/23 15:45:03]

Last sentence duplicated.

[gbracha, 2015/06/23 19:53:47]

It's idempotent :-). Fixed.

 
  \LMHash{}
-If $m$ is a setter name, let $f$ be the result of looking up setter $m$ in $S$ with respect to the current library $L$. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$  with respect to superclass $S$  (\ref{superClosurization}).  If setter lookup failed, a \cd{NoSuchMethodError} is thrown.
+If $m$ is a setter name, let $f$ be the result of looking up setter $m$ in $S_{dynamic}$ with respect to the current library $L$. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$  with respect to superclass $S_{dynamic}$  (\ref{superClosurization}).  If setter lookup failed, a \cd{NoSuchMethodError} is thrown.
 
-If $m$ is not a setter name, let $f$ be the result of looking up method $m$ in $S$ with respect to the current library $L$. If method lookup succeeds then $i$ evaluates to the closurization of method $m$ with respect to superclass $S$ (\ref{superClosurization}).
+If $m$ is not a setter name, let $f$ be the result of looking up method $m$ in $S_{dynamic}$ with respect to the current library $L$. If method lookup succeeds then $i$ evaluates to the closurization of method $m$ with respect to superclass $S_{dynamic}$ (\ref{superClosurization}).
 
 \LMHash{}
- Otherwise, let $f$ be the result of looking up getter $m$ in $S$ with respect to the current library $L$.  If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ with respect to superclass $S$ (\ref{superClosurization}).   If getter lookup failed, a \cd{NoSuchMethodError} is thrown.
+ Otherwise, let $f$ be the result of looking up getter $m$ in $S_{dynamic}$ with respect to the current library $L$.  If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ with respect to superclass $S_{dynamic}$ (\ref{superClosurization}).   If getter lookup failed, a \cd{NoSuchMethodError} is thrown.
 
 \LMHash{}
-It is a static type warning if $S$ does not have an accessible instance member named $m$.
+Let $S_{static}$ be the superclass of the immediately enclosing class.It is a static type warning if $S_{static}$ does not have an accessible instance member named $m$.
 
 \LMHash{}
-The static type of $i$ is the static type of the function $S.m$,  if $S$ has an accessible instance member named $m$. Otherwise the static type of $i$ is \DYNAMIC{}.
+The static type of $i$ is the static type of the function $S_{static}.m$,  if $S_{static}$ has an accessible instance member named $m$. Otherwise the static type of $i$ is \DYNAMIC{}.
 
 
 
 \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:
@@ skipping 241 matching lines @@
 
 
 
 \LMHash{}
 It is a static type warning if the static type of $e_2$ may not be assigned to the static type of the formal parameter of the setter $v=$.   The static type of the expression $e_1.v$ \code{=} $e_2$ is the static type of $e_2$.
 
 \LMHash{}
 Evaluation of an assignment of the form $\SUPER.v$ \code{=} $e$ proceeds as follows:
 
 \LMHash{}
-Let $S$ be the superclass of the immediately enclosing class.
-The expression $e$ is evaluated to an object $o$.  Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $S$ with respect to the current library.  The body  of $v=$ is executed with its formal parameter bound to $o$ and \THIS{} bound to \THIS{}. 
+Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. 
+The expression $e$ is evaluated to an object $o$.  Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $S_{dynamic}$ with respect to the current library.  The body  of $v=$ is executed with its formal parameter bound to $o$ and \THIS{} bound to \THIS{}. 
 
 \LMHash{}
 If the setter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
 \begin{itemize}
 \item  \code{im.isSetter} evaluates to \code{\TRUE{}}.
 \item  \code{im.memberName} evaluates to the symbol \code{v=}.
 \item \code{im.positionalArguments} evaluates to an immutable list with the same values as \code{[$o$]}.
 \item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
 
 \LMHash{}
-Then the method \code{noSuchMethod()} is looked up in $S$ and invoked  with argument $im$. 
+Then the method \code{noSuchMethod()} is looked up in $S_{dynamic}$ and invoked  with argument $im$. 
 However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
 \item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
 \item  \code{im'.memberName} evaluates to \code{\#noSuchMethod}.
 \item \code{im'.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
 \item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
 
 \LMHash{}
 The value of the assignment expression is $o$ irrespective of whether setter lookup has failed or succeeded.
 
 \LMHash{}
 In checked mode, it is a dynamic type error if $o$ is not \NULL{} and the interface of the class of $o$ is not a subtype of the actual type of $S.v$.
 
 \LMHash{}
-It is a static type warning if $S$ does not have an accessible instance setter named $v=$ unless $S$ or a superinterface of $S$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. 
+Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible instance setter named $v=$ unless $S_{static}$ or a superinterface of $S_{static}$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. 
 
 \LMHash{}
 It is a static type warning if the static type of $e$ may not be assigned to the static type of the formal parameter of the setter $v=$.   The static type of the expression $\SUPER.v$ \code{=} $e$ is the static type of $e$.
 
 
 
 
 
 
 \LMHash{}
@@ skipping 3310 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.
 
 ----------------------------------------------------------------------