in reply to Re^7: Operator overloading with returning lists?
in thread Operator overloading with returning lists?

> I've no idea what you mean by "precedence is weaker than context",

Let me try to give you a counterexample, here precedence is stronger than scalar_of_array

DB<124> sub scal {return scalar @_ } DB<125> print scal ( (1,2) x 5 ) 10
that's the way I expected x-mult and scalar to work!

Cheers Rolf

Replies are listed 'Best First'.
Re^9: Operator overloading with returning lists?
by ikegami (Patriarch) on Dec 01, 2008 at 16:45 UTC

    scalar affects the behaviour of the operator for which it sets the context. If perl was written in Perl, scalar would look something like

    sub scalar { local $context = 'scalar'; return $child_op->(); }

    scalar does not convert the result of the operator. If perl was written in Perl, scalar would NOT look like

    sub scalar { return _coerce_to_scalar( $child_op->() ); }

    In "scalar((1,2)x5)", scalar affects the behaviour of x.
    In "scalar(@_)", scalar affects the behaviour of the array access.

      Thanx, good sumarization of the topic.

      just perldoc -f scalar

      There is no equivalent operator to force an expression to be interpolated in list context because in practice, this is never needed. If you really wanted to do so, however, you could use the construction @{[ (some expression) ]} , but usually a simple (some expression) suffices.
      "but usually a simple (some expression)" suffices looks like an unneccessary myth! ; )

      Cheers Rolf

        Indeed. Like it says earlier, "this is never needed".
Re^9: Operator overloading with returning lists?
by JavaFan (Canon) on Dec 01, 2008 at 16:33 UTC
    I still have no clue what you mean by "precedence is stronger than scalar_of_array". Could you explain what you mean instead of just giving examples? The result of your example is quite obvious to me; it doesn't contain a single surprise. But it doesn't explain to me what an earth "precedence is stronger than scalar_of_array" is. To me, it sounds as logical as "wednesday is bluer than noise".
      That the code in the parens have precedence in evaluation before a scalar-like function is applied on a returned list.

      Cheers Rolf

        Well, yes, but that's because what's inside the parens is an operand of an operator whose result is an argument to the function. It's not any different from:
        some_sub(EXPR1 + EXPR2)
        EXPR1 is evaluated before some_sub is called. And since perl5 doesn't have lazy evaluation, and unlike to get it any time soon, it's going to stay like this for a while.

        But that has little to do with precedence (or at least not with the precedence people talk about when talking about operator precedence); the only 'rule' that's in effect is that arguments (and parameters) are evaluated before the operators/subs themselves.