in reply to Difference between leftward and rightward list operators

Hello Firsov,

The following quote from the Camel Book (4th Edition, 2012, Chapter 3: “Unary and Binary Operators,” Section “Terms and List Operators (Leftward),” page 98) may help:

In the absence of parentheses, the precedence of list operators such as print, sort, chmod is either very high or very low depending on whether you look at the left side or the right side of the operator. (That’s what the “Leftward” is doing in the title of this section.) For example, in:
my @ary = (1, 3, sort 4, 2); print @ary; # prints 1324
the commas on the right of the sort are evaluated before the sort, but the commas on the left are evaluated after. In other words, a list operator tends to gobble up all the arguments that follow it, and then act like a simple term with regard to the preceding expression.

Hope that helps,

Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^2: Difference between leftward and rightward list operators
by Firsov (Novice) on Aug 02, 2015 at 13:01 UTC

    Thank you for answer, Athanasius!

    So there are no separately leftward and rightward operators. There is only precedence context for operator, am i right?

      Yes, and the leftward/rightward distinction applies only to list operators, which the Camel Book’s Glossary (p. 1064) defines as follows:

      list operator
      An operator that does something with a list of values, such as join or grep. Usually used for named built-in operators (such as print, unlink, and system) that do not require parentheses around their argument list.

      Of the functions listed in Chapter 27 of the Camel Book, the list operators are those which take a LIST as their only, or final, argument. Thus, any user-defined subroutine with a prototype having @ as its final element is also a “list operator.” (See perlsub#Prototypes.)

      Hope that helps,

      Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Re^2: Difference between leftward and rightward list operators
by eritain (Novice) on May 11, 2025 at 03:53 UTC

    For me, the traditional terms of leftward and rightward precedence always obscured more than they explained. On reflection, it's actually the "leftward" precedence that introduces the confusion.

    Operator precedence is just syntax sugar, right? Every expression can be notated without it, as long as every operator gets a pair of parentheses for its argument list. Precedence is just a convention for allowing some of the parentheses to go un-notated.

    When we look at an expression like $a + $b ** $c * $d we can imagine those parentheses being emitted from the operator's position and riding outward until some condition requires them to stop. Specifically, each operator's parentheses skate over operators of higher precedence, but stop before operators of lower precedence, or at the edges of the expression.

    This is exactly what's going on with the "rightward" precedence of the list operators: The implied right parenthesis continues rightward, scooping things into the operator's argument list, until it is stopped by the right edge of the expression or by one of the low-precedence boolean operators.

    But the assertion of their "leftward" precedence is superfluous. It contrives to say that the implied left parenthesis can't pull in any arguments from the left, but we already know that, because the list operators are prefix.

    We might just as well assert that the prefix unary operators also have maximal "leftward" precedence -- well of course they do, how could they not? perlop doesn't do this, it just lists them at what we might call their "rightward" precedence.

    (Well, ++ and -- appear to have a non-maximal "leftward" precedence, but that's solely because each of them represents a postfix operator as well as a prefix one.)

    I owe a bunch of this thinking to Jeffrey Kegler's blog post, "Do list operators have left/right precedence?" I've given the concept of rightward precedence more credit than he did in that post, but only because I had the benefit of reading his post and turning it over in my head for over a decade. Until I started writing this, I'd have affirmed what he wrote, that the concept is just incoherent.

    I also haven't made as much hay out of the "grouping operator" description, because the whole point of any operator precedence is to make operators sometimes group their arguments together without having to spell that out in parentheses; but again, that's with benefit of hindsight.