<u></u>

  
    
    
  
  <div text="#000000" bgcolor="#ffffff">
    On 28/09/11 18:11, Waldemar Horwat wrote:
    <blockquote type="cite">Thinking
      about the implications of paren-free, I see additional potential
      trouble spots in addition to the one I mentioned in the meeting
      yesterday:
      <br>
      <br>
      <blockquote type="cite">Start with ES5 code:
        <br>
        <br>
        if (a + b)
        <br>
         (x.y)()
        <br>
        z++
        <br>
        <br>
        Now (erroneously) convert it to paren-free:
        <br>
        <br>
        if a + b
        <br>
         (x.y)()
        <br>
        z++
        <br>
        <br>
        This doesn't give a syntax error; it silently changes the
        meaning of the program.
        <br>
      </blockquote>
    </blockquote>
    <br>
    I'm not sure how this is much different from the rules you have now
    with ASI, though if this were such a problem, a block statement
    could be required with paren-free conditions that aren't followed by
    a block sub-statement, or a keyword prefixed one. Though, again, I
    don't think it would make much sense  as the current syntax is
    pretty consistent with what's expected from ASI rules.<br>
    <br>
    Oh, yes, people often blame ASI because it's unintuitive and blah
    blah blah. I think it's more a problem of people expecting JS to be
    parsed as any other C-language family (more close to Java,
    perhaps?), whereas semicolons are treated in a manner almost close
    to Python, except for the fact you have tokens for implicit
    statement continuations instead of a single escape character for
    explicit statement continuation.<br>
    <br>
    <br>
    <blockquote type="cite">Another
      hidden pitfall of the paren-free experience is illustrated by the
      expression refactoring to add parentheses:
      <br>
      <br>
      Start with ES5 code:
      <br>
      <br>
      if (a + b/g > f) f = a + b/g
      <br>
      <br>
      Convert it to paren-free:
      <br>
      <br>
      if a + b/g > f {f = a + b/g}
      <br>
      <br>
      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:
      <br>
      <br>
      if (a + b)/g > f {f = (a + b)/g}
      <br>
      <br>
      Oops. Now the / starts a regexp. There is an extra closing brace
      which will simply close the enclosing scope early, so a syntax
      error likely won't appear for a while.
      <br>
      <br>
    </blockquote>
    This is more of a real problem, with which I am concerned with =/<br>
  </div>