Discuss
  • Paren-free heads strawman

Paren-free heads strawman

# kdex (9 years ago)

I've noticed that there's a strawman that has been left untouched for quite a while, namely strawman:paren_free.

It intends to make parentheses in heads optional, making, for instance:

if x > 3 {
    /* … */
}

equivalent to:

if (x > 3) {
    /* … */
}

Does anyone know if there are still any efforts to bring this into a future version of EcmaScript?

The strawman hasn't been updated for five years, and I have the feeling that this addition was forgotten about. The last time I've heard anyone from TC39 talk about paren-free heads was at GOTO Aarhus 2013.

Note that the strawman also talks about backward compatibility:

For backward compatibility, we support parenthesized heads with any sub-statement. To preserve the LR(1) grammar this requires factoring out OtherStatement.

Thus, this proposal is intended to make no backward-incompatible syntactic or semantic changes to ES5. “Paren-free” is now > purely a relaxation of syntax rules.

If anyone seeks to try this out, Mozilla's Narcissus has been supporting it for years now. You can enable it via --paren-free.

# kdex (9 years ago)

I've noticed that there's a strawman that has been left untouched for quite a while, namely strawman:paren_free.

It intends to make parentheses in heads optional, making, for instance:

if x > 3 {
    /* … */
}

equivalent to:

if (x > 3) {
    /* … */
}

Does anyone know if there are still any efforts to bring this into a future version of EcmaScript?

The strawman hasn't been updated for five years, and I have the feeling that this addition was forgotten about. The last time I've heard anyone from TC39 talk about paren-free heads was at GOTO Aarhus 2013.

Note that the strawman also talks about backward compatibility:

For backward compatibility, we support parenthesized heads with any sub-statement. To preserve the LR(1) grammar this requires factoring out OtherStatement.

Thus, this proposal is intended to make no backward-incompatible syntactic or semantic changes to ES5. “Paren-free” is now > purely a relaxation of syntax rules.

If anyone seeks to try this out, Mozilla's Narcissus has been supporting it for years now. You can enable it via --paren-free.

# Alican Çubukçuoğlu (9 years ago)

Isn't this very unnatural? If you are into this kind of thing, why don't you code Coffee for example? (Or don't since saving a few keystrokes isn't worth your dignity.)

# kdex (9 years ago)

Well, try and define "natural" in the context of constructed languages. If this was a question of "naturalness" (whatever that may be), then really any deviation from what the language currently is, is "unnatural". Anyway, we're here to discuss, not to blindly judge. :)

Note that the parens serve no purpose whatsoever. They're actually just a relic dating back to Ken Thompson's re-interpretation of BCPL, B (1969), which in turn did this, because in FORTRAN, if x and ifx looked the same to the parser; the parens were thus needed for the parser to differentiate between the two.

Since C derived from B, virtually any language that derived from it adapted to this redundant syntax; nowadays, the parens exist solely for decoration.

Douglas Crockford and Brendan Eich seem to be in favor of making them optional; that's why the strawman exists.

# Andreas Rossberg (9 years ago)

Will

if x (y) (z);

parse as

if (x) ((y)(z));

or

if (x(y)) (z);

? And how do you parse it without infinite look-ahead?

# Bob Myers (9 years ago)

I love the paren-free head idea. But as an obsessive user of non-braced single-statement if/for/while bodies, I don't see the advantage of making the head paren-free at the cost of mandating braces for the body.

Has either of the following been considered:

if i < 3: foo();
if i < 3 do foo();

-- Bob

# Brendan Eich (9 years ago)

Braces required, see the old strawman.

# Brendan Eich (9 years ago)

On Mon, Feb 1, 2016 at 8:02 AM kdex <kdex at kdex.de> wrote:

Douglas Crockford and Brendan Eich seem

to be in favor of making them optional; that's why the strawman exists.

The strawman exists because I wrote it, yes.

I was inspired by the common (not ubiquitous) style of always bracing sub-statements. The paren-free meme did "stick" with Rust, but it seems doomed for JS on account of the problems Waldemar Horwat raised:

esdiscuss.org/topic/another-paren-free-gotcha

Not the cited example, that seemed to forget that paren-free requires braces around the sub-statement in absence of leading left paren after controlling keyword. I pointed this out here:

esdiscuss.org/topic/another-paren-free-gotcha#content-9

Waldemar's other example showed a refactoring hazard:

"""

if (a + b/g > f) f = a + b/g

Convert it to paren-free:

if a + b/g > f {f = a + b/g}

So far so good; it works. However, later someone discovers that the code had a logic error, the fix to which is to divide the sum a+b by c instead of dividing only b by c. So he fixes the code to:

if (a + b)/g > f {f = (a + b)/g}

"""

Anyway, the proposal predates 1JS (note my last message talks about "opt in") and needs a champion who can resolve the refactoring hazard worry (if possible).

# Andreas Rossberg (9 years ago)

This refactoring hazard is intimately tied to the infinite look-ahead problem. Teaching a parser to handle the latter case or examples like if (x) (y) -z {} correctly is gonna be all but easy. Either backtracking or terrifying grammar refactorings would be needed.

# Brendan Eich (9 years ago)

Did you read the proposal? strawman:paren_free

Yes, it means if you start a condition with '(' you are obligated to use paren-full not paren-free style. :