d at domenic.me (2015-10-12T20:24:03.841Z)
On Thu, Sep 24, 2015 at 8:14 AM, Mark S. Miller <erights at google.com> wrote:
> 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.
>
> 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.
>
> 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.
>
MarkM, I'm surprised you didn't also mention that there is precedent for #4
from your own E.
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.
-(2).pow(2) # "ought to be" -4, is a syntax error
-(2).max(2) # "ought to be" 2, is a syntax error
(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.)
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.
On Thu, Sep 24, 2015 at 8:14 AM, Mark S. Miller <erights at google.com> wrote: > 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. > > 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. > > 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. > MarkM, I'm surprised you didn't also mention that there is precedent for #4 from your own E. 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. -(2).pow(2) # "ought to be" -4, is a syntax error -(2).max(2) # "ought to be" 2, is a syntax error (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.) 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150927/42e0e4db/attachment.html>