Changes for TC52 3rd edition

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 19 matching lines @@
 \LMHash{}
 This Ecma standard specifies the syntax and semantics of the Dart programming language.  It does not specify the APIs of the Dart libraries except where those library elements are essential to the correct functioning of the language itself (e.g., the existence of class \cd{Object} with methods such as \cd{noSuchMethod}, \cd{runtimeType}).
 
 \section{Conformance}
 \LMLabel{ecmaConformance}
 
 \LMHash{}
 A conforming  implementation of the Dart programming language must provide and support all the  APIs (libraries, types, functions, getters, setters, whether top-level, static, instance or local) mandated in this specification. 
 
 \LMHash{}
-A conforming implementation is permitted to provide additional APIs, but not additional syntax.
+A conforming implementation is permitted to provide additional APIs, but not additional syntax, except for experimental features in support of null-aware cascades and tear-offs that are likely to be introduced in the next revision of this specification.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Clever :)

[eernst, 2015/03/26 22:38:50]

I guess 'property extraction' covers more than intended, but 'tear-offs' might
require a definition since it is a new term in the specification.

 
 \section{Normative References}
 \LMLabel{ecmaNormativeReferences}
 
 \LMHash{}
 The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
 
 \begin{enumerate}
 \item
 The Unicode Standard, Version 5.0, as amended by Unicode 5.1.0, or successor.
@@ skipping 2291 matching lines @@
     .
 \end{grammar}    
 
 \begin{grammar}
 {\bf primary:}thisExpression;
       \SUPER{} assignableSelector;
       functionExpression;
       literal;
       identifier;
       newExpression;
+      \NEW{} type `\#' (`{\escapegrammar .}' identifier)?;
+      \CONST{} type `\#' (`{\escapegrammar .}' identifier)?;

[Paul Berry, 2015/03/26 18:55:58]

What's the justification for having tear-offs of both the form "new type#" and
"const type#"?  I don't see any semantic difference between the two syntaxes.

[Lasse Reichstein Nielsen, 2015/03/26 19:18:57]

Ack, yes, forgot to comment on that.
If there is no difference between the two, I'd prefer to not have the const
version. It looks like the "const" means something, which it doesn't.

If "const Foo#bar" was a compile-time constant expression, it would make sense,
but I don't see any changes to the constant section.
Also, there is no reason to not make "new Foo#bar" a compile-time constant, and
in that case the const version should again be dropped.

Which also reminds me: MyClass.staticMethod is a compile time constant, should
MyClass#staticMethod (or getter/setter) also be constant?

[eernst, 2015/03/26 22:38:51]

