Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2433943002:
Spec: Rewrite lambdas to simpler semantics instead. (Closed)
|
Created:
4 years, 2 months ago by Lasse Reichstein Nielsen Modified:
4 years, 1 month ago Reviewers:
eernst CC:
reviews_dartlang.org Target Ref:
refs/heads/master Visibility:
Public. |
DescriptionSpec: Rewrite lambdas to simpler semantics instead.
This is instead of introducing a let-construct.
R=eernst@google.com
Committed: https://github.com/dart-lang/sdk/commit/f3288982debc171ce144579b216c4a95010974b7
Patch Set 1 #Patch Set 2 : Remove \LET #
Total comments: 139
Patch Set 3 : Address comments. #
Total comments: 71
Patch Set 4 : More LMHash. #
Total comments: 1
Messages
Total messages: 10 (2 generated)
lrn@google.com changed reviewers: + eernst@google.com
Alternative version, without the let, just rewriting the lambdas into prose. I think I prefer this one.
https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... File docs/language/dartLangSpec.tex (right): https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3836: Otherwise let \code{v} be a fresh variable bound to $x$ and evaluate As discussed offline, the \code{v} should be $v$ - it's a metasyntactic variable, not a syntactic variable. Similarly for all the other cases.
LGTM, with lots of little things that we might as well make consistent now that we're touching it. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dart.sty File docs/language/dart.sty (right): https://codereview.chromium.org/2433943002/diff/20001/docs/language/dart.sty#... docs/language/dart.sty:94: As far as I can see this file has white space fixes only. I suggest we take a round of formatting fixes separately. Alternatively, we should do a bit more about it now: Remove the white space before each \def, remove all empty lines except for a single one at each "new stuff starts here" location, and remove some comments containing material that we consider obsolete, e.g., \PUBLIC. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... File docs/language/dartLangSpec.tex (right): https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:931: f(x) $=>$ 3; The `dartCode` environment shows source code in a sans serif font (using \sffamily), and it does a few other things to preserve white space. So the `=` used to be in sans serif font and the `>` was in math mode (which use different fonts, and a plethora of complex spacing rules). I would actually expect the change from `=$>$` to `$=>$` to introduce "operator" spacing between the two operators --- but apparently we don't get the extra space, probably because it's classified as two operators rather than an operator and an operand. In any case, I can't see any difference between the sans serif `=` and the math mode `=`, and I can't see any significant difference in the spacing either. So I'd suggest that we avoid making changes like this because it doesn't improve anything. I can see that there are other occurrences of `$=>$`, but the approach where the single char `>` is in math mode seems to be the most common (a quick estimate says 7-10 times more frequent), so this change would make things less consistent, not more. For a longer term solution, we are forced to put `>` in a math context in order to get the "right angle" glyph rather than the "upside-down question mark" glyph, but we have a lot of messy spacing due to misplaced math environments. For example, `<` and `>` in generic class instantiations get far too much space (e.g., `$S<U_1, \ldots, U_m>$` in `\subsubsection{New}`). So we would need to (1) create `\newcommand`s for each construct including all the incantations needed in order to get the formatting right, and (2) use them consistently. This would make it possible to fiddle with the spacing and fonts in the definition, and consistently get the good quality formatting at each "call site". https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:940: \STATIC{} f(x) $=>$ 3; Just keep the old version. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3835: If $x$ is the null value, $e$ evaluates to the null value. This is confusing because the scope of the first `If` is unclear: you have to read all the way down to `If $o$ is a type literal` to see that there is no missing case, otherwise the obvious protest here would be "but $x$ is undefined if $o$ is a type literal, so how is that handled?". We could make the separation smaller (and the whole thing perhaps more smooth) by reordering: ``` \LMHash{} If $o$ is a type literal, $e$ is equivalent to $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. \LMHash{} Otherwise $o$ is not a type literal. Evaluate $o$ to an object $x$. ... ``` I'm not so happy about using `$o$` for syntax and `$x$` for semantic entity (object); in many locations `$o$` is an object and there may not be a syntactic expression which is guaranteed to evaluate to that object (or we'd need to invent a fresh variable, as is done in some cases, such that no side-effects can destroy it). Maybe we could use `$e^\prime$` for the expression that evaluates to the receiver (rather than `$o$`), and `$o$` for the resulting object (rather than `$x$`). https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3836: Otherwise let \code{v} be a fresh variable bound to $x$ and evaluate On 2016/10/31 07:39:25, Lasse Reichstein Nielsen wrote: > As discussed offline, the \code{v} should be $v$ - it's a metasyntactic > variable, not a syntactic variable. Similarly for all the other cases. Acknowledged. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3946: Evaluation of a cascaded method invocation expression $e$ of the form \code{e..suffix} proceeds as follows: We ought to use meta-variables here: `\code{$e$..\mbox{\em suffix}}`. The use of `\mbox{\em suffix}` rather than a plain `suffix` in math mode is motivated by the need to have something that is similar to math mode, but avoiding the completely non-natural-language-ish formatting of `ff` in math mode. So we need an unusual trick because it's unusual to have these long meta-variable names. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3948: Evaluate \code{e} to an object $o$. `\code{e}` --> `$e$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3950: Evaluate $t.suffix$ to an object. `$t.suffix$` --> `\code{$t$.\mbox{\em suffix}}` just to be consistent (I doubt it looks very different ;-) https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3954: 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 == \NULL{} ? \NULL{} : t.{\em suffix}} where \code{t} is bound to the value of $e$. might as well say `$t$ is a fresh variable bound to..` as usual. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4045: If $e_1$ is not a type literal, evaluation of a {\em conditional property extraction expression} $e$ of the form $e_1?.id$ proceeds as follows: I think it would be useful to reorganize this a bit: `Evaluation of .. proceeds as follows: If $e_1$ is a type literal, $e$ is equivalent to $e_1.id$. Otherwise, evaluate $e_1$ to an object $o$. ..`. The point is again that the short alternative is first, such that the list structure is more obvious, which means that it is OK that the last alternative is contains several sentences. Also, I suspect that math mode '?' might be different from \sffamily '?', in which case we should probably use `$e_1$?.$id$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4049: Otherwise let $x$ be a fresh variable bound to $o$ and evaluate \code{$x$.id} to a value $r$. `$x$.$id$`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4052: If $e_1$ is a type literal, $e$ is equivalent to $e_1.m$. (If the reorg above is performed, this line is moved up). https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4496: Evaluation of an assignment $a$ of the form \code{$e_1$?.v = $e_2$} If we keep metavariables in math mode, it should be `\code{$e_1$.$v$ = $e_2$}`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4501: Otherwise let $x$ be a fresh variable bound to $o$ and evaluate \code{$o$.v = $e_2$} to an object $r$. `\code{$o$.$v$ = $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4504: If $e_1$ is a type literal, $a$ is equivalent to $e_1.v$ \code{=} $e_2$. We could reorganize this as well, both for consistency with the previous text and for the reasons mentioned earlier: `If $e_1$ is a type literal, $a$ is equivalent to \code{$e_1$.$v$ = $e_2$}. Otherwise, $e_2$ is not a type literal. Evaluate $e_1$ to ..` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4507: It's probably difficult to tell, but `\code{$y$.$v$ = $e_2$}` would be more consistent, and `\code{$e_1$?.$v$ = $e_2$}`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4599: Call the method $[]=$ on $a$ with $i$ as first argument and $v$ as second argument. The method name is actually concrete syntax, so that would be `\code{[]=}`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4602: The static type of the expression $e_1[e_2]$ \code{=} $e_3$ is the static type of $e_3$. `\code{$e_1$[$e_2$] = $e_3$}` would be the consistent choice. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4622: Evaluation of a compound assignment $a$ of the form $v$ {\em ??=} $e$ I'd say `of the form \code{$v$ ??= $e$}`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4631: Evaluation of a compound assignment, $a$ of the form $C.v$ {\em ??=} $e$, where $C$ is a type literal, proceeds as follow: `of the form \code{$C$.$v$ ??= $e$}, ..` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4643: Evaluation of a compound assignment $a$ of the form $e_1.v$ {\em ??=} $e_2$ `of the form \code{$e_1$.$v$ ??= $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4647: Let \code{x} be a fresh variable not occuring in $e_2$ and bound to $u$. `$x$`, `occuring` --> `occurring`, but it's not fresh if it occurs anywhere, so let's just say `a fresh variable bound to $u$`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4648: Evalute \code{x.$v$} to an object $o$. `\code{$x$.$v$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4650: Otherwise evaluate \code{x.$v$ = $e_2$} to an object $r$, `\code{$x$.$v$ = $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4654: Evaluation of a compound assignment $a$ of the form $e_1[e_2]$ {\em ??=} $e_3$ `\code{$e_1$[$e_2$] ??= $e_3$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4658: Call the $[]$ method on $u$ with argument $i$ and let $o$ be the returned value. `\code{[]}`, add comma: `argument $i$, and let` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4661: and then call the $[]=$ method on $u$ with $i$ as first argument and $v$ as second argument. `\code{[]=}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4665: Evaluation of a compound assignment $a$ of the form $\SUPER.v$ {\em ??=} $e$ `\code{\SUPER.$v$ ??= $e$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4668: Evaluate $\SUPER.v$ to an object $o$. `\code{\SUPER.$v$}` Ok, ok, this only changes the font of the period, but it still feels good to follow a consistent approach. ;-) For instance, if we wish to make concrete syntax blue then we would get it right just by adapting the definition of \code{}, if we have been consistent. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4674: Evaluation of a compound assignment $a$ of the form $e_1?.v$ {\em ??=} $e_2$ `\code{$e_1$?.$v$ ??= $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4677: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4678: Evaluate \code{x.$v$} to an object $o$. `\code{$x$.$v$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4680: Otherwise evaluate \code{x.$v$ = $e_2$} to an object $r$, `\code{$x$.$v$ = $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4705: 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$. `\code{$v$ $op$= $e$}`, `\code{$v$ = $v$ $op$ $e$}`, `\code{$C$.$v$ $op$= $e$}`, `\code{$C$.$v$ = $C$.$v$ $op$ $e$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4707: Evaluation of a compound assignment $a$ of the form $e_1.v$ $op = e_2$ proceeds as follows: `\code{$e_1$.$v$ $op$= $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4708: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4709: Evaluate \code{x.$v$ = x.$v$ $op$ $e_2$} to an object $r$ `\code{$x$.$v$ = $x$.$v$ $op$ $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4714: Let \code{a} and \code{i} be fresh variables bound to $u$ and $v$ respectively. `$a$`, `$i$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4715: Evaluate \code{a[i] = a[i] $op$ $e_3$} to an object $r$, `\code{$a$[$i$] = $a$[$i$] $op$ $e_3$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4719: Evaluation of a compound assignment $a$ of the form \code{$e_1$?.$v$ $op$ = $e_2$} proceeds as follows: Drop the space before `=`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4721: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4722: Evaluate \code{x.$v$} to an object $o$. `\code{$x$.$v$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4723: If $o$ is the null value, then $a$ evaluates to the null value. Isn't the question whether $x$ (or $u$) is the null value, not $o$? In that case the test should go before evaluating \code{$x$.$v$}. $o$ is just the "before" value that we are going to use on the right hand side of `=` to compute an "after" value which is than assigned to $x$.$v$. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4724: Otherwise let \code{y} be a fresh variable bound to $o$ `$y$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4725: and evaluate \code{x.$v$ = t $op$ $e_2$} to an object $r$. `\code{$x$.$v$ = $y$ $op$ $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4728: The static type of $e_1?.v$ $op = e_2$ is the static type of $e_1.v$ $op$ $e_2$. Exactly the same static warnings that would be caused by $e_1.v$ $op = e_2$ are also generated in the case of $e_1?.v$ $op = e_2$. `\code{$e_1$?.$v$ $op$= $e_2$}`, `\code{$e_1$.$v$ $op$ $e_2$}`, `\code{e_1$.$v$ $op$= $e_2$}`, `\code{$e_1$?.$v$ $op$= $e_2$}`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4796: Evaluation of an if-null expression $e$ of the form $e_1??e_2 $ `\code{$e_1$ ?? $e_2$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5177: Evaluate $v$ to an object $r$ and let \code{t} be a fresh variable bound to $r$. $t$ https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5178: Evaluate \code{$v$ = y + 1}. `\code{$v$ = $y$ + 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5189: Evaluation of a postfix expression $e$ of the form \code{$C.v$ ++} Drop the space before `++`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5192: Evaluate $C.v$ to a value $r$ and let \code{y} be a fresh variable bound to $r$. `$y$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5193: Evaluate \code{$C.v$ = y + 1}. `\code{$C$.$v$ = $y$ + 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5204: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5205: Evaluate \code{x.$v$} to a value $r$ and let \code{y} be a fresh variable bound to $r$. `\code{$x$.$v$}`, `$y$`. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5206: Evaluate \code{x.$v$ = y + 1}. `\code{$x$.$v$ = $y$ + 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5214: Evaluation of a postfix expression $e$ of the form \code{$e_1[e_2]$++} `\code{$e_1$[$e_2$]++}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5218: Let \code{a} and \code{i} be fresh variables bound to $u$ and $v$ respectively. `$a$`, `$i$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5219: Evaluate \code{a[i]} to an object $r$ and let $y$ be a fresh variable bound to $r$. `\code{$a$[$i]}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5220: Evaluate \code{a[i] = y + 1}. `\code{$a$[$i$] = $y$ + 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5230: Evaluate the expression $v$ to an object $r$ and let \code{y} be a fresh variable bound to $r$. `$y$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5231: Evaluate \code{$v$ = y - 1}. `\code{$v$ = $y$ - 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5242: Evaluate $C.v$ to a value $r$ and let \code{y} be a fresh variable bound to $r$. `$y$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5243: Evaluate \code{$C.v$ = y - 1}. `\code{$C$.$v$ = $y$ - 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5251: Evaluation of a postfix expression of the form \code{$e_1.v$-{}-} `\code{$e_1$.$v$-{}-}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5254: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5255: Evaluate \code{x.$v$} to a value $r$ and let \code{y} be a fresh variable bound to $r$. `\code{$x$.$v$}`, `$y$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5256: Evaluate \code{x.$v$ = y - 1}. `\code{$x$.$v$ = $y$ -1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5265: Evaluation of a postfix expression $e$ of the form \code{$e_1[e_2]$-{}-} `\code{$e_1$[$e_2$]-{}-}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5269: Let \code{a} and \code{i} be fresh variables bound to $u$ and $v$ respectively. `$a$`, `$i$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5270: Evaluate \code{a[i]} to an object $r$ and let $y$ be a fresh variable bound to $r$. `\code{$a$[$i$]}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5271: Evaluate \code{a[i] = y - 1}. `\code{$a$[$i$] = $y$ - 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5278: Evaluation of a postfix expression $e$ of the form \code{$e_1?.v$++} `\code{$e_1$?.$v$++}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5281: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5282: Evaluate \code{u.$v$} to an object $o$. `\code{$x$.$v$}` (if we can evaluate $u$.$v$ then there is no reason to introduce $x$) But I'd expect a check on $u$, and a bail out if it's null. Checking on $o$ instead could also be useful in some cases, but in that case it would be inconsistent to have the `?` right after `e_1`, where it usually means "is this receiver null?". For a check on the member $v$ we could introduce support for having the `?` elsewhere, maybe `e_1.v?++`, but I'd assume that this wouldn't be worthwhile. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5283: If $o$ is the null value, then $e$ evaluates to the null value. This test may then be moved up before computing $x$.$v$, and checking on $u$ rather than $o$. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5285: and evaluate \code{u.$v$ = y + 1}. `\code{$x$.$v$ = $y$ + 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5288: If $e_1$ is a type literal, $e$ is equivalent to \code{$e_1$.$v$++}. This also motivates a test on $u$ rather than $o$: It's the type literal that can't be null, not the static field $v$. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5294: Evaluation of a postfix expression $e$ of the form \code{$e_1?.v$-{}-} `\code{$e_1$?.$v$-{}-}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5297: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. `$x$` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5298: Evaluate \code{u.$v$} to an object $o$. `\code{$x$.$v$}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5301: and evaluate \code{u.$v$ = y - 1}. `\code{$x$.$v$ = $y$ - 1}` https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5614: } Wouldn't this whole section be unused at this point? https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5751: f(x) $=>$ x++; // a top level function Just keep `=$>$`
PTAL https://codereview.chromium.org/2433943002/diff/20001/docs/language/dart.sty File docs/language/dart.sty (right): https://codereview.chromium.org/2433943002/diff/20001/docs/language/dart.sty#... docs/language/dart.sty:94: On 2016/11/03 18:07:02, eernst wrote: > As far as I can see this file has white space fixes only. I suggest we take a > round of formatting fixes separately. > > Alternatively, we should do a bit more about it now: Remove the white space > before each \def, remove all empty lines except for a single one at each "new > stuff starts here" location, and remove some comments containing material that > we consider obsolete, e.g., \PUBLIC. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... File docs/language/dartLangSpec.tex (right): https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:931: f(x) $=>$ 3; Ack. I don't like physical formatting. I'd prefer to just write \code{literal Dart code with $variable$}. Is there any way we can fix \code{...} and \begin{dartCode} so we can write => verbatim? Reverted for now. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:940: \STATIC{} f(x) $=>$ 3; On 2016/11/03 18:07:06, eernst wrote: > Just keep the old version. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3835: If $x$ is the null value, $e$ evaluates to the null value. changed to expression $i$ on the form $e.m(...)$ and $e$ evaluates to $o$ (also changed the following section similarly). https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3946: Evaluation of a cascaded method invocation expression $e$ of the form \code{e..suffix} proceeds as follows: Physical formatting :( I added a new def so I can write \metavar{suffix}. Maybe it should just be \var or \meta. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3948: Evaluate \code{e} to an object $o$. On 2016/11/03 18:07:03, eernst wrote: > `\code{e}` --> `$e$` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3950: Evaluate $t.suffix$ to an object. On 2016/11/03 18:07:06, eernst wrote: > `$t.suffix$` --> `\code{$t$.\mbox{\em suffix}}` just to be consistent (I doubt > it looks very different ;-) Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3954: 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 == \NULL{} ? \NULL{} : t.{\em suffix}} where \code{t} is bound to the value of $e$. On 2016/11/03 18:07:06, eernst wrote: > might as well say `$t$ is a fresh variable bound to..` as usual. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4045: If $e_1$ is not a type literal, evaluation of a {\em conditional property extraction expression} $e$ of the form $e_1?.id$ proceeds as follows: On 2016/11/03 18:07:05, eernst wrote: > I think it would be useful to reorganize this a bit: > > `Evaluation of .. proceeds as follows: If $e_1$ is a type literal, $e$ is > equivalent to $e_1.id$. Otherwise, evaluate $e_1$ to an object $o$. ..`. > > The point is again that the short alternative is first, such that the list > structure is more obvious, which means that it is OK that the last alternative > is contains several sentences. > > Also, I suspect that math mode '?' might be different from \sffamily '?', in > which case we should probably use `$e_1$?.$id$` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4049: Otherwise let $x$ be a fresh variable bound to $o$ and evaluate \code{$x$.id} to a value $r$. \code{$e_1$.\metavar{id}} Logical formatting FTW! https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4052: If $e_1$ is a type literal, $e$ is equivalent to $e_1.m$. On 2016/11/03 18:07:06, eernst wrote: > (If the reorg above is performed, this line is moved up). Acknowledged. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4496: Evaluation of an assignment $a$ of the form \code{$e_1$?.v = $e_2$} On 2016/11/03 18:07:06, eernst wrote: > If we keep metavariables in math mode, it should be `\code{$e_1$.$v$ = $e_2$}`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4501: Otherwise let $x$ be a fresh variable bound to $o$ and evaluate \code{$o$.v = $e_2$} to an object $r$. On 2016/11/03 18:07:04, eernst wrote: > `\code{$o$.$v$ = $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4504: If $e_1$ is a type literal, $a$ is equivalent to $e_1.v$ \code{=} $e_2$. On 2016/11/03 18:07:04, eernst wrote: > We could reorganize this as well, both for consistency with the previous text > and for the reasons mentioned earlier: > > `If $e_1$ is a type literal, $a$ is equivalent to \code{$e_1$.$v$ = $e_2$}. > > Otherwise, $e_2$ is not a type literal. Evaluate $e_1$ to ..` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4599: Call the method $[]=$ on $a$ with $i$ as first argument and $v$ as second argument. On 2016/11/03 18:07:04, eernst wrote: > The method name is actually concrete syntax, so that would be `\code{[]=}`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4602: The static type of the expression $e_1[e_2]$ \code{=} $e_3$ is the static type of $e_3$. I'm all for consistency. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4622: Evaluation of a compound assignment $a$ of the form $v$ {\em ??=} $e$ On 2016/11/03 18:07:06, eernst wrote: > I'd say `of the form \code{$v$ ??= $e$}`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4631: Evaluation of a compound assignment, $a$ of the form $C.v$ {\em ??=} $e$, where $C$ is a type literal, proceeds as follow: On 2016/11/03 18:07:03, eernst wrote: > `of the form \code{$C$.$v$ ??= $e$}, ..` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4643: Evaluation of a compound assignment $a$ of the form $e_1.v$ {\em ??=} $e_2$ On 2016/11/03 18:07:03, eernst wrote: > `of the form \code{$e_1$.$v$ ??= $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4647: Let \code{x} be a fresh variable not occuring in $e_2$ and bound to $u$. On 2016/11/03 18:07:07, eernst wrote: > `$x$`, `occuring` --> `occurring`, but it's not fresh if it occurs anywhere, so > let's just say `a fresh variable bound to $u$`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4648: Evalute \code{x.$v$} to an object $o$. On 2016/11/03 18:07:04, eernst wrote: > `\code{$x$.$v$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4650: Otherwise evaluate \code{x.$v$ = $e_2$} to an object $r$, On 2016/11/03 18:07:04, eernst wrote: > `\code{$x$.$v$ = $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4654: Evaluation of a compound assignment $a$ of the form $e_1[e_2]$ {\em ??=} $e_3$ On 2016/11/03 18:07:05, eernst wrote: > `\code{$e_1$[$e_2$] ??= $e_3$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4658: Call the $[]$ method on $u$ with argument $i$ and let $o$ be the returned value. On 2016/11/03 18:07:04, eernst wrote: > `\code{[]}`, add comma: `argument $i$, and let` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4661: and then call the $[]=$ method on $u$ with $i$ as first argument and $v$ as second argument. On 2016/11/03 18:07:04, eernst wrote: > `\code{[]=}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4665: Evaluation of a compound assignment $a$ of the form $\SUPER.v$ {\em ??=} $e$ On 2016/11/03 18:07:04, eernst wrote: > `\code{\SUPER.$v$ ??= $e$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4668: Evaluate $\SUPER.v$ to an object $o$. On 2016/11/03 18:07:06, eernst wrote: > `\code{\SUPER.$v$}` > > Ok, ok, this only changes the font of the period, but it still feels good to > follow a consistent approach. ;-) For instance, if we wish to make concrete > syntax blue then we would get it right just by adapting the definition of > \code{}, if we have been consistent. Acknowledged. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4674: Evaluation of a compound assignment $a$ of the form $e_1?.v$ {\em ??=} $e_2$ On 2016/11/03 18:07:04, eernst wrote: > `\code{$e_1$?.$v$ ??= $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4677: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. On 2016/11/03 18:07:04, eernst wrote: > `$x$` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4678: Evaluate \code{x.$v$} to an object $o$. On 2016/11/03 18:07:07, eernst wrote: > `\code{$x$.$v$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4680: Otherwise evaluate \code{x.$v$ = $e_2$} to an object $r$, On 2016/11/03 18:07:06, eernst wrote: > `\code{$x$.$v$ = $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4705: 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$. On 2016/11/03 18:07:06, eernst wrote: > `\code{$v$ $op$= $e$}`, `\code{$v$ = $v$ $op$ $e$}`, > `\code{$C$.$v$ $op$= $e$}`, `\code{$C$.$v$ = $C$.$v$ $op$ $e$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4708: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. On 2016/11/03 18:07:06, eernst wrote: > `$x$` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4709: Evaluate \code{x.$v$ = x.$v$ $op$ $e_2$} to an object $r$ On 2016/11/03 18:07:06, eernst wrote: > `\code{$x$.$v$ = $x$.$v$ $op$ $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4714: Let \code{a} and \code{i} be fresh variables bound to $u$ and $v$ respectively. On 2016/11/03 18:07:05, eernst wrote: > `$a$`, `$i$` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4715: Evaluate \code{a[i] = a[i] $op$ $e_3$} to an object $r$, On 2016/11/03 18:07:07, eernst wrote: > `\code{$a$[$i$] = $a$[$i$] $op$ $e_3$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4719: Evaluation of a compound assignment $a$ of the form \code{$e_1$?.$v$ $op$ = $e_2$} proceeds as follows: On 2016/11/03 18:07:03, eernst wrote: > Drop the space before `=`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4721: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. On 2016/11/03 18:07:05, eernst wrote: > `$x$` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4722: Evaluate \code{x.$v$} to an object $o$. On 2016/11/03 18:07:05, eernst wrote: > `\code{$x$.$v$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4723: If $o$ is the null value, then $a$ evaluates to the null value. On 2016/11/03 18:07:03, eernst wrote: > Isn't the question whether $x$ (or $u$) is the null value, not $o$? In that case > the test should go before evaluating \code{$x$.$v$}. > > $o$ is just the "before" value that we are going to use on the right hand side > of `=` to compute an "after" value which is than assigned to $x$.$v$. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4723: If $o$ is the null value, then $a$ evaluates to the null value. On 2016/11/03 18:07:03, eernst wrote: > Isn't the question whether $x$ (or $u$) is the null value, not $o$? In that case > the test should go before evaluating \code{$x$.$v$}. Ack, true. I was probably still thinking of ??=. Rewritten (and shorter). https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4724: Otherwise let \code{y} be a fresh variable bound to $o$ On 2016/11/03 18:07:03, eernst wrote: > `$y$` Acknowledged. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4725: and evaluate \code{x.$v$ = t $op$ $e_2$} to an object $r$. On 2016/11/03 18:07:07, eernst wrote: > `\code{$x$.$v$ = $y$ $op$ $e_2$}` Acknowledged. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4728: The static type of $e_1?.v$ $op = e_2$ is the static type of $e_1.v$ $op$ $e_2$. Exactly the same static warnings that would be caused by $e_1.v$ $op = e_2$ are also generated in the case of $e_1?.v$ $op = e_2$. On 2016/11/03 18:07:05, eernst wrote: > `\code{$e_1$?.$v$ $op$= $e_2$}`, `\code{$e_1$.$v$ $op$ $e_2$}`, `\code{e_1$.$v$ > $op$= $e_2$}`, `\code{$e_1$?.$v$ $op$= $e_2$}`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4796: Evaluation of an if-null expression $e$ of the form $e_1??e_2 $ On 2016/11/03 18:07:03, eernst wrote: > `\code{$e_1$ ?? $e_2$}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5177: Evaluate $v$ to an object $r$ and let \code{t} be a fresh variable bound to $r$. On 2016/11/03 18:07:05, eernst wrote: > $t$ Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5178: Evaluate \code{$v$ = y + 1}. On 2016/11/03 18:07:04, eernst wrote: > `\code{$v$ = $y$ + 1}` Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5189: Evaluation of a postfix expression $e$ of the form \code{$C.v$ ++} On 2016/11/03 18:07:03, eernst wrote: > Drop the space before `++`. Done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5281: Evaluate $e_1$ to an object $u$ and let \code{x} be a fresh variable bound to $u$. All the above comments: done. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5282: Evaluate \code{u.$v$} to an object $o$. ack, same bug. Fixed. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5283: If $o$ is the null value, then $e$ evaluates to the null value. On 2016/11/03 18:07:07, eernst wrote: > This test may then be moved up before computing $x$.$v$, and checking on $u$ > rather than $o$. Acknowledged. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5285: and evaluate \code{u.$v$ = y + 1}. Rewritten to just evaluate \code{$x$.$v$++}. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5294: Evaluation of a postfix expression $e$ of the form \code{$e_1?.v$-{}-} -- case fixed the same way as ++. https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5614: } Absolutely. I thought I removed it. One undo too many! https://codereview.chromium.org/2433943002/diff/20001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5751: f(x) $=>$ x++; // a top level function OK, but not consistent with the following lines. We should make a \=> macro (\arr?) There is a macro for \> - could we just write =\> ?
LGTM, with comments on a bunch of missing `\LMHash{}` and a few typos.
I just tested whether `>` produces the correct glyph in a `dartCode`
environment: It doesn't! So we must use `=$>$` and not `=>` (nor `$=$>`).
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dart.sty
File docs/language/dart.sty (right):
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dart.sty#...
docs/language/dart.sty:10: \def\metavar#1{\ensuremath{\mathit{#1}}}
Yes!
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
File docs/language/dartLangSpec.tex (right):
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:931: f(x) $=$> 3;
Oops, that wouldn't work! `$>$` may be needed (rather than a plain `>`) in order
to avoid getting the upside-down question mark glyph. But `$=$` should not be
needed (in a `dartCode` environment it should be a sans serif equals sign, and
there's nothing wrong with that, and it should have text spacing, not math
spacing, so `=` is still fine and `$=$` not needed).
So if this doesn't produce the upside-down question mark then line 931 does not
need to have any `$`s at all, but if it does produce that glyph then it should
contain two `$`s: `$>$`.
Similarly for all the other, similar cases.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:940: \STATIC{} f(x) $=$> 3;
`$>$`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:3955: 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 \code{$e$?..\metavar{suffix}} to be equivalent to the expression
\code{$t$ == null ? null : $t$.\metavar{suffix}} where \code{t} is a fresh
variable bound to the value of $e$.
`where $t$ is`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4047: If $e_1$ is a type literal, $e$ is
equivalent to $e_1.m$.
I believe it has to be `\code{$e_1$.\metavar{id}}`, not `$e_1.m$`.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4393:
Add a new line with `\LMHash{}` after this line.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4397:
Add an `\LMHash{}` line.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4431: Otherwise evaluate \code{$C.v$ = $e$} to a
value $r$,
Might as well use `$C$.$v$` now that so many other locations are consistently
using this style.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4441:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4452:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4463:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4472:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4502:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4507:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4516:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4522:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4593:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4598:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4599: 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$.
`is least` --> `is the least`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4971:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4986:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4987: Evaluate $C.v$ to a value $r$ and let $y$
be a fresh variable bound to $r$.
Well, `\code{$C$.$v$}` would be the strictly consistent version.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4988: Evaluate \code{$C.v$ = $y$ + 1}.
`$C$.$v$`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4996: Evaluating of a postfix expression $e$ of
the form \code{$e_1$.$v$++}
`Evaluating` --> `Evaluation`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:4998:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5012:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5026:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5039:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5052:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5067:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5081:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5083:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5096:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5098:
`\LMHash{}`
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5374:
Actually the spec is not at all as consistent as I thought when it comes to
empty lines before sectioning commands. Let's just take one step in a separate
CL, and make them all one-line-blocks: Any attempt to make the LaTeX source look
like a wysiwyg document will fail anyway, so readability is not improved much by
"big break semantically, two empty lines" or anything like that. With that,
deletion of line 5220 is fine as well.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:5510: f(x) $=$> x++; // a top level function
Revert to `=$>$`, or just omit all `$`s if that works.
Description was changed from ========== Spec: Rewrite lambdas to simpler semantics instead. This is instead of introducing a let-construct. ========== to ========== Spec: Rewrite lambdas to simpler semantics instead. This is instead of introducing a let-construct. R=eernst@google.com Committed: https://github.com/dart-lang/sdk/commit/f3288982debc171ce144579b216c4a95010974b7 ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001) manually as f3288982debc171ce144579b216c4a95010974b7 (presubmit successful).
Message was sent while issue was closed.
https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... File docs/language/dartLangSpec.tex (right): https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:931: f(x) $=$> 3; Ack, yes, that's just me not reading what the original actually wrote. It should have been the same as the original. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:940: \STATIC{} f(x) $=$> 3; On 2016/11/09 11:35:37, eernst wrote: > `$>$` Acknowledged. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3955: 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 \code{$e$?..\metavar{suffix}} to be equivalent to the expression \code{$t$ == null ? null : $t$.\metavar{suffix}} where \code{t} is a fresh variable bound to the value of $e$. On 2016/11/09 11:35:37, eernst wrote: > `where $t$ is` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4047: If $e_1$ is a type literal, $e$ is equivalent to $e_1.m$. On 2016/11/09 11:35:37, eernst wrote: > I believe it has to be `\code{$e_1$.\metavar{id}}`, not `$e_1.m$`. Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4393: On 2016/11/09 11:35:38, eernst wrote: > Add a new line with `\LMHash{}` after this line. Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4397: On 2016/11/09 11:35:37, eernst wrote: > Add an `\LMHash{}` line. Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4431: Otherwise evaluate \code{$C.v$ = $e$} to a value $r$, On 2016/11/09 11:35:38, eernst wrote: > Might as well use `$C$.$v$` now that so many other locations are consistently > using this style. Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4441: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4452: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4463: On 2016/11/09 11:35:36, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4472: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4502: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4507: On 2016/11/09 11:35:38, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4516: On 2016/11/09 11:35:38, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4522: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4593: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4598: On 2016/11/09 11:35:38, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4599: 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$. On 2016/11/09 11:35:38, eernst wrote: > `is least` --> `is the least` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4971: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4986: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4987: Evaluate $C.v$ to a value $r$ and let $y$ be a fresh variable bound to $r$. On 2016/11/09 11:35:38, eernst wrote: > Well, `\code{$C$.$v$}` would be the strictly consistent version. Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4988: Evaluate \code{$C.v$ = $y$ + 1}. On 2016/11/09 11:35:37, eernst wrote: > `$C$.$v$` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4996: Evaluating of a postfix expression $e$ of the form \code{$e_1$.$v$++} On 2016/11/09 11:35:37, eernst wrote: > `Evaluating` --> `Evaluation` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:4998: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5012: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5026: On 2016/11/09 11:35:38, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5039: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5052: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5067: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5081: On 2016/11/09 11:35:38, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5083: On 2016/11/09 11:35:38, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5096: On 2016/11/09 11:35:37, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5098: On 2016/11/09 11:35:36, eernst wrote: > `\LMHash{}` Done. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5374: On 2016/11/09 11:35:38, eernst wrote: > Actually the spec is not at all as consistent as I thought when it comes to > empty lines before sectioning commands. Let's just take one step in a separate > CL, and make them all one-line-blocks: Any attempt to make the LaTeX source look > like a wysiwyg document will fail anyway, so readability is not improved much by > "big break semantically, two empty lines" or anything like that. With that, > deletion of line 5220 is fine as well. Acknowledged. https://codereview.chromium.org/2433943002/diff/40001/docs/language/dartLangS... docs/language/dartLangSpec.tex:5510: f(x) $=$> x++; // a top level function On 2016/11/09 11:35:37, eernst wrote: > Revert to `=$>$`, or just omit all `$`s if that works. Done.
Message was sent while issue was closed.
One post-hoc comment for the next CL: I think there's a spurious `f` in `$fi$`. https://codereview.chromium.org/2433943002/diff/60001/docs/language/dartLangS... File docs/language/dartLangSpec.tex (right): https://codereview.chromium.org/2433943002/diff/60001/docs/language/dartLangS... docs/language/dartLangSpec.tex:3926: 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 $fi$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of $F$. Spurious `f` in `$fi$`? |
