in reply to Re: Re: Will/Can Perl 6 clean up the bit-wise operator precedence mess?
in thread Will/Can Perl 6 clean up the bit-wise operator precedence mess?

Getting people to remember the new precedences when writing new code would probably be really hard,

Actually, the proposed precedence should be easier to remember since it groups the bit-wise operators together and places them in a much more logical place in the order. (I'll just set aside my proposed change to the precedence of !, which I have changed my mind about.) I also doubt that most Perl programmers have bothered to memorize the current precedence of these particular operators as it is nearly non-sensical as well as mostly useless. The only thing worth memorizing about the current state is that you need to always use parens when dealing with bit-wise operators. If you do that, then a change in the precedence will have no effect on you.

Like you said, there'd be a flood of "why doesn't my script work?" questions.

I'd really like to see a single production script that would be affected by this change. To do so, it would have to be using code like what you wrote: if(  0 == $mask & $value  ) { which gets parsed as: if(  ( 0 == $mask ) & $value  ) { which computes a value of 1 or 0 (depending whether $mask is 0 or not), then does a bit-wise "and" with $value. When would you ever write code like that? You want to know whether $value is odd, but only if $mask is non-zero? If so, there are much clearer ways to write such code.

Using bit-wise operators on the Boolean results of comparison operators is a pretty useless act. Even the "named unary operators" return values that you are quite unlikely to want to perform bit-wise operations on.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: Will/Can Perl 6 clean up the bit-wise operator precedence mess?
by chipmunk (Parson) on Jun 03, 2001 at 18:37 UTC
    Pretty sneaky of you to retract your proposed change in precedence of ! in composing your response. :P I think it's fairly clear that changing the precedence of ! could lead to the problems I mentioned.

    The change in precedence of bitwise operators would be less problematic, both because it's a less significant change relative to the precedence chart, and because the current precedence is counter-intuitive.

    Besides the comparison operators, the precedence would also change when using bitwise operators with named unary operators. For example, rand $value & $mask is (rand $value) & $mask now, but would be rand($value & $mask) instead.

    That sort of code probably wouldn't appear in production either -- I expect a programmer would use parentheses to make the precedence explicit -- but it does seem slightly more likely than the == and & case.

[reply]
[d/l]
[select]

      At first, it made sense to me to get the bit-wise operators finally grouped together and also get the logical operators finally grouped together. Plus, I'd been recently surprised by the rather tight binding of !.

      But ! is also useful for extracting a Boolean value from a possibly-non-Boolean value. And since we don't have operators for "is logically equivalent" nor for "is not logically equivalent", it can be convenient to write, for example: if(  ! $expr == ! $cond  ) { Also, we do have negated versions of all of the comparison operators so there isn't much need for: if(  ! ( $value == $expr )  ) { So I realized that this change wasn't going to fly.

      But the main point of my proposal was the bit-wise operators (hence the title). I snuck the change to ! into the table but didn't mention it anywhere. And now I'm sneaking it back out. q-: Sorry for the confusion.

      It does make some (though not a lot of) sense to put ! in with the other unary operators.

              - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]

        Your reasons for doing this are somwhat bogus -- in perl6, one of the new operators (that you're ignoring in the table, so it's reasonable to overlook them) is a boolification operator, so you don't have to abuse !. Simply write ?$expr == ?$cond. Also, you could define a new operator, say infix:ile (for Is Logicly Equivlent To): 

        sub infix:ile is tighter(==) {
 ?$^a == ?$^b
}

        [download]
        (This uses theDamien's placeholder vars, which I'm not sure are in exactly as I've used them. I need to find time to read A6 again, more carefuly. Also, it may be possible to write this as... 
        sub infix:ile($a is bool, $b is bool) is tigheter(==) {
 $a == $b
}

        [download]
        And rely on the compiler to coerce the arguments to bools.)

        Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]
[d/l]
[select]

In Section Meditations