OK, I've also now changed the precedence of .. (I described that below), so that 1..10 == 1..10 works (as I would expect it to, anyway). It used to be that making that work would also make 1|2..10 be interpreted as 1|(2..10) but because of the movement of the binary ops to be more tightly binding than ==, 1|2..10 will be interpreted correctly either way now.
Only the 4 tests reported below fail. The current patch is: Index: compiler/parser/chapel.ypp =================================================================== --- compiler/parser/chapel.ypp (revision 22502) +++ compiler/parser/chapel.ypp (working copy) @@ -104,16 +104,16 @@ %left TFOR TFORALL TIF TATOMIC TSYNC TSINGLE %left TALIGN TBY THASH %left TIN -%left TDOTDOT %left TOR %left TAND +%left TEQUAL TNOTEQUAL +%left TLESSEQUAL TGREATEREQUAL TLESS TGREATER +%left TDOTDOT %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 Is this OK, assuming I fix up the 4 failing tests? Could somebody review? -michael On 01/06/2014 04:50 PM, Michael Ferguson wrote: > 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 > ------------------------------------------------------------------------------ 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
