From @moritz

IMHO this is important to understanding how operators work in Perl 5,
and it's not documented very clearly in perlop so far.

From @moritz

From 2fbfb0b04603b2ef347dcf3eaf33504665de38e0 Mon Sep 17 00:00:00 2001
From: Moritz Lenz <moritz@faui2k3.org>
Date: Sun, 21 Apr 2013 16:11:06 +0200
Subject: [PATCH] document that it is the operator that determines the
 operation

In many other dynamic languages it is the operator plus the type of the
first operand, so it is worth mentioning.
---
 pod/perlop.pod |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/pod/perlop.pod b/pod/perlop.pod
index 40402be..1fed7f1 100644
--- a/pod/perlop.pod
+++ b/pod/perlop.pod
@@ -5,6 +5,22 @@ perlop - Perl operators and precedence
 
 =head1 DESCRIPTION
 
+In Perl, the operator determines what operation is performed,
+independent of the type of the operands. For example C<$a + $b>
+is always a numeric addition, and if C<$a> or C<$b> do not contain
+numbers, and attempt is made to convert them to numbers first.
+
+This is in contrast to many other dynamic languages, where the
+operation is determined by the type of the first argument. It also
+means that Perl has two versions of some operators, one for numeric
+and one for string comparison. For example C<$a == $b> compares
+two numbers for equality, and C<$a eq $b> compares two strings.
+
+There are a few exceptions though: C<x> can be either string
+repetition or list repetition, depending on the type of the left
+operand, and C<&>, C<|> and C<^> can be either string or numeric bit
+operations.
+
 =head2 Operator Precedence and Associativity
 X<operator, precedence> X<precedence> X<associativity>
 
-- 
1.7.10.4

From tchrist@perl.com

Moritz Lenz (via RT) <perlbug-followup@​perl.org> wrote
  on Sun, 21 Apr 2013 07​:14​:13 PDT​:

+In Perl, the operator determines what operation is performed,
+independent of the type of the operands. For example C<$a + $b>
+is always a numeric addition, and if C<$a> or C<$b> do not contain
+numbers, and attempt is made to convert them to numbers first.

Absent any operator overloading on object operands.

--tom

The RT System itself - Status changed from 'new' to 'open'

From perrettdl@googlemail.com

"and attempt is made" should read "an attempt is made"

Daniel

On 21 April 2013 15​:14, Moritz Lenz <perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Moritz Lenz
# Please include the string​: [perl #117689]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=117689 >

IMHO this is important to understanding how operators work in Perl 5,
and it's not documented very clearly in perlop so far.

From @ap

* Moritz Lenz <perlbug-followup@​perl.org> [2013-04-21 20​:35]​:

+There are a few exceptions though​: C<x> can be either string
+repetition or list repetition, depending on the type of the left
+operand,

This one is not…

and C<&>, C<|> and C<^> can be either string or numeric bit
+operations.

… at all like these.

The meaning of `x` is dependent only on whether there are parentheses
around its left operand or not. What any `x` means is known at compile
time and depends only on the source text, never the run time values of
its operands. This is just like most Perl 5 operators and is in sharp
contrast to the bit ops whose behaviour depends *at run time* on the
flag bits their operands.

It is as though Perl 5 has two different repetition operators that just
so happen to look very similar (one spelled with parentheses followed
by `x`, the other spelled with the invisible absence of parentheses
followed by `x`), of which both are monomorphic just like most Perl 5
operators.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @moritz

On 04/26/2013 10​:45 PM, A. Pagaltzis via RT wrote​:

* Moritz Lenz <perlbug-followup@​perl.org> [2013-04-21 20​:35]​:

+There are a few exceptions though​: C<x> can be either string
+repetition or list repetition, depending on the type of the left
+operand,

This one is not…

and C<&>, C<|> and C<^> can be either string or numeric bit
+operations.

… at all like these.

The meaning of `x` is dependent only on whether there are parentheses
around its left operand or not. What any `x` means is known at compile
time and depends only on the source text, never the run time values of
its operands. This is just like most Perl 5 operators and is in sharp
contrast to the bit ops whose behaviour depends *at run time* on the
flag bits their operands.

It is as though Perl 5 has two different repetition operators that just
so happen to look very similar (one spelled with parentheses followed
by `x`, the other spelled with the invisible absence of parentheses
followed by `x`), of which both are monomorphic just like most Perl 5
operators.

so, how would you formulate it?