Did you have to add the periods here to make the grammar parseable?  I don't see
them in earlier documentation about the tear-offs (e.g.,
https://github.com/gbracha/generalizedTearOffs/blob/master/proposal.md).

[gbracha, 2015/03/26 23:21:22]

You mean we haven't stated that a const T# is a constant constructor?

       constObjectExpression;
       `(' expression `)'
     .
     
 \end{grammar}   
 
 \LMHash{}
 An expression $e$ may always be enclosed in parentheses, but this never has any semantic effect on $e$.
 
 \commentary{
@@ skipping 1156 matching lines @@
   \item If $s$ has been canceled then its cancellation future is completed with $x$ as an error.
   \end{itemize}
 \item $s$ is closed.
 \end{itemize}
 
 \rationale{
 When an asynchronous generator's stream has been canceled, cleanup will occur in the \FINALLY{} clauses (\ref{try}) inside the generator. We choose to direct any exceptions that occur at this time to the cancellation future rather than have them be lost. 
 }
 
 \LMHash{}
-If $f$ is asynchronous then, when $f$ terminates, any open stream subscriptions associated with any asynchronous for loops  (\ref{asynchronousFor-in}) or yield-each statements  (\ref{yieldEach}) executing within $f$ are canceled.
+If $f$ is asynchronous then, when $f$ terminates, any open stream subscriptions associated with any asynchronous for loops  (\ref{asynchronousFor-in}) or yield-each statements  (\ref{yieldEach}) executing within $f$ are canceled, in the order of their nesting, innermost first.
 
 \rationale{Such streams may be left open by for loops that were escaped when an exception was thrown within them for example.
 }
 
+%\LMHash{}
+%When a stream is canceled, the implementation must wait for the cancelation future returned by \cd{cancell()} to complete before proceeding.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Uncomment?
Also maybe: "stream is canceled" -> "stream subscription associated with a
\code{yield*} or \code{await for} loop is canceled"

[gbracha, 2015/03/26 23:21:22]

The VM team has concerns with this. If it's absence is a bug, it has been there
since the initial version. I'm leaving as is until we are clear on that point.

+
 \LMHash{}
 If $f$ is marked \SYNC* (\ref{functions}), then a fresh instance $i$ implementing the built-in class \code{Iterable} is associated with the invocation and immediately returned.  
 
 
 \commentary{
 A Dart implementation will need to provide a specific implementation of \code{Iterable} that will be returned by \SYNC* methods. A typical strategy would be to produce an instance of a subclass of class \code{IterableBase} defined in \code{dart:core}. The only method that needs to be added by the Dart implementation in that case is \code{iterator}.  
 }
 
 \LMHash{}
 The iterable implementation must comply with the contract of \code{Iterable} and should not take any steps identified as exceptionally efficient in that contract.
@@ skipping 146 matching lines @@
 
 
 \subsubsection{ Function Expression Invocation}
 \LMLabel{functionExpressionInvocation}
 
 \LMHash{}
 A function expression invocation $i$ has the form 
 
 $e_f(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$, 
 
 where $e_f$ is an expression. If $e_f$ is an identifier $id$, then $id$ must necessarily denote a local function, a library function, a library or static getter or a variable as described above, or $i$ is not considered a function expression invocation. If $e_f$ is a property extraction expression (\ref{propertyExtraction}), then $i$ is is not a function expression invocation and is instead recognized as an ordinary method invocation (\ref{ordinaryInvocation}). 

[Paul Berry, 2015/03/26 15:07:21]

We need to clarify that the last sentence applies both to expressions of the
form "e.m" and of the form "e?.m".  (Currently "property extraction" is defined
only using the '.' operator, so by a strict reading, "e?.m(...)" would be parsed
as a function expression invocation, which is not what we want).

Suggestion: modify the "property extraction" section to allow property
extractions to be either conditional or unconditional (in much the same way that
the "ordinary method invocation" section is being modified).  Then move the
evaluation rule for "e?.id" from line 4996 to somewhere in the "property
extraction" section.  In addition to fixing the parsing of "e?.m(...)", this
would have the advantage of clarifying that the warnings defined in the
"property extraction" section apply to uses of '?.'.

[gbracha, 2015/03/26 23:21:22]

Yes, I think that is a good idea. Done.

 
 \commentary{
 \code{$a.b(x)$} is parsed as a method invocation of method \code{$b()$} on object \code{$a$}, not as an invocation of getter \code{$b$} on \code{$a$} followed by a function call \code{$(a.b)(x)$}.  If a method or getter \code{$b$} exists, the two will be equivalent. However, if \code{$b$} is not defined on \code{$a$}, the resulting invocation of \code{noSuchMethod()} would differ.  The \code{Invocation} passed to \code{noSuchMethod()} would describe a call to a method \code{$b$} with argument \code{$x$} in the former case, and a call to a getter \code{$b$} (with no arguments) in the latter.
 }
 
 \LMHash{}
 Otherwise:
 
 A function expression invocation $e_f(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is equivalent to $e_f.call(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
@@ skipping 58 matching lines @@
 \subsection{ Method Invocation}
 \LMLabel{methodInvocation}
 
 \LMHash{}
 Method invocation can take several forms as specified below. 
 
 \subsubsection{Ordinary Invocation}
 \LMLabel{ordinaryInvocation}
 
 \LMHash{}
-An ordinary method invocation $i$ has the form 
+An ordinary method invocation can be {\em conditional} or {\em unconditional}.
+
+\LMHash{}
+Evaluation of a {\em conditional ordinary method invocation} $e$ of the form 
+
+\LMHash{}
+$o?.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$  
+
+\LMHash{}
+is equivalent to the evaluation of the expression  
+
+\LMHash{}
+$((x) => x == \NULL ? \NULL : x.im(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k}))(o)$. 

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

x.im -> x.m

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Does this correctly give static warnings if o.m does not have the correct type,
because "x" here is dynamic so x.m(...) would not give warnings if looking only
at the rewritten version.

Could it be written as:
  $((T x) => x == .....)(o)$
  where $T$ is the static type of $o$
? 

[Paul Berry, 2015/03/26 15:07:21]

Unfortunately Lasse's proposed rewrite would introduce an additional type check
in checked mode which I think would be confusing, since the user is going to
expect that the only difference between "?." and "." is the null check.  (It's
possible to construct programs that run in checked mode without throwing an
exception, but which nonetheless contain an expression whose runtime type is
unrelated to its static type).

I think the CL is ok as is, since line 3786 says that we're only rewriting
o?.m(...) for evaluation purposes, and line 3798 explicitly specifies the static
type of o?.m(...).

[gbracha, 2015/03/26 23:21:21]

Done.

[gbracha, 2015/03/26 23:21:23]

No, because checked mode would behave differently. Need to deal with warnings
separately. I have adjusted the text in 16.18 and 16.17.1 accordingly.

+
+\LMHash{}
+The static type of $e$ is the same as the static type of $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
+
+\LMHash{}
+An {\em unconditional ordinary method invocation} $i$ has the form 
 
 $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
-Evaluation of an ordinary method invocation $i$ of the form 
+Evaluation of an unconditional ordinary method invocation $i$ of the form 
 
 $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
 
 proceeds as follows:
 
 \LMHash{}
 First, the expression $o$ is evaluated to a value $v_o$. Next, 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 $f$ be the result of looking up (\ref{methodLookup}) method $m$  in $v_o$ with respect to the current library $L$. 
 
 \LMHash{}
 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$.
@@ skipping 45 matching lines @@
 \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$.

[Paul Berry, 2015/03/26 15:07:21]

Considering the commentary you've added at line 4999, I'm assuming your
intention is that:

class C {
  static f() { ... }
}
main () {
  C?.f();
}

should produce a NoSuchMethodError at runtime.

Assuming that is true, then we should also change this line to read "\item  $T$
is \code{Type}, $e$ is a constant type literal, $i$ is an unconditional ordinary
method invocation, and the class corresponding to $e$ has a static getter named
$m$."

That way the code above will produce a static warning.

Note: a similar change is probably needed to ensure that "C?.x" produces a
warning, where x is a static getter/setter in the class C.  I'm not sure where
that change needs to go--it probably depends whether you accept my suggestions
about what to do with the "property extraction" section :)

[gbracha, 2015/03/26 23:21:22]

The intent was that it would produce a static warning by virtue of the
translation, but of course that is flawed because the translation is only used
for dynamic evaluation.  I think the new wording at the beginning of 16.18 and
16.17.1 covers things.

 \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 $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 {\em e..suffix}
 where $e$ is an expression and {\em suffix} is a sequence of operator, method, getter or setter invocations.
 
 \begin{grammar}
 {\bf cascadeSection:}
       `{\escapegrammar ..}' (cascadeSelector arguments*) (assignableSelector arguments*)* (assignmentOperator expressionWithoutCascade)?
       .
      
 {\bf cascadeSelector:}`['  expression `]';
       identifier
       .
 \end{grammar}
 
 \LMHash{}
 A cascaded method invocation expression of the form {\em e..suffix} is equivalent to the expression \code{(t)\{t.{\em suffix}; \RETURN{} t;\}($e$)}.
 
+\rationale{
+With the introduction of null-aware conditional assignable expressions (\ref{assignableExpressions}), it would make sense to extend cascades with a null-aware conditional form as well. One might define {\em e?..suffix}  to be equivalent to the expression \code{(t)\{t?.{\em suffix}; \RETURN{} t;\}($e$)}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Makes sense. We have cascades so you can write x..foo..bar; instead of
x.foo;x.bar;. Would be sad to have to go back to x?.foo;x?.bar; because of lack
of x?..foo?..bar

[eernst, 2015/03/26 22:38:51]

Having x?..foo?..bar it's natural to consider x?..foo..bar and x..foo?..bar. 
Only the "?-everywhere" and "?-nowhere" variants seem to make sense, because
either the ? is "unused", or the cascade section with no ? will unconditionally
fail.  So maybe the syntax should enforce that only everywhere/nowhere in
possible.

+
+The present specification has not added such a construct, in the interests of simplicity and rapid language evolution. However, Dart implementations may experiment with such constructs, as noted in section \ref{ecmaConformance}.
+}
+
 \subsubsection{Super Invocation}
 \LMLabel{superInvocation}
 
 \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:
@@ skipping 50 matching lines @@
 
 \commentary{In other words, the methods supporting sending messages embody primitives of Dart that are not accessible to ordinary code, much like the methods that spawn isolates.
 }
 
 
 
 \subsection{ Property Extraction}
 \LMLabel{propertyExtraction}
 
 \LMHash{}
-{\em Property extraction} allows for a member of an object to be concisely extracted from the object.
+{\em Property extraction} allows for a member or constructor to be accessed as a property rather than a function.
 A property extraction can be either:
 \begin{enumerate}
-\item A {\em closurization} (\ref{closurization}) which allows a method to be treated as if it were a getter for a function valued object. Or
+\item A {\em closurization} which converts a method or constructor into a closure. Or
 \item A {\em getter invocation} which returns the result of invoking of a getter method.
 \end{enumerate}
 
 \LMHash{}
+Property extraction takes several syntactic forms: $e.m$ (\ref{getterAccessAndMethodExtraction}), $\SUPER.m$ (\ref{superGetterAccessAndMethodClosurization}), $e\#m$ (\ref{generalClosurization}), $\NEW{}$ $T\#m$ (\ref{namedConstructorExtraction}), $\NEW{}$ $T\#$ (\ref{anonymousConstructorExtraction}) and $\SUPER\#m$ (\ref{generalSuperPropertyExtraction}), where $e$ is an expression, $m$ is an identifier optionally followed by an equal sign and $T$ is a type.

[Paul Berry, 2015/03/26 15:07:21]

As I mentioned on line 3704, I think the syntactic forms "e?.m" and "super?.m"
also need to be covered, so that warnings defined in this section will apply to
expressions of these forms.

[gbracha, 2015/03/26 23:21:22]

super?.m makes no sense; I've altered the grammar to ban that. e?.m is now
covered.

+
+\subsubsection{Getter Access and Method Extraction}
+\LMLabel{getterAccessAndMethodExtraction}
+
+\LMHash{}
 Evaluation of a property extraction $i$ of the form $e.m$ proceeds as follows:
 
 \LMHash{}
-First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up (\ref{methodLookup}) method  (\ref{instanceMethods}) $m$ in $o$ with respect to the current library $L$.  If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $m$ is a method that forwards (\ref{functionDeclarations}) to a static method,  method lookup fails. If method lookup succeeds and $f$ is a concrete method then $i$ evaluates to the closurization of $o.m$.  
+First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up (\ref{methodLookup}) method  (\ref{instanceMethods}) $m$ in $o$ with respect to the current library $L$.  If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards (\ref{functionDeclarations}) to a static method,  method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+
+\commentary {
+Note that $f$ is never an abstract method, because method lookup skips abstract methods. Hence, if $m$ refers to an abstract method, we will continue to the next step. However, since methods and getters never override each other, getter lookup will necessarily fail as well, and \cd{noSuchMethod()} will ultimately be invoked. The regrettable implication is that the error will refer to a missing getter rather than an attempt to closurize an abstract method.
+}
 
 \LMHash{}
-Otherwise, $i$ is a getter invocation, and the getter function (\ref{getters}) $m$ is looked up (\ref{getterAndSetterLookup}) in $o$  with respect to $L$. If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $m$ is a getter that forwards  to a static getter,  getter lookup fails. Otherwise, the body of $m$ is executed with \THIS{} bound to $o$.  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
+(\ref{getterAndSetterLookup}) getter (\ref{getters}) $m$ in $o$  with respect to $L$. If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a getter that forwards  to a static getter,  getter lookup fails. Otherwise, the body of $f$ is executed with \THIS{} bound to $o$.  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 \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 $o$ 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 $o$ 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{} \{\}}.
+\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 $m$ is a member of class \cd{Object} and $e$ is either a prefix object (\ref{imports}) or a constant type literal.
 
 \commentary {
 This precludes \code{int.toString} but not \code{(int).toString} because in the latter case, $e$ is a parenthesized expression.
 }
 
 \LMHash{}
 Let $T$ be the  static type of $e$. It is a static type warning if $T$ does not have a method or getter 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 method or getter named $m$.
 \end{itemize}
 
 \LMHash{}
-If $i$ is a getter invocation, the static type of $i$ is:
+The static type of $i$ is:
 \begin{itemize}
-\item The declared return type of $T.m$, if $T.m$ exists.
-\item The declared return type of $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ has a static method or getter named $m$.
+\item The declared return type of $T.m$, if $T$  has an accessible instance getter named $m$.
+\item The declared return type of $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static getter named $m$.
+\item The static type of function $T.m$ if $T$ has an accessible instance method named $m$.
+\item The static type of function $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static method named $m$.
 \item  The type \DYNAMIC{} otherwise.  
 \end{itemize}
 
-\LMHash{}
-If $i$ is a closurization, its static type is as described in section \ref{closurization}.
+
+\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 $f$ is a concrete method then $i$ evaluates to the closurization of $\SUPER.m$ with respect to superclass $S$(\ref{closurization}).  
+ 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}).  
  
 \LMHash{}
