[perl #117689] [PATCH] perlop: document that it is the operator that determines the operation

[Moritz Lenz]

# 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.perl.org:443/rt3/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.

[Tom Christiansen]

Moritz Lenz (via RT) <perlbug-...@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

[Daniel Perrett]

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

Daniel

[Aristotle Pagaltzis]

* Moritz Lenz <perlbug-...@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/>

[Moritz Lenz]

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)

[Aristotle Pagaltzis]

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

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.

[Moritz Lenz]

On 05/27/2013 06:32 PM, A. Pagaltzis via RT wrote:
> * Moritz Lenz<mor...@faui2k3.org> [2013-05-06 20:35]:

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

[Aristotle Pagaltzis]

Hi Moritz,

* Moritz Lenz <mor...@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.

[Tony Cook via RT]

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 ae3f739188e3ee21fa593cafc28023c533e8d9bf with the and
-> an change mentioned by Daniel.

Tony

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=117689