(There is even a third one​: reverse() does either list reversal or
string reversal, but depending on the context, not on the type of the
arguments)

From @ap

* Moritz Lenz <moritz@​faui2k3.org> [2013-05-06 20​:35]​:

On 04/26/2013 10​:45 PM, A. Pagaltzis via RT wrote​:

* Moritz Lenz <perlbug-followup@​perl.org> [2013-04-21 20​:35]​:

+There are a few exceptions though​: C<x> can be either string
+repetition or list repetition, depending on the type of the left
+operand,

This one is not…

and C<&>, C<|> and C<^> can be either string or numeric bit
+operations.

… at all like these.

The meaning of `x` is dependent only on whether there are parentheses
around its left operand or not. What any `x` means is known at
compile time and depends only on the source text, never the run time
values of its operands. This is just like most Perl 5 operators and
is in sharp contrast to the bit ops whose behaviour depends *at run
time* on the flag bits their operands.

It is as though Perl 5 has two different repetition operators that
just so happen to look very similar (one spelled with parentheses
followed by `x`, the other spelled with the invisible absence of
parentheses followed by `x`), of which both are monomorphic just like
most Perl 5 operators.

so, how would you formulate it?

(There is even a third one​: reverse() does either list reversal or
string reversal, but depending on the context, not on the type of the
arguments)

After thinking about this for a long time, I went back to the didactic
purpose of this paragraph. I think the idea should be to help a novice
“think Perl” sooner. This paragraph helps by making explicit an abstract
design principle that isn’t really spelled out in the following concrete
information.

Is it the goal here to instil encyclopædic knowledge of Perl arcana?
I don’t think so.

Is it useful to alert the novice to exceptions that cause problems?
I think so.

In these terms, `x` and `reverse` are neither truly exceptions nor do
they cause problems. (OK, `reverse` is slightly slippery, but the
problem it does cause is of a different kind entirely compared to the
bitwise operators’, and an altogether smaller one.)

Didactically it therefore seems best to me to consider those two as
distracting detail, and leave them out entirely, while expanding further
on the ones that do cause problems.

So I would write something like this​:

  Beware of some notable unfortunate exceptions though​: the bitwise
  operators C<&>, C<|> and C<^> will treat their operands as either
  strings I<or> numbers, depending on how their values entered the
  program and what previous operations were performed on them. This
  can lead to subtle bugs unless you convert operands to a consistent
  form before passing them to such an operator.

This also goes beyond just giving the reader information, to giving them
a brief idea of what it means for them.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @moritz

On 05/27/2013 06​:32 PM, A. Pagaltzis via RT wrote​:

* Moritz Lenz<moritz@​faui2k3.org> [2013-05-06 20​:35]​:

On 04/26/2013 10​:45 PM, A. Pagaltzis via RT wrote​:

* Moritz Lenz<perlbug-followup@​perl.org> [2013-04-21 20​:35]​:

+There are a few exceptions though​: C<x> can be either string
+repetition or list repetition, depending on the type of the left
+operand,

This one is not…

and C<&>, C<|> and C<^> can be either string or numeric bit
+operations.

… at all like these.

The meaning of `x` is dependent only on whether there are parentheses
around its left operand or not. What any `x` means is known at
compile time and depends only on the source text, never the run time
values of its operands. This is just like most Perl 5 operators and
is in sharp contrast to the bit ops whose behaviour depends *at run
time* on the flag bits their operands.

It is as though Perl 5 has two different repetition operators that
just so happen to look very similar (one spelled with parentheses
followed by `x`, the other spelled with the invisible absence of
parentheses followed by `x`), of which both are monomorphic just like
most Perl 5 operators.

so, how would you formulate it?

(There is even a third one​: reverse() does either list reversal or
string reversal, but depending on the context, not on the type of the
arguments)

After thinking about this for a long time, I went back to the didactic
purpose of this paragraph. I think the idea should be to help a novice
“think Perl” sooner. This paragraph helps by making explicit an abstract
design principle that isn’t really spelled out in the following concrete
information.

Is it the goal here to instil encyclopædic knowledge of Perl arcana?
I don’t think so.

Where would the encyclopaedic knowledge about Perl operators be, if not
in perlop? It doesn't need to mentioned at the top of the document, but
IMHO it's important that it is mentioned somewhere in that document.

Is it useful to alert the novice to exceptions that cause problems?
I think so.

In these terms, `x` and `reverse` are neither truly exceptions

They don't? Of course they are. They are cases where it's not the
operator, but rather the context (scalar/list in the case of reverse,
and syntactic context in case of x).

