in reply to Precedence design question...'x' & arith

G'day perl-diddler,

To be honest, I got the impression that you made a coding error 

$ perl -MO=Deparse,-p -e 'my $str = " " x $col%$maxcol;'
(my $str = ((' ' x $col) % $maxcol));
-e syntax OK

[download]

and instead of simply fixing it with the addition of a pair of parentheses 

$ perl -MO=Deparse,-p -e 'my $str = " " x ($col%$maxcol);'
(my $str = (' ' x ($col % $maxcol)));
-e syntax OK

[download]

you decided that Perl should change to accomodate you.

If you simply want a maximum amount of indentation, your logic (regardless of syntax) is wrong. When you see your output starting to zigzag across the screen, will you change your code to 

$ perl -MO=Deparse,-p -e 'my $str = " " x $col > $maxcol ? $maxcol : $
+col;'
(my $str = (((' ' x $col) > $maxcol) ? $maxcol : $col));
-e syntax OK

[download]

instead of 

$ perl -MO=Deparse,-p -e 'my $str = " " x ($col > $maxcol ? $maxcol : 
+$col);'
(my $str = (' ' x (($col > $maxcol) ? $maxcol : $col)));
-e syntax OK

[download]

and then want the precedence of the ternary operator to change as well.

Now, let's say your indentation was based on tabs of four spaces and your check also needed to take a margin into consideration. This code would no longer work as expected under your new precedence rules: 

$ perl -MO=Deparse,-p -e 'length "    " x $expr + $margin'
length((('    ' x $expr) + $margin));
-e syntax OK

[download]
"The 'x' operator isn't commutative"

So what? The '/' and '%' operators aren't commutative either: do you want to change their precedence as well based on commutativity?

"So it would only change in P20 or P22 if it were to change, ..."

By that, I assume you mean version 5.20 or 5.22. The 'x' operator has been around, with the same precedence, since at least Perl 4 (it's in my first edition Programming perl) — so, that's at least 22 years (see perlhist) of code that could potentially just break for anyone upgrading perl.

"To me, it looks like a prime situation for perl's precedence rules to change in a mostly backwards compatible way ..."

There is nothing in your post that suggests backwards compatibility. Perhaps you also want: 

use feature 'diddler_precedence';

[download]

In closing, I see no merit whatsoever in what you're proposing. Just add the parentheses to your broken code and move on with your life.

-- Ken

Replies are listed 'Best First'.
Re^2: Precedence design question...'x' & arith
by perl-diddler (Chaplain) on Jul 05, 2013 at 05:38 UTC
    To be honest, I got the impression that you made a coding error
    Where did you get that impression? Did I ask why it didn't work? Could you explain what could possibly have given you that impression in anything I wrote?

    I get the impression that you are used to deciding what people want to do (or did do) and going off on a tangent. Example:

    If you simply want a maximum amount of indentation, your logic (regardless of syntax) is wrong. When you see your output starting to zigzag across the screen, will you change your code to
    This is a 2nd example in the same posting of you making assumptions about what I wanted and having no basis for doing so. You then go on to soapbox about how I should have done it. You didn't answer the original question at all but seem to be wanting to direct it onto something else entirely.

    Tell me, when you write text on a page, when you get to the right-hand margin, do you then write one letter per column going down, or do you zig-zag your writing back and forth?

    Most writers discover that when they push all their writing into one column, not only does it become unreadable, but they would lose any future changes in indentation. How would you propose to communicate the indent level increasing or decreasing after you've hit say, column 40 out of 80? Your suggested correction is based on your trying to fit my problem into your own problem. I don't want

    simply want a maximum amount of indentation,
    I want something that shows me when indentation has increased and decreased.

    Then you go off into another problem about tabs and how my algorithm won't work for that? Irrelevant to my problem space -- it's debug output.

    Which brings me back to the original problem where you think I made some coding mistake and want perl to change to fix it. Please explain why you think the current syntax is superior to what I suggest.

    You seem to think I wrote asking for your specious advice based on my lying about the initial assumptions. That you have a propensity such doesn't mean everyone does. Some of us are honest to a fault.

    What I want is for you to simplify my expression down to one single expression that needs no parentheses. I maintain that they need for parentheses in this simple expression are inherently unnecessary, and that perl requires them seems inefficient. It is an example of the lack-of-expressiveness in the language -- a lack of conciseness. Rather than doing something *useful*, it has to generate an error for a case that shouldn't be an error in the first place.

[reply]

In Section Seekers of Perl Wisdom