- Otherwise, $i$ is a getter invocation and the getter function $m$ is looked up in $S$  with respect to $L$, and its body 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$  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 \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 :
 \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{} \{\}}.
+\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 a method or getter named $m$.  If $i$ is a getter invocation, the static type of $i$ is the declared return type of $S.m$, if $S.m$ exists and  \DYNAMIC{} otherwise. If $i$ is a closurization, its static type is as described in section \ref{closurization}.
+It is a static type warning if $S$ does not have an accessible instance method or getter named $m$.  
+
+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 type  \DYNAMIC{} otherwise. 
+\end{itemize}
 
 
-\subsubsection{Closurization}
-\LMLabel{closurization}
+\subsubsection{General Closurization}
+\LMLabel{generalClosurization}
 
 \LMHash{}
-The {\em closurization of $o.m$} is defined to be equivalent to:
+Evaluation of a property extraction $i$ of the form $e\#m$ proceeds as follows:
 
+\LMHash{}
+First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up method $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static method, method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+ 
+\LMHash{}
+ Otherwise, let $f$ be the result of looking up getter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static getter, getter lookup fails. If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+ 
+ \LMHash{}
+ Otherwise, let $f$ be the result of looking up setter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static setter, setter lookup fails. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

So we technically go through the previous two lookups for the the name "m=",
even if we know syntactically that they can't succeed?
How about splitting on that at the top:
 if m is not a setter name then
  - method lookup
  - getter lookup
 else if m is a setter name then
  - setter lookup
?
I think I'd find that less confusing.

[sra1, 2015/03/26 19:41:38]

It seems that this would be simpler if the closurization site made explicit
whether a tear-off getter, setter or method was required.

e#foo
  - a field access or tear off method

e#get foo
  - Closurizer the getter. Always returns a function taking zero arguments.
Closurizes the implicit getter of a field or the closurizing getter of a method.


e#set foo
  - Closurizes the setter.  Always returns a function taking exactly one
argument.

[gbracha, 2015/03/26 23:21:22]

Yes, I think splitting it makes a lot of sense, for this and other reasons.
Done.

+ 
+
+\LMHash{}
+Otherwise,  a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
 \begin{itemize}
+\item  If $m$ is a setter name, \code{im.isSetter} evaluates to \code{\TRUE{}}; otherwise \code{im.isMethod} evaluates to \code{\TRUE{}}

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

I still think this is dangerously wrong, and must not be released in its current
form.

A noSuchMethod implementation seeing "im.isMethod" will assume that it is a
method call and may emulate the call with zero arguments, which is wrong.
It would actually want to return a function to correctly emulate the extraction.

Similarly, seeing "isSetter" as true but with zero positional parameters is
breaking the invariant on Invocation. The documentation of Invocation.isSetter
says:
   * Whether the invocation was a setter call.
   *
   * If so, [arguments] has exactly one positonal argument,
   * and [namedArguments] is empty.
The invocation object created here is simply invalid, and should not be created
or be passed to any existing code.


I'd actually prefer to not go through the object's noSuchMethod at all, and just
throw a NoSuchMethodError directly until we can find a way to make it
interceptable without being wrong. The current approach should *not* be
launched, it's just too broken.

[sra1, 2015/03/26 19:41:38]

I think this would also be fixed by e#foo / e#get foo / e#set foo.

[Lasse Reichstein Nielsen, 2015/03/26 20:23:23]

I don't see how that would change anything. There is no reasonable way to send
an Invocation to a noSuchMethod method corresponding to extracting a setter,
whether it's written e#foo= or e#set foo.

[gbracha, 2015/03/26 23:21:22]

Good point. Indeed, existing tear-offs using the e.m syntax already have this
problem, though no one has noticed so far. Long term, I think we need to extend
noSuchMethod with an #isTearOff flag.  I would not change the e.m tear-off
behavior, but e#m would then set the flag. Presumably, no working code would
notice the difference (I'll neglect any crazies who catch NoSuchMethodError).
Yes, but if I split the cases I could have it pass a dummy argument. But the
point above remains.

The documentation of Invocation.isSetter
Well, we launched the same broken semantics years ago :-) But I agree.

[Lasse Reichstein Nielsen, 2015/03/27 07:03:04]

The existing extraction works because of the correspondence between a function
and a function-typed getter - if can try to "get" or "call" a name, and the
noSuchMethod can distinguish the two and simulate its choice of field or method.
You could even have said that a method introduces a synthetic getter which
returns the extracted function, so "o.foo" accesses would always use a getter.