nor do
they cause problems. (OK, `reverse` is slightly slippery, but the
problem it does cause is of a different kind entirely compared to the
bitwise operators’, and an altogether smaller one.)

Didactically it therefore seems best to me to consider those two as
distracting detail, and leave them out entirely, while expanding further
on the ones that do cause problems.

So I would write something like this​:

 Beware of some notable unfortunate exceptions though​: the bitwise
 operators C\<&>\, C\<|>  and C\<^>  will treat their operands as either
 strings I\<or>  numbers\, depending on how their values entered the
 program and what previous operations were performed on them\. This
 can lead to subtle bugs unless you convert operands to a consistent
 form before passing them to such an operator\.

This also goes beyond just giving the reader information, to giving them
a brief idea of what it means for them.

I'm fine with your proposed changes, though not with your reasoning
above :-)

Cheers,
Moritz

From @ap

Hi Moritz,

* Moritz Lenz <moritz@​faui2k3.org> [2013-05-29 02​:30]​:

On 05/27/2013 06​:32 PM, A. Pagaltzis via RT wrote​:

After thinking about this for a long time, I went back to the
didactic purpose of this paragraph. I think the idea should be to
help a novice “think Perl” sooner. This paragraph helps by making
explicit an abstract design principle that isn’t really spelled out
in the following concrete information.

Is it the goal here to instil encyclopædic knowledge of Perl arcana?
I don’t think so.

Where would the encyclopaedic knowledge about Perl operators be, if
not in perlop? It doesn't need to mentioned at the top of the
document, but IMHO it's important that it is mentioned somewhere in
that document.

It already is mentioned in the respective sections on `x` (and in the
section on `reverse` in… perlfunc. Why did you mention a function as
a counter-example for a principle regarding operators? Why did I never
notice?)

Is it useful to alert the novice to exceptions that cause problems?
I think so.

In these terms, `x` and `reverse` are neither truly exceptions

They don't? Of course they are. They are cases where it's not the
operator, but rather the context (scalar/list in the case of reverse,
and syntactic context in case of x).

I said “in these terms” they are not exceptions, i.e. they are not
exempt from the principle that operands get coerced to suit whatever
operation is being performed on them. `x` treats its operands (and
`reverse`, its arguments) as strings, even if they were NVs going in.

Only the bitwise operators (and smartmatch…) are exceptional in that
particular sense.

nor do they cause problems. (OK, `reverse` is slightly slippery, but
the problem it does cause is of a different kind entirely compared
to the bitwise operators’, and an altogether smaller one.)

Didactically it therefore seems best to me to consider those two as
distracting detail, and leave them out entirely, while expanding
further on the ones that do cause problems.

So I would write something like this​:

 Beware of some notable unfortunate exceptions though​: the
 bitwise operators C\<&>\, C\<|> and C\<^> will treat their operands
 as either strings I\<or> numbers\, depending on how their values
 entered the program and what previous operations were performed
 on them\. This can lead to subtle bugs unless you convert
 operands to a consistent form before passing them to such an
 operator\.

This also goes beyond just giving the reader information, to giving
them a brief idea of what it means for them.

I'm fine with your proposed changes, though not with your reasoning
above :-)

Well then. :-)

I mean it’s doable to mention `x` as an exception there too, but to my
mind it would have to be extra text beyond this bit, because it really
is a different case. And (repeating myself,) I don’t see the value here.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @tonycoz

On Fri Apr 26 13​:45​:11 2013, aristotle wrote​:

The meaning of `x` is dependent only on whether there are parentheses
around its left operand or not. What any `x` means is known at compile
time and depends only on the source text, never the run time values of
its operands. This is just like most Perl 5 operators and is in sharp
contrast to the bit ops whose behaviour depends *at run time* on the
flag bits their operands.

It is as though Perl 5 has two different repetition operators that just
so happen to look very similar (one spelled with parentheses followed
by `x`, the other spelled with the invisible absence of parentheses
followed by `x`), of which both are monomorphic just like most Perl 5
operators.

That's not entirely true, () x acts non-() x in scalar context​:

$ perl -le '@​x = qw(a b); $, = ","; sub f { (@​x) x 5 } print scalar f();
print f();'
22222
a,b,a,b,a,b,a,b,a,b

Thanks, applied as ae3f739 with the and
-> an change mentioned by Daniel.

Tony

@tonycoz - Status changed from 'open' to 'resolved'