Hi - OK, with no loud complaints and some signs of encouragement, I went ahead and made the change. It looks like only tests that are checking precedence actually fail:
[Error matching program output for expressions/bradc/bitopsVsEqualtyPrec] [Error matching program output for performance/compiler/bradc/compSampler-timecomp] [Error matching program output for trivial/deitz/test_all_precedence_levels_in_a_single_expression] [Error matching program output for trivial/shannon/compSampler] (everything else passes). I found the predecence within the binary operations acceptable, but the change below moves them to be among + and * (instead of hanging around == and friends): Index: compiler/parser/chapel.ypp =================================================================== --- compiler/parser/chapel.ypp (revision 22502) +++ compiler/parser/chapel.ypp (working copy) @@ -107,13 +107,13 @@ %left TDOTDOT %left TOR %left TAND +%left TEQUAL TNOTEQUAL +%left TLESSEQUAL TGREATEREQUAL TLESS TGREATER %left TBOR %left TBXOR +%left TPLUS TMINUS %left TBAND -%left TEQUAL TNOTEQUAL -%left TLESSEQUAL TGREATEREQUAL TLESS TGREATER %left TSHIFTLEFT TSHIFTRIGHT -%left TPLUS TMINUS %right TUPLUS TUMINUS %left TSTAR TDIVIDE TMOD %right TBNOT TNOT While I am here though, it seems strange to me that .. binds so loosely (above == ): writeln( 1..10 == 1..10 ); gives an error. With this change,the binary operations (which make sense to go inside of the ..) are in a group binding tighter than ==. So I'd like to also move .. (ie TDOTDOT) to between <= and | -- at the risk of making ranges on Bools nonsense (but I really doubt that people were writing a&&b..c. I will run the tests again with that change and let you know what happens. -michael On 01/06/2014 02:52 PM, Brad Chamberlain wrote: > > I've spoken with Michael a bit about this off-list, and the summary of my > thoughts is: > > * I don't necessarily feel beholden to the C operator precedence list (it > is what led to the current state of the affairs, not realizing that it > was considered flawed) > > * my approach would be to see what tests break under the testing system > under any new scheme and to use that as input into deciding whether to > switch or not. > > -Brad > > > On Thu, 2 Jan 2014, Michael Ferguson wrote: > >> Hi - >> >> I learned recently that even the creators of C (or at least, Dennis Ritchie) >> think that the bitwise operator precedence rules are wrong. See >> http://www.lysator.liu.se/c/dmr-on-or.html >> >> One way that this comes up is that if you are checking for particular >> bit, you have to write: >> if( (x & MASK) == MASK ) >> ... in other words, it would make more sense if & and other bitwise >> operations bind tighter than ==. >> >> I did a little survey of languages. >> >> The C way : C C++ Java Objective-C PHP C#, Javascript; >> in these languages, bitwise operations have lower precedence than ==. >> >> FORTRAN: bit ops not in language exactly >> >> GO: shift, bitwise and with multiply, bitwise or xor with + >> Erlang: bitwise and with *; all others bitwise ops with + >> Perl 6, Python, Ruby, Dart: all bitwise operators lower than + but before == >> >> I'm proposing that Chapel follow Go on this point, >> since shifting also means multiply by a power of 2. >> >> Some examples that I think work nicely this way: >> right-rotate: x >> 1 | x & 1 >> left-rotate: x << 1 | x >> 63 >> check mask set: if x & MASK == MASK >> check mask bit: if x & MASK != 0 // != 0 required because Chapel doesn't >> promote ints to bools >> append bits to number: x << 7 | new_bits >> >> >> Comments? >> >> Thanks, >> >> -michael >> >> >> P.S. Here are some precedence tables (from binds-tightest to loosest) >> for the various languages for the curious: >> >> GO (shift, and with multiply, or xor with +) >> * / % << >> & &^ >> + - | ^ >> == != < <= > >= >> && >> || >> >> Perl 6 (bitwise operators lower than + but before == ) >> ** >> ! + ~ etc unary operators >> * / % >> + - >> & >> | ^ >> != == etc >> && >> || >> (no shift operators) >> >> Erlang (bitwise and with *; all others with +) >> Unary + - bnot not >> / * div rem band and >> + - bor bxor bsl bsr or xor >> == etc >> >> Python (all bitwise ops lower than +, higher than ==) >> a[i], a.b >> ** >> + - ~ unary operators >> * / // % >> + - >> << >> >> & >> ^ >> | >> != == etc >> not x >> and >> or >> >> Ruby (all bitwise ops lower than +, higher than ==) >> a[i] >> ** >> ! ~ + - (unary) >> * / % >> + - >>>> << >> & >> ^ | >> <= > > >= >> == != (and others) >> && >> || >> not >> or and >> >> Dart (all bitwise ops lower than +, higher than ==) >> * / >> + - >> << >> >> & >> ^ >> | >> <= > <= < >> == != >> && >> || >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Chapel-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-developers >> ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
