<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 24, 2015 at 8:14 AM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I like #4. Normally in a situation like this I would still argue for #1. #4 is a complicated special case that breaks the normal pattern of operator precedence elsewhere in the language. The need for ** is not great enough to justify introducing a new special case for users to learn. <div><br></div><div>However, in this case, #4 is only technically complicated -- for those writing or reading spec docs like us. For normal users, the only complexity is a rarely encountered surprising static error. With a decent (and easy to generate) error message, these users will immediately know what they need to do to repair their program.<div><br></div><div>Significant programs are read much more than they are written. Both #2 and #3 will lead many readers to misread programs. For programs that are not rejected, #4 is no more confusing than #1. Altogether, for readers, #4 is better than #1 because ** is more readable than Pow.</div></div></div></blockquote><div><br></div><div>MarkM, I'm surprised you didn't also mention that there is precedent for #4 from your own E.</div><div><br></div><div>The E language chose to place math operations as methods on numbers, rather than on any static "Math" object, and does not have an exponentiation operator. In order to avoid precedence surprises of the category we're discussing, E statically rejects the combination of a unary prefix (negation) and unary postfix (method call) operator.</div><div><br></div><div>    -(2).pow(2)   # "ought to be" -4, is a syntax error</div><div>    -(2).max(2)   # "ought to be" 2, is a syntax error</div><div><br></div><div>(The parentheses around the number are not actually required in E, but I have included them for the sake of comparison to JS despite the lexical rejection of "1.foo" in JS.)</div><div><br></div><div>JavaScript already syntactically accepts the above programs (parsing "-" as lower precedence than ".foo()"), but #4 is in the same spirit of rejecting cases where there are conflicting or unclear precedents for operator precedence.</div></div></div></div>