It breaks down only for the new extraction of getters and setters because we get
a third way to access a name, and Invocation has no way to represent that. An
existing noSuchMethod implementation cannot correctly simulate a getter because
extracting a getter is a completely new thing (but extracting a function isn't).

In this way, o#foo is actually slightly worse than the existing tear-off because
it does does not treat function-typed getters and methods the same - the former
returns a function that must be called to get the value, the latter just returns
the value. That's OK because the language has always been saying that a function
typed getter and a function are quite different (one can't override the other).

Sadly, even if we add an isTearOff flag to the Invocation, it will still make
existing code behave incorrectly if it sees such an invocation because it
doesn't check for that flag or implement it. We may want it anyway (it's not
*breaking* because no existing program will stop working, but existing libraries
may not be compatible with new code).

+\item  \code{im.memberName} evaluates to \code{'m'}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

This looks like it evaluates to a string, but it should evaluate to a symbol.
Either:
  evaluates to the symbol \code{m}.
or 
  evaluates to \code{\#m}.
?

[gbracha, 2015/03/26 23:21:22]

A bug that has been lying dormant for a while. Fixed in all locations.

+\item \code{im.positionalArguments} evaluates to the value of \code{\CONST{} []}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Are we requiring "const []" in other places too? Otherwise I think it might be
overspecifying since it is detectable whether the value really is const [] or
some othe empty fixed-length array, and you don't need it to be that specific
object.

[eernst, 2015/03/26 22:38:50]

Why not \code{\CONST{} <Object>[]}, such that List<dynamic> instances are not
created unless this is unavoidable?  A similar argument would call for
\code{\CONST <Object>\{\}} below.

[gbracha, 2015/03/26 23:21:22]

We have been doing this in similar situations with method lookup (e.g., const
{}). 

+\item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
+\end{itemize}
+Then the method \code{noSuchMethod()} is looked up in $o$ 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 $o$ 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}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Symbol #noSuchMethod ?

[gbracha, 2015/03/26 23:21:22]

Done everywhere in response to previous comment.

+\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{} \{\}}.

[eernst, 2015/03/26 22:38:50]

Could again be <Object>[$im$] and \CONST <Object>\{\}.

+\end{itemize}
+and the result of this latter invocation is the result of evaluating $i$.
 
+\LMHash{}
+It is a compile-time error if $e$ is a prefix object (\ref{imports}) and $m$ refers to a type or a member of class \cd{Object}.
+
+\commentary{
+This restriction is in line with other limitations on the use of prefixes as objects. The only permitted uses of $p\#m$ are closurizing top level methods and getters imported via the prefix $p$. Top level methods are directly available by their qualified names: $p.m$. However, getters and setters are not, and allowing their closurization is the whole point of the $e\#m$ syntax.
+}
+
+\LMHash{}
+Let $T$ be the static type of $e$. It is a static type warning if $T$ does not have an accessible instance method or getter named $m$ unless either:

[Paul Berry, 2015/03/26 18:55:58]

It seems inconsistent that on line 4102 we allow e#m to refer to a setter named
m (if there is no function or getter named m), but here we don't allow for it.

I think we need to say "It is a static type warning if $T$ does not have an
accessible instance method, getter, or setter named m unless either..."

So that code like the following will be warning-free:

class C {
  void set s(int value) { ... }
}
f(C c) => c#s=;

+\begin{itemize}
+\item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant proxy defined in \cd{dart:core}. Or

[Paul Berry, 2015/03/26 18:55:58]

Nit: when this text appears elsewhere in the spec, "proxy" is notated as
"@proxy".

+\item $T$ is \cd{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static method or getter named $m$.

[Paul Berry, 2015/03/26 18:55:58]

Similarly, "or setter" should be added here.

+\end{itemize}
+
+The static type of $i$ is:
+\begin{itemize}
+\item The static type of function $T.m$, if $T$ has an accessible instance member named $m$.
+\item The static type of function $T.m$, if $T$ is \cd{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static member or constructor named $m$.
+\item The type  \DYNAMIC{} otherwise. 
+\end{itemize}

[Paul Berry, 2015/03/26 18:55:58]

Consider adding some non-normative explanatory text to clarify that in the case
where $T$ has an accessible instance member that is a getter or a setter, the
static type of $i$ is the type of the getter or setter function.

(I missed this subtlety on the first several readings, and assumed that you'd
simply forgotten to cover these cases.)

+
+\subsubsection{Named Constructor Extraction}
+\LMLabel{namedConstructorExtraction}
+
+\LMHash{}
+Evaluation of a property extraction $i$ of the form \NEW{} $T\#m$ or \CONST{} $T\#m$ proceeds as follows:

[Paul Berry, 2015/03/26 18:55:58]

This is inconsistent with line 2352, where the constructs that are added to the
grammar contain '.', e.g. "new T#.m" and "const T#.m".

+
+\LMHash{}
+If $T$ is a malformed type (\ref{staticTypes}), a dynamic error occurs. If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs. If $T$ does not denote a class, a dynamic error occurs. In checked mode, if $T$ or any of its superclasses is malbounded a dynamic error occurs. Otherwise, if the type $T$ does not declare an accessible named constructor $f$ with name $m$, a \cd{NoSuchMethodError} is thrown. Otherwise, $i$ evaluates to the closurization of constructor $f$ of type $T$ (\ref{namedConstructorClosurization}).
+
+\commentary{Note that if $T$ is malformed or malbounded, a static warning occurs, as always.}
+
+\LMHash{}
+The static type of $i$ is the type of the constructor function, if $T$ denotes a class in the surrounding scope with an accessible constructor $f$ named $m$. Otherwise the static type of $i$ is \DYNAMIC{}.

[Paul Berry, 2015/03/26 18:55:58]

"$f$" can be removed, since nothing refers to it.

+
+\subsubsection{Anonymous Constructor Extraction}
+\LMLabel{anonymousConstructorExtraction}
+
+\LMHash{}
+Evaluation of a property extraction $i$ of the form \NEW{} $T\#$ or \CONST{} $T\#$ proceeds as follows:
+
+\LMHash{}
+If $T$ is a malformed type (\ref{staticTypes}), a dynamic error occurs. If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs. If $T$ does not denote a class, a dynamic error occurs. In checked mode, if $T$ or any of its superclasses is malbounded a dynamic error occurs. Otherwise, if the type $T$ does not declare an accessible anonymous constructor, a \cd{NoSuchMethodError} is thrown. Otherwise, $i$ evaluates to the closurization of the anonymous constructor of type $T$ (\ref{anonymousConstructorClosurization}).
+
+\commentary{Again, note that if $T$ is malformed or malbounded, existing rules ensure that a static warning occurs. This also means that $x\#$ where $x$ is not a type will always give a static warning.}

[Paul Berry, 2015/03/26 18:55:58]

I think you mean "This also means that \NEW{} $x\#$ or \CONST{} $x\#$ where $x$
is not a type will always give a static warning."

+
+\LMHash{}
+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:
+
+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 $m$ with respect to superclass $S$ (\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}).  
+ 
+ \LMHash{}
+ Otherwise, 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}).  
+ 
+
+\LMHash{}
+Otherwise,  a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
+\begin{itemize}
+\item  If $m$ is a setter name, \code{im.isSetter} evaluates to \code{\TRUE{}}; otherwise \code{im.isMethod} evaluates to \code{\TRUE{}}

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Same comment as above: Just throw a NoSuchMethodError directly instead of
sending incorrect/broken information to noSuchMethod.

[gbracha, 2015/03/26 23:21:21]

Done.

+\item  \code{im.memberName} evaluates to \code{'m'}.
+\item \code{im.positionalArguments} evaluates to the value of \code{\CONST{} []}.
+\item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.

[eernst, 2015/03/26 22:38:50]

Again we could have <Object>[] and <Object>{}.

