Discuss
  • Reading tail calls specification

Reading tail calls specification

# T.J. Crowder (7 years ago)

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 is that b is in the tail position here (obviously, this is the easiest case):

function a() {
    // ...do something...
    return b();
}

...but not here:

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).

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, 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

# T.J. Crowder (7 years ago)

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:

"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

# Michael Dyck (7 years ago)

On 17-07-26 07:32 AM, T.J. Crowder wrote:

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.

No significance, just a styling thing. See tc39/ecma262#956

# T.J. Crowder (7 years ago)

On Wed, Jul 26, 2017 at 1:52 PM, Michael Dyck <jmdyck at ibiblio.org> wrote:

On 17-07-26 07:32 AM, T.J. Crowder wrote:

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.

No significance, just a styling thing. See tc39/ecma262#956

Thanks!

Ouch, that's time I'd really like back. The problem is in the ES2015 and ES2016 specs too, I assumed it had to mean something.

Astonishing timing that Logan Smyth should have opened that github issue just 18 hours prior to my post here, as the problem's been there for years.

-- T.J. Crowder

# Mike Samuel (7 years ago)

On Wed, Jul 26, 2017 at 9:01 AM, T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:

On Wed, Jul 26, 2017 at 1:52 PM, Michael Dyck <jmdyck at ibiblio.org> wrote:

On 17-07-26 07:32 AM, T.J. Crowder wrote:

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.

No significance, just a styling thing. See tc39/ecma262#956

Thanks!

Ouch, that's time I'd really like back. The problem is in the ES2015 and ES2016 specs too, I assumed it had to mean something.

I find it confusing too. Other specifications look similar but have significant indentation. For example, JLS uses a similar metagrammar: colons separate left hand sides from right, line breaks representing disjunction, and spaces conjunction. JLS Section 2.4 says "A very long right-hand side may be continued on a second line by clearly indenting the second line."

# Allen Wirfs-Brock (7 years ago)

On Jul 26, 2017, at 6:01 AM, T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:

Ouch, that's time I'd really like back. The problem is in the ES2015 and ES2016 specs too, I assumed it had to mean something.

Note that the irregular indentation does not occur in the ES2015 PDF which is a direct rendering of the MS Word source document that was in use at that time. The irregular indentation (at least then) as an artifact of the HTML rendering process.

www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262 6th edition June 2015.pdf, www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262 6th edition June 2015.pdf

# T.J. Crowder (7 years ago)

On Wed, Jul 26, 2017 at 4:31 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

Note that the irregular indentation does not occur in the ES2015 PDF which is a direct rendering of the MS Word source document that was in use at that time. The irregular indentation (at least then) as an artifact of the HTML rendering process.

So two separate causes. Fun fun fun. Still, needs sorting out, in my view ASAP. I'll try to carve out some time to take a stab at it this weekend.

-- T.J. Crowder