Paren-free heads strawman

Brendan Eich brendan.eich at gmail.com
Mon Feb 1 19:27:48 UTC 2016


Did you read the proposal?
http://wiki.ecmascript.org/doku.php?id=strawman:paren_free

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

/be

On Mon, Feb 1, 2016 at 10:20 AM Andreas Rossberg <rossberg at google.com>
wrote:

> 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.
>
> On 1 February 2016 at 18:46, Brendan Eich <brendan.eich at gmail.com> wrote:
>
>> On Mon, Feb 1, 2016 at 8:02 AM kdex <kdex at kdex.de> wrote:
>>
>>> [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and
>>> [Brendan Eich](https://brendaneich.com/2010/11/paren-free/) 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:
>>
>>  https://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:
>>
>> https://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).
>>
>> /be
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160201/bf5025b8/attachment.html>


More information about the es-discuss mailing list