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

Presumably a change of precedence would make the job of the Perl5 to Perl6 converter even harder for more than the trivial cases.

And I can imagine the flood of "why doesn't my script work ?" questions.

But, I tend to agree that if you are going to make a break with backwards compatibility, you may as well fix some other bugs at the same time.

I guess that O'Reilly will do well out of the wholesale replacement of Perl books, which will all become inaccurate.
--
Brovnik

  • Comment on Re: Will/Can Perl 6 clean up the bit-wise operator precedence mess?

Replies are listed 'Best First'.
Re: Re: Will/Can Perl 6 clean up the bit-wise operator precedence mess?
by chipmunk (Parson) on Jun 03, 2001 at 01:12 UTC
    Actually, I think that changing operator precedence would be trivial to implement in an automatic conversion script; all it has to do is add parentheses:

    0 == $mask & $value becomes (0 == $mask) & $value
    !$switch + $base becomes (!$switch) + $base

    Getting people to remember the new precedences when writing new code would probably be really hard, on the other hand. Like you said, there'd be a flood of "why doesn't my script work?" questions.

[reply]
[d/l]
[select]

      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")
[reply]
[d/l]
[select]
        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]

In Section Meditations