Low-precedence and/or/not

[edemaine]

trafficstars

I'm out of time to continue work on this right now, so thought I'd post my progress so far for comments.

• New "low-precedence" operators and/or/not via parse tree and parenthesization, effectively just below &&/||/!
• Implement not in all cases (fixes #287)
• New coffeeAndOr restores CoffeeScript's precedence for and/or (same as &&/||)
• Old coffeeNot restores CoffeeScript's precedence for not (same as !)

I still need to fix a few tests (related to custom operators) and add actual tests, but you can see intended use in the added documentation.

Possible items to discuss:

• Name of coffeeAndOr and coffeeAndOrNot. Partly hampered by existing coffeeNot here, but not sure what's best.
• Is low-precedence and/or/not good (by default)?
  • In particular, do we like not x == y → not (x == y) as in Python but not CoffeeScript?
  • I think a || b and c || d → (a || b) && (c || d) is reasonable because, if you're mixing styles of operators, you probably expect something to happen. If you stick to one or the other, there's nothing surprising.
  • Lots of precedent (heh) for it: Ruby, Perl, LiveScript. Although they differ on the exact precedence (see #287).
• xor is not yet low-precedence, but it already didn't mix with &&/|| so not sure what's best... (This is also harder to fix.)
• Should custom operators be processed at regular or low precedence? Low precedence might make sense given that they're also words (currently), but on the other hand we're not changing precedence of word operators like instanceof so I'm not sure.

[STRd6]

Adding not at the same precedence as ! is good and should be done.

Having different precedence like perl is an interesting experiment that I think could have value but that value may be finding out that it is too confusing and there are always some weird cases (or we could luck out and find a perfect intuitive yet complex precedence ladder).

I think having the default be words and symbol logical operators have the exact same precedence but have a feature flag where we (or those interested) can try out zany ideas and get a feel for it it's worth the complexity.

Next steps:

• Merge not as synonymous with !.
• Experiment with alternative precedence of logical operators (could start with reading and documenting Ruby and perl pros and cons)
• Split out a separate issue for xor precedence
• Separate issue/discussion for research and experiments around custom operator precedence. One possibility is something like: operator someOp < otherOp := value where <, =, > could specify precedence in relation to other operators instead of the default precedence.