+\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 :
+\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{} \{\}}.

[eernst, 2015/03/26 22:38:51]

<Object>{}.

+\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 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{}.
+
+
+
+\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$ $m$ $a;$\} if $f$ is named $m$ and $m$ 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 $m$ has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+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$.
 \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, \ldots, p_k)$;
 \}
 \end{dartCode}
 
-if $m$ has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \end{itemize}
 
-where $u$ is a fresh final variable bound to $o$, except that:
-\begin{enumerate}
-\item  Iff  \code{identical($o_1, o_2$)}  then \cd{$o_1.m$ == $o_2.m$}.
-\item The static type of the property extraction is the static type of function $T.m$, where $T$ is the static type of $e$, if $T.m$ is defined. Otherwise the static type of $e.m$ is \DYNAMIC{}.
-\end{enumerate}
+\LMHash{}
+Except that iff  \code{identical($o_1, o_2$)}  then  \cd{$o_1\#m$ == $o_2\#m$},  \cd{$o_1.m$ == $o_2.m$}, \cd{$o_1\#m$ == $o_2.m$} and  \cd{$o_1.m$ == $o_2\#m$}.
+%\item The static type of the property extraction is the static type of function $T.m$, where $T$ is the static type of $e$, if $T.m$ is defined. Otherwise the static type of $e.m$ is \DYNAMIC{}.

[eernst, 2015/03/26 22:38:51]

Why is this commented out?

+
+\LMHash{}
+The {\em closurization of getter $f$ on object $o$} is defined to be equivalent to \cd{()\{\RETURN{} u.m;\}} if $f$ is named $m$, except that iff  \code{identical($o_1, o_2$)} then  \cd{$o_1\#m$ == $o_2\#m$}.
+
+\LMHash{}
+The {\em closurization of setter $f$ on object $o$} is defined to be equivalent to \cd{(a)\{\RETURN{} u.m = a;\}} if $f$ is named $m=$, except that iff  \code{identical($o_1, o_2$)} then \cd{$o_1\#m=$ == $o_2\#m=$}.
 
 \commentary{
 There is no guarantee that \cd{identical($o_1.m, o_2.m$)}. Dart implementations are not required to canonicalize these or any other closures.
 }
 % local functions that have a closure extracted are always different
 
 \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:
+
+One cannot closurize a constructor, getter or a setter via the dot based syntax. One must use the \# based form. 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.
+}
+
 
 
+\subsubsection{Named Constructor Closurization}
+\LMLabel{namedConstructorClosurization}
 
-\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 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:
-
+The {\em closurization of constructor $f$ of type $T$} 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$.
-%\item $(r_1, \ldots, r_n, rest)\{return$  $o.m(r_1, \ldots, r_n, rest);\}$ if $m$ has required parameters $r_1, \ldots r_n$, and a rest parameter $rest$.
-%\item
 \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)$;
+$(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
+  \RETURN{} \NEW{} $T.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
+\} 
+\end{dartCode}
+
+if $f$ is a named constructor with name $m$ that has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+\item 
+\begin{dartCode}
+$(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
+  \RETURN{} \NEW{} $T.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
 \}
 \end{dartCode}
 
-if $m$ has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is a named constructor with name $m$ that has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+\end{itemize}
+
+\LMHash{}
+Except that iff  \code{identical($T_1, T_2$)}  then  \cd{\NEW{} $T_1\#m$ == \NEW{} $T_2\#m$}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

The identical(T_1, T_2) looks odd when you are comparing types, since they are
not being used as values in the T_1#m / T_2#m syntax. How about: 
  For any type T, new T#m == new T#m (that is, creating a closurization of the
same constructor twice gives functions that are equal to each other).

[gbracha, 2015/03/26 23:21:21]

Then I have to exclude parameterized types somehow. Leaving as is.

+
+\commentary{ 
+The above implies that for non-parameterized types, one can rely on the equality of closures resulting from closurization on the ``same'' type. For parameterized types, one cannot, since there is no requirement to canonicalize them.
+}
+
+\subsubsection{Anonymous Constructor Closurization}
+\LMLabel{anonymousConstructorClosurization}
+
+\LMHash{}
+The {\em closurization of anonymous constructor $f$ of type $T$} is defined to be equivalent to:
+\begin{itemize}
+\item  
+\begin{dartCode}
+$(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
+  \RETURN{} \NEW{} $T(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
+\} 
+\end{dartCode}
+
+if $f$ is an anonymous constructor that has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \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, \ldots, p_k)$;
-\} 
+  \RETURN{} \NEW{} $T(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
+\}
 \end{dartCode}
 
-if $m$ has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is an anonymous constructor that has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \end{itemize}
 
 \LMHash{}
-Except that:
-\begin{enumerate}
-\item  iff  \code{identical($o_1, o_2$)}  then \cd{$o_1.m$ == $o_2.m$}.
+Except that iff  \code{identical($T_1, T_2$)}  then  \cd{\NEW{} $T_1\#$ == \NEW{} $T_2\#$}.
+
+
+\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{} $m$ $a;$\} if $f$ is named $m$ and $m$ 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$.
 \item 
-The static type of the property extraction is the static type of the method $S.m$,  if $S.m$ is defined. Otherwise the static type of $\SUPER{}.m$ is \DYNAMIC{}.
-\end{enumerate}
+\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, \ldots, p_k)$;
+\}
+\end{dartCode}
+
+if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+\end{itemize}
+
+\LMHash{}
+Except that iff two closurizations were created by code declared in the same class with identical bindings of \THIS{} then  \cd{\SUPER$_1\#m$ == \SUPER$_2\#m$},  \cd{\SUPER$_1.m$ == \SUPER$_2.m$}, \cd{\SUPER$_1\#m$ == \SUPER$_2.m$} and  \cd{\SUPER$_1.m$ == \SUPER$_2\#m$}.
+
+
+\LMHash{}
+The {\em closurization of getter $f$  with respect to superclass $S$} is defined to be equivalent to \cd{()\{\RETURN{} \SUPER.m;\}} if $f$ is named $m$, except that iff two closurizations were created by code declared in the same class with identical bindings of \THIS{} then  \cd{\SUPER$_1\#m$ == \SUPER$_2\#m$}.
+
+\LMHash{}
+The {\em closurization of setter $f$  with respect to superclass $S$} is defined to be equivalent to \cd{(a)\{\RETURN{} \SUPER.m = a;\}} if $f$ is named $m=$, except that iff two closurizations were created by code declared in the same class with identical bindings of \THIS{} then \cd{\SUPER$_1\#m=$ == \SUPER$_2\#m=$}.
+
 
 
 \subsection{ Assignment}
 \LMLabel{assignment}
 
 \LMHash{}
 An assignment changes the value associated with a mutable variable or property.
 
 \begin{grammar}
 {\bf assignmentOperator:}`=' ;
@@ skipping 32 matching lines @@
 \LMHash{}
 Otherwise, the assignment is equivalent to the assignment \code{ \THIS{}.$v$ = $e$}. 
 
 \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 (\ref{actualTypeOfADeclaration}) of $v$.
 
 \LMHash{}
 It is a static type warning if the static type of $e$ may not be assigned to the static type of $v$. The static type of the expression $v$ \code{=} $e$ is the static type of $e$.
 
 \LMHash{}
+Evaluation of an assignment $a$ of the form $e_1?.v$ \code{=} $e_2$ is equivalent to the evaluation of the expression $((x) => x == \NULL? \NULL: x.v = e_2)(e_1)$. The static type of $a$ is the static type of $e_2$. 

[eernst, 2015/03/26 22:38:50]

It might be an error-prone choice to let $e_2$ be evaluated _zero_ times when
the value of $e_1$ is null.  Would it make sense to say that, compared to the
corresponding null-agnostic constructs, null-aware constructs do not change the
number of times subexpressions are evaluated, they just prevent lookups on null?

[Lasse Reichstein Nielsen, 2015/03/27 07:14:45]

The ?? operator is definitely short-circuit: (e1 ?? e2) will not evaluate e2 if
e1 evaluates to a non-null value. It's like JavaScript (e1 || e2).
That makes ??= also short-circuit.

For e1?.selector(e2) I would *not* expect e2 to be evaluated if selector isn't
called. The '?' guards the entire expression. So again, I think the guarding
should affect which expressions are evaluated, and I would be surprised if it
didn't.
Example:
  foo?.addFeature(new Feature(id: counter++))
If I'm not adding anything, I don't want to increment my counter.

So, the only one I may have doubts about is  e1.foo ?= e2.
If e1 is null, would I expect it to evaluate e2? I'm split on that.
Since assignment returns the value, you can have cases like:
  x = o?.bar = 42
and in that case you might want x to be 42.
On the other hand, it's inconsistent with the other cases, which counts against
it, and other null-aware expressions also have a value, so is this different
from:
  x = o?.setBar(42)
which sets x to null?

I think I lean slightly towards not evaluating the expression, making o?.bar = e
and o?.setBar(e) work the same way.

[eernst, 2015/03/27 08:44:03]

For (e1 || e2), the rationale for the short-circuit semantics could be "skip the
evaluation of subexpressions whose value cannot affect the value of the
expression as a whole" plus "evaluation proceeds from left to right".  

The same rationale doesn't quite work for (e1 ?? e2), but we could have "e2 is a
backup for e1, to be used only if necessary".  For e1?.selector(e2), we could
have "call off the entire action if e1 'is not present'", again not quite the
same.  Finally, with `v ?= e` we could have "call off the assignment if 'v _is_
already present'".  It seems that there is an interesting wealth of rationales
around.  ;)

One overarching principle that we could apply is: "Avoid the evaluation of
subexpressions as often as possible", in which case `v ?= e` should not evaluate
and return the value of `e` when `v != null`, but it could pass on the value of
`v` to the enclosing expression (just like other assignment expressions).

[Lasse Reichstein Nielsen, 2015/03/27 15:42:09]

We don't actually have "v ?= e", only "o?.p = e" which should call the setter p=
if o is not null (or did you mean "v ??= e"?).

It is true that there can be different perspectives. Mine is mostly as a "null
guard", and everything being guarded should be skipped if the guard is null (or
for '??', if it is not null). It's a shorthand for something with "x == null ?
... : ...".

The ?? operator exists in C# (and in Groovy as he Elvis operator), and it is
short-circuit there. It should be short-circuit in Dart too.

It seems that Groovy's safe navigation operator does evaluate arguments before
not calling a function, so that's a different behavior. C# is getting safe
navigation operators (?.foo, ?.coo(), ?[..]), but I can't find their spec. From
the examples I've seen I'd expect the ?.foo(args) to not evaluate args. I'll see
if I can find an implementation.

Groovy a.?x=print(42) also prints 42 if a is null.
At least they are consistent (but the language doesn't seem to have a
specification that actually specifies anything).

[eernst, 2015/04/07 10:44:49]

Sorry, I meant "v ??= e".

I think the most intuitive semantics (having had this in the back of my mind
today ;) is based on an "ok, then drop it" rationale: As soon as a null is
encountered, no more actions take place.

Assigning something to a variable _unless_ it is _non-null_ is an anomaly here. 
You might expect that only non-null values could be assigned to a formerly null
valued variable, but you can't undo the side-effects (e.g., print(42)) when you
discover that the returned value is null. So that operation probably doesn't
have a rationale.  ;-)

+
+\LMHash{}
 Evaluation of an assignment of the form $e_1.v$ \code{=} $e_2$ proceeds as follows:
 
 \LMHash{}
 The expression $e_1$ is evaluated to an object $o_1$. Then, the expression $e_2$  is evaluated to an object $o_2$. Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $o_1$ with respect to the current library.  If $o_1$ is an instance of \code{Type} but $e_1$ is not a constant type literal, then if $v=$ is a setter that forwards (\ref{functionDeclarations}) to a static setter, setter lookup fails. Otherwise, the body  of $v=$ is executed with its formal parameter bound to $o_2$ and \THIS{} bound to $o_1$. 
 
 \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 \code{'v='}.
@@ skipping 39 matching lines @@
 
 \LMHash{}
 It is a compile-time error to invoke any of the setters of class \cd{Object} on a prefix object (\ref{imports}) or on a constant type literal that is  immediately followed by the token `.'.
 
 
 
 \subsubsection{Compound Assignment}
 \LMLabel{compoundAssignment}
 
 \LMHash{}
-A compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{=} v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equivalent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. A compound assignment of the form  $e_1[e_2]$ $op\code{=} e_3$ is equivalent to 
+Evaluation of a compound assignment of the form $v$ $\code{??=} e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL?  v=e : x)(v)$ where $x$ is a variable that is not used in $e$. Evaluation of a compound assignment of the form $C.v$ $\code{??=} e$, where $C$ is a type literal, is equivalent to the evaluation of the expression  $((x) => x == \NULL?  C.v=e: x)(C.v)$ where $x$ is a variable that is not used in $e$. Evaluation of a compound assignment of the form $e_1.v$  $\code{??=} e_2$ is equivalent to the evaluation of the expression  $((x) =>((y) => y == \NULL?  x.v = e_2: y)(x.v))(e_1)$ where $x$ and $y$ are distinct variables that are not used in $e_2$. Evaluation of a compound assignment of the form  $e_1[e_2]$  $\code{??=} e_3$ is equivalent to the evaluation of the expression  

[Paul Berry, 2015/03/26 15:07:21]

Nit: the pdf output of this paragraph contains some confusing spaces.  For
example, "$v$ $\code{??=} e$" comes out looking like "v ?? =e" when the
intention is probably "v ??= e".  Similarly, "$((x) => x == \NULL?  v=e :
x)(v)$" comes out looking like "((x) => x == null?v = e : x)(v)", whereas when
coding one almost always puts spaces around the '?' operator.

[eernst, 2015/03/26 22:38:50]

If null-awareness should not change the number of times subexpressions are
evaluated then $e$ should be evaluated also if v == null.  A general pattern for
this could be to pass all subexpressions to the function expression rather than
just some of them.  Alternatively, the principle could be that as few as
possible of the given subexpressions should be evaluated for all null-aware
constructs, in which case nothing should be changed above.

[eernst, 2015/03/26 22:38:50]

Typo?: $((x) ..)(..)$ vs. \code{((x) $=>$ ..)(..)}.

[gbracha, 2015/03/26 23:21:22]

Yes, I am aware of that. I made some changes, but I still don't like how it
comes out. But I can fix typography later.  Today I should focus on semantics.

+$((a, i) => ((x) => x == \NULL?  a[i] = e_3: x)(a[i]))(e_1, e_2)$ where $x$, $a$ and $i$ are distinct variables that are not used in $e_3$. Evaluation of a compound assignment of the form $e_1?.v$  $\code{??=} e_2$ is equivalent to the evaluation of the expression \code{((x) $=>$ x == \NULL? \NULL: $x.v ??=  e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. 

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Need to address super.x ??= y too?

[eernst, 2015/03/26 22:38:50]

How about \code{$e_1$ == null}?

[gbracha, 2015/03/26 23:21:21]

Hmm. Actually, I think we don't really cover super.v = e or super[i] = e. 

[gbracha, 2015/03/26 23:21:22]

Done. 

[gbracha, 2015/03/26 23:21:22]

How about it :-) ? Sorry not clear what you mean. 

[eernst, 2015/03/27 08:44:03]

Actually, thinking about it, no special checking is needed in order to act
differently when \code{$e_1$ == \NULL}.  The anomaly is that we don't have

  e_1?[e_2] === ((a, i) => a == \NULL? \NULL : a[i])(e_1, e_2)

plus something similar to

  e_1?[e_2] = e_3 === ((a, i) => a == \NULL || i == \NULL? 
      \NULL : a[i] = e_3)(e_1, e_2)

And of course `e_1 ?@ e_2` for @ \in {+,-,*,/,...}.  ;)

+
+
+\LMHash{}
+The static type of a compound assignment of the form $v$ $\code{??=} e$ or the form $C.v$ $\code{??=} e$ is the static type of $e$. The static type of a compound assignment of the form $e_1.v$  $\code{??=} e_2$ is the static type of $e_2$. The static type of a compound assignment of the form $e_1[e_2]$  $\code{??=} e_3$ is the static type of $e_3$.

[Paul Berry, 2015/03/26 15:07:21]

I don't think this is what we want.  Consider the code:

f(num x) {
  (x ??= 1).modPow(2, 1000);
}

(Note that "modPow" is defined on the class "int" but not the class "num".)

As currently defined, this would produce no warnings, since the static type of
"x ??= 1" is the static type of "1", which is "int".  However, at runtime, if a
non-null value is passed to f(), then "x ??= 1" will evaluate to x, which is not
guaranteed to be an int.

I think we want to define the static type of "v ??= e" to be the least upper
bound of the static types of "v" and "e", similar to what we do for "v ?? e".

[gbracha, 2015/03/26 23:21:22]

Right. Likewise for all variants (v , C.v, e1.v, e1[e2]).

+
+\LMHash{}
+For any other valid operator $op$, a compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{=} v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equivalent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. A compound assignment of the form  $e_1[e_2]$ $op\code{=} e_3$ is equivalent to 
 \code{((a, i) $=>$ a[i] = a[i] $op$ $e_3$)($e_1, e_2$)} where $a$ and $i$ are a variables that are not used in $e_3$. 
-
+A compound assignment of the form $e_1?.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x?.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. 

[Paul Berry, 2015/03/26 15:07:21]

Nit: there are some spacing errors in this paragraph too.

 
 \begin{grammar}
 {\bf compoundAssignmentOperator:}`*=';
       `/=';
       `\~{}/=';
       `\%=';
       `+=';
       `-=';
       `{\escapegrammar \lt \lt}=';
        `{\escapegrammar \gt \gt}=';
       `\&=';
       `\^{}=';
-      `$|$='
+      `$|$=';
+      `??=';
     .
 \end{grammar}
 
     
 \subsection{ Conditional}
 \LMLabel{conditional}
 
 \LMHash{}
 A {\em conditional expression} evaluates one of two expressions based on a boolean condition.
 
 \begin{grammar}
   {\bf conditionalExpression:}
-     logicalOrExpression (`?' expressionWithoutCascade `{\escapegrammar :}' expressionWithoutCascade)?
+     ifNullExpression (`?' expressionWithoutCascade `{\escapegrammar :}' expressionWithoutCascade)?
     . % the first  branches could  top level expressions, it seems, but certainly NOT the second
 \end{grammar}
 
 \LMHash{}
 Evaluation of a conditional expression $c$ of the form $e_1 ? e_2 : e_3$ proceeds as follows:
 
 \LMHash{}
 First, $e_1$ is evaluated to an object $o_1$.  Then, $o_1$ is  subjected to boolean conversion (\ref{booleanConversion}) producing an object $r$.  If $r$ is \TRUE, then the value of $c$ is the result of evaluating the expression $e_2$. Otherwise the value of $c$ is the result of evaluating the expression $e_3$. 
 
 \LMHash{}
 If all of the following hold:
 \begin{itemize}
 \item $e_1$ shows that a variable $v$ has type $T$.
 \item $v$ is not potentially mutated in $e_2$ or within a closure.
 \item If the variable $v$ is accessed by a closure in $e_2$ then the variable $v$ is not potentially mutated anywhere in the scope of $v$.
 \end{itemize}
 
 then the type of $v$ is known to be $T$ in $e_2$.
 
 
 \LMHash{}
  It is a static type warning if the static type of $e_1$ may not be assigned to \code{bool}.  The static type of $c$ is the least upper bound (\ref{leastUpperBounds}) of the static type of $e_2$ and the static type of $e_3$.
+ 
+   
+ \subsection{If-null Expressions}
+ \label{ifNull}
+ 
+ \LMHash{}
+ An {\em if-null expression}evaluates an expression and if the result is \NULL, evaluates another.
+
+\begin{grammar}
+{\bf ifNullExpression:}
+  logicalOrExpression (`??' logicalOrExpression)*
+\end{grammar}
+  
+\LMHash{}
+Evaluation of an if-null expression $e$ of the form $e_1??e_2 $ is equivalent to the evaluation of the expression $((x) => x == \NULL? e_2: x)(e_1)$. The static type of $e$ is least upper bound (\ref{leastUpperBounds}) of the static type of $e_1$ and the static type of $e_2$.
   
 
 \subsection{ Logical Boolean Expressions}
 \LMLabel{logicalBooleanExpressions}
 
 \LMHash{}
 The logical boolean expressions combine boolean objects using the boolean conjunction and disjunction operators.
 
 \begin{grammar}
 {\bf logicalOrExpression:}
@@ skipping 329 matching lines @@
 
      
 \subsection{ Postfix Expressions}
 \LMLabel{postfixExpressions}
 
 \LMHash{}
 Postfix expressions invoke the postfix operators on objects.
 
  \begin{grammar}
 {\bf postfixExpression:}assignableExpression postfixOperator;
-      primary selector*
+      primary (selector* $|$ ( `\#' ( (identifier `='?) $|$ operator)))

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Could the #-syntax be part of selector instead?

It's probably ok, and it does prevent the (arguably abusive) use:
  o#b()
Just want to be sure we are sure you never want to immediately do something to
an extracted function (like calling it or accessing a member of it).

[gbracha, 2015/03/26 23:21:21]

I'm not inclined to outlaw the abuse.

     .
 
 {\bf postfixOperator:}
       incrementOperator
     .
 
 {\bf selector:}assignableSelector;
       arguments
     .
 
@@ skipping 62 matching lines @@
 
 
 \begin{grammar}
 
 {\bf assignableExpression:}primary (arguments* assignableSelector)+;
       \SUPER{} assignableSelector;
       identifier
     .
     
 {\bf assignableSelector:}`[' expression `]'; % again, could be top level
-      `{\escapegrammar .}' identifier
+      `{\escapegrammar .}' identifier;
+       `{\escapegrammar ?.}' identifier

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Different indentation?

[gbracha, 2015/03/26 23:21:22]

Acknowledged.

     .
 
 \end{grammar}
 
 \LMHash{}
-An {\em assignable expression} is either:
+An assignable expression can be {\em conditional} or {\em unconditional}.
+
+Evaluation of a {\em conditional assignable expression} $e$ of the form $e_1?.id$  is equivalent to the evaluation of the expression  $((x) => x == \NULL ? \NULL : x.id)(e_1)$. The static type of $e$ is the same as the static type of $e_1.id$.
+
+\commentary{
+One might be tempted to conclude that for $e \ne \NULL{}$, $e?.v$ is always equivalent to $e.v$. However this is not the case. If $e$ is a type literal representing a type with static member $v$, the $e.v$ refers to that member, but $e?.v$ does not.
+}
+
+\rationale{
+One could try and address this with special case rules, but this is simply a matter of digging oneself deeper into a hole. Removing the restrictions on the use of types as objects is the proper way to resolve this issue.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Objection, editorializing!

[gbracha, 2015/03/26 23:21:22]

I am the editor, after all. I wondered if anyone would notice. 

+}
+
+
+\LMHash{}
+An {\em unconditional assignable expression} is either:
 \begin{itemize}
  \item An identifier. 
 \item An invocation of a getter (\ref{getters}) or list access operator on an expression $e$.
 \item An invocation of a getter or list access operator on  \SUPER{}.
 \end{itemize}
 
 
 \LMHash{}
 An assignable expression of the form $id$ is evaluated as an identifier expression (\ref{identifierReference}).
 
@@ skipping 924 matching lines @@
 A try statement \TRY{} $s_1$ $on-catch_1 \ldots  on-catch_n$ \FINALLY{} $s_f$  defines an exception handler $h$ that executes as follows:
 
 \LMHash{}
 The \ON{}-\CATCH{} clauses are examined in order, starting with $catch_1$, until either an \ON{}-\CATCH{} clause that matches the current exception (\ref{throw}) is found, or the list of \ON{}-\CATCH{} clauses has been exhausted. If an \ON{}-\CATCH{} clause $on-catch_k$ is found, then $p_{k1}$ is bound to the current exception,  $p_{k2}$, if declared,  is bound to the active stack trace, and then $catch_k$ is executed. If no \ON{}-\CATCH{} clause is found, the \FINALLY{} clause is executed. Then, execution resumes at the end of the try statement.
 
 
 \LMHash{}
 A finally clause \FINALLY{} $s$ defines an exception handler $h$ that executes as follows:
 
 \LMHash{}
-Let $r$ be the current return value (\ref{return}). Then the current return value becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executing within the dynamic scope of $h$ are canceled. 
+Let $r$ be the current return value (\ref{return}). Then the current return value becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executing within the dynamic scope of $h$ are canceled, in the order of their nesting, innermost first. 
 
 \rationale{
 Streams left open by for loops that were escaped for whatever reason would be canceled at function termination, but it is best to cancel them as soon as possible.
 }
 
 \LMHash{}
 Then the \FINALLY{} clause is executed. Let $m$ be the immediately enclosing function. If $r$ is defined then the current return value is set to $r$ and then:
 \begin{itemize}
 \item
  if there is a dynamically enclosing error handler $g$ defined by a \FINALLY{} clause in $m$, control is transferred to $g$.
@@ skipping 185 matching lines @@
 \begin{grammar}
 {\bf breakStatement:}
      \BREAK{} identifier? `{\escapegrammar ;}'
     .
  \end{grammar}
  
 \LMHash{}
 Let $s_b$ be a \BREAK{} statement. If $s_b$ is of the form  \code{\BREAK{} $L$;}, then let $s_E$ be the the innermost labeled statement with label $L$ enclosing $s_b$. If $s_b$ is of the form \code{\BREAK{};},  then let $s_E$ be the the innermost  \DO{} (\ref{do}), \FOR{} (\ref{for}), \SWITCH{} (\ref{switch}) or \WHILE{} (\ref{while}) statement enclosing  $s_b$. It is a compile-time error if no such statement $s_E$ exists within the innermost function in which  $s_b$ occurs.  Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclosed in $s_E$ and that enclose  $s_b$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$.   Executing  $s_b$ first executes $f_1, \ldots,  f_n$ in innermost-clause-first  order and then terminates $s_E$. 
 
 \LMHash{}
-If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchronous for loops  and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that are enclosed in $s_E , 1 \le k \le m$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$. 
+If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchronous for loops  and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$. 
 
 
 
 \subsection{ Continue}
 \LMLabel{continue}
 
 \LMHash{}
 The {\em continue statement} consists of the reserved word \CONTINUE{} and an optional label (\ref{labels}). 
 
 \begin{grammar}
 {\bf continueStatement:}
     \CONTINUE{} identifier? `{\escapegrammar ;}'
         .
  \end{grammar}      
  
 \LMHash{}
  Let $s_c$ be a \CONTINUE{} statement. If $s_c$ is of the form  \code{\CONTINUE{} $L$;}, then let $s_E$ be the the innermost labeled \DO{} (\ref{do}), \FOR{} (\ref{for}) or \WHILE{} (\ref{while}) statement or case clause with label $L$ enclosing $s_c$. If $s_c$ is of the form \code{\CONTINUE{};}  then let $s_E$ be the the innermost  \DO{} (\ref{do}), \FOR{} (\ref{for}) or \WHILE{} (\ref{while}) statement enclosing  $s_c$. It is a compile-time error if no such statement or case clause $s_E$ exists within the innermost function in which  $s_c$ occurs.  Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclosed in $s_E$ and that enclose  $s_c$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$.   Executing  $s_c$ first executes $f_1, \ldots,  f_n$ in innermost-clause-first  order. Then, if $s_E$ is a case clause, control is transferred to the case clause. Otherwise, $s_E$ is necessarily a loop and execution resumes after the last statement in the loop body.
  
  \commentary{
  In a while loop, that would be the boolean expression before the body. In a do loop, it would be the boolean expression after the body. In a for loop, it would be the increment clause.  In other words, execution continues to the next iteration of the loop.
  }
  
 \LMHash{}
- If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be the set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enclosing $s_c$ that are enclosed in $s_E , 1 \le k \le m$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$. 
+ If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be the set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enclosing $s_c$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$. 
  
  \subsection{ Yield and Yield-Each}
  \LMLabel{yieldAndYieldEach}
  
  \subsubsection{ Yield}
  \LMLabel{yield}
  
 \LMHash{}
  The {\em yield statement} adds an element to the result of a generator function (\ref{functions}).
 
@@ skipping 1304 matching lines @@
 \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 |}
 \hline
 Description &  Operator & Associativity & Precedence \\ 
 \hline
 Unary postfix &  ., e++, e--, e1[e2], e1() , () & None & 15 \\

[Paul Berry, 2015/03/26 15:07:21]

Add "?." to the table.

[gbracha, 2015/03/26 23:21:22]

Done.

 \hline
 Unary prefix & -e, !e, \~{}e, ++e, --e & None & 14\\
 \hline
 Multiplicative & *, /, \~/,  \%  & Left & 13\\
 \hline
 Additive & +, - & Left & 12\\
 \hline 
 Shift &  $<<$, $>>$&  Left & 11\\
 \hline
 Bitwise AND & \& & Left & 10\\
 \hline
 Bitwise XOR & \^{} & Left & 9\\
 \hline
 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

[Paul Berry, 2015/03/26 15:07:21]

Add "??" to the table (left-associative).

[gbracha, 2015/03/26 23:21:21]

Done.

 Conditional &  e1? e2: e3 & Right & 3\\
 \hline
 Cascade & ..  & Left & 2\\
 \hline
 Assignment &  =, *=, /=, +=, -= ,\&=, \^{}= etc.  &  Right &  1\\
 \hline
 \end{tabular}
 }
 %\subsection{Glossary}
 %\LMLabel{glossary}
@@ skipping 162 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.
 
 ----------------------------------------------------------------------