Reading tail calls specification

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Reading tail calls specification

T.J. Crowder-2
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







_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reading tail calls specification

T.J. Crowder-2
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 <[hidden email]> 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








_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reading tail calls specification

Michael Dyck
In reply to this post by T.J. Crowder-2
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 https://github.com/tc39/ecma262/issues/956

-Michael
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reading tail calls specification

T.J. Crowder-2
On Wed, Jul 26, 2017 at 1:52 PM, Michael Dyck
<[hidden email]> 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 https://github.com/tc39/ecma262/issues/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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reading tail calls specification

Mike Samuel
On Wed, Jul 26, 2017 at 9:01 AM, T.J. Crowder
<[hidden email]> wrote:

> On Wed, Jul 26, 2017 at 1:52 PM, Michael Dyck
> <[hidden email]> 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 https://github.com/tc39/ecma262/issues/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."
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reading tail calls specification

Allen Wirfs-Brock
In reply to this post by T.J. Crowder-2

On Jul 26, 2017, at 6:01 AM, T.J. Crowder <[hidden email]> 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.

<a href="https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262 6th edition June 2015.pdf" class="">https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262%206th%20edition%20June%202015.pdf 

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reading tail calls specification

T.J. Crowder-2
On Wed, Jul 26, 2017 at 4:31 PM, Allen Wirfs-Brock
> 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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss