Sorry, I meant to mention that I checked my understanding of that specific
case against the current in-progress TCO implementation in V8 v5.8.283.41
(in Node 8.2.1 behind a flag), and it did indeed happily optimize the first
and not the second:
```js
"use strict";
// Optimized:
function a(val, count) {
++val;
return count > 0 ? a(val, count - 1) : val;
}
// Not optimized:
/*
function a(val, count) {
++val;
const r = count > 0 ? a(val, count - 1) : val;
return r;
}
*/
console.log(a(0, 1e6));
```
-- T.J. Crowder
On Wed, Jul 26, 2017 at 12:32 PM, T.J. Crowder <
[email protected]> wrote:
> I'm wrapping my head around the details of TCO in the spec. Two parts to
> this: 1. Could I ask someone to double-check me on a particular
> understanding, and 2. What's the significance of some productions in the
> various statement and expression rules being indented and set apart from
> others? (A problem I've had reading several parts of the spec. I feel a bit
> thick.)
>
> First, the particular: My read of [the definition of
> HasCallInTailPosition][1] is that `b` is in the tail position here
> (obviously, this is the easiest case):
>
> ```js
> function a() {
> // ...do something...
> return b();
> }
> ```
>
> ...but not here:
>
> ```js
> function a() {
> // ...do something...
> const r = b();
> return r;
> }
> ```
>
> I base that on the statement rule:
>
> ```
> ReturnStatement : returnExpression
> 1. Return HasCallInTailPosition of Expression with argument call.
> ```
>
> `r` is an *IdentifierReference* expression, which doesn't have a
> tail-position call (obviously, and also I believe in [the expression
> rules][3]).
>
> Am I reading that correctly?
>
> Second, the general: What's the significance of the indentation? Some
> productions are indented more than others, and I can't see meaning in it.
> For example, under [Statement Rules][2], there's (I'll try to replicate it
> faithfully here):
>
> ```
> FunctionStatementList: [empty]
> StatementListItem: Declaration
>
> Statement:
> VariableStatement
> EmptyStatement
> ExpressionStatement
> ContinueStatement
> BreakStatement
> ThrowStatement
> DebuggerStatement
>
> Block:{}
> ReturnStatement: return;
> LabelledItem: FunctionDeclaration
>
> IterationStatement:
> for (LeftHandSideExpression of AssignmentExpression) Statement
> for (var ForBinding of AssignmentExpression) Statement
> for (ForDeclaration of AssignmentExpression) Statement
>
> CaseBlock: {}
>
> 1. Return false.
> ```
>
> Similarly under the expression rules we start off with an
> *AssignmentExpression* rule indented, then a bunch of bitwise expression
> rules not indented, then several indented ones again, etc., on again off
> again, without apparent relationships between them.
>
> Thanks,
>
> -- T.J. Crowder
>
> [1]: http://www.ecma-international.org/ecma-262/8.0/index.html#
> sec-static-semantics-hascallintailposition
> [2]: http://www.ecma-international.org/ecma-262/8.0/index.html#
> sec-statement-rules
> [3]: http://www.ecma-international.org/ecma-262/8.
> 0/index.html#sec-expression-rules
>
>
>
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
