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

[tye]

I've recently been reminded how much I hate the fact that C got the precedence for the bit-wise operators completely wrong (something which I believe at least one of Kernighan and Ritchie have publicly admitted to).

I know I'm way past the Perl 6 RFC process and this isn't the Perl 6 discussion list. But I wanted to throw this out here first...

Wouldn't it be great if Perl 6 were to fix this brain damage that has plagued (well, a somewhat minor plague) C, C++, Perl 4, and now Perl 5?

Here is how I'd prefer to have operator precedence table in Perl (note that I'm listing only Perl 5 operators even though I know these change will never make it into Perl 5):

Associativity	Old	New
left	terms, (leftward) list ops	terms, (leftward) list ops
left	->	->
nonassoc	++ --	++ --
right	**	**
right	! ~ \ unary + and -	~ \ unary + and -
left	=~ !~	=~ !~
left	* / % x	* / % x
left	+ - .	+ - .
left	<< >>	<< >>
left	(n/a)	&
left	(n/a)	| ^
nonassoc	named unary ops	named unary ops
nonassoc	< > <= >= lt gt le ge	< > <= >= lt gt le ge
nonassoc	== != <=> eq ne cmp	== != <=> eq ne cmp
left	&	(n/a)
left	| ^	(n/a)
right	(n/a)	!
left	&&	&&
left	||	||
nonassoc	.. ...	.. ...
right	?:	?:
right	= += -= *= etc.	= += -= *= etc.
left	, =>	, =>
nonassoc	(rightward) list ops	(rightward) list ops
right	not	not
left	and	and
left	or xor	or xor

This preserves the relationship between the operators that you might already be mixing together, but removes the major breakedness of, for example, == binding tighter than &, |, and ^ so that you could finally just say: if(   0 == $mask & $value  ) {

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

[Abigail]

I do see ways of simplifying Perl's precedence table from 24 levels down to 18 levels, albeit with some damage to C compatibility in the less frequently used ops. More on that later.

Larry Wall in Apocalypse 1: The Ugly, the Bad, and the Good

-- Abigail

[tye]

And right before that:

We'll discuss precedence reform under Apocalypse 3,

...so something even more drastic is planned and I have a while to wait before I hear the details. Thanks.

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

[Brovnik]

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

[chipmunk]

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.

[tye]

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")

[Dominus]

Says tye:

I hate the fact that C got the precedence for the bit-wise operators completely wrong (something which I believe at least one of Kernighan and Ritchie have publicly admitted to).

The section "Neonatal C" in this paper by Dennis Ritchie explains why the precedence for the bitwise operators is wrong.

--
Mark Dominus
Perl Paraphernalia

[sierrathedog04]

Forking Perl's precedence rules from those of C would be a mistake.

It is part of Perl's philosophy that Perl is based upon C. When one reads Camel 2 (the version Merlyn co-wrote) one sees that adopting C's precedence rules was a deliberate decision in order to enhance Perl's C-ishness. Merlyn, LW and Tom Christiansen wrote in the 2nd chapter:

Note that any operators borrowed from C keep the same precedence relationship with each other, even where C's precedence is slightly screwy. (This makes learning Perl easier for C folks.)

It also makes learning C easier for Perl folks.

[Vynce]

<diatribe>
yes, but when they wrote that, perl was still a sincere second banana to C. to my mind, this is no longer the case; there are hordes of perl programmers who will never learn C or C++ because they have no need to. and, as i further understand it, perl6 will no longer be written in C. how much longer whould we encourage an artificial resemblance in the language?
</diatribe>

[davorg]

as i further understand it, perl6 will no longer be written in C

I think you may be confusing Perl 6 with Topaz.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

[John M. Dlugosz]

and, as i further understand it, perl6 will no longer be written in C

What will it be written in? C++ has the same operator precedence as C, so I assume you mean something besides that?