Documentation of backslash operator inducing list context for its operand is missing

[p5pRT]

Migrated from rt.perl.org#131061 (status was 'resolved')

Searchable as RT131061$

[p5pRT]

From @hakonhagland

I could not find any documentation for the following behavior​:

$ perl -E '$s =\sort qw(a b c); say $$s'
c

According to the documentation for sort, the behavior of sort in scalar
context is undefined

$ perl -E '$s = sort qw(a b c); say "undef" if !defined $s'
undef

Apparently when using the backslash operator, sort does not consider
itself to be in scalar context any more, or else the first example should
give an undefined $$s.

I checked the following documentation​:

http​://perldoc.perl.org/perldata.html#List-value-constructors
http​://perldoc.perl.org/perlref.html
http​://perldoc.perl.org/perlop.html
http​://perldoc.perl.org/functions/sort.html

See also​:

http​://stackoverflow.com/q/42996519/2173773

Best regards,
Håkon Hægland

[p5pRT]

From zefram@fysh.org

Hakon Haegland wrote​:

Apparently when using the backslash operator, sort does not consider
itself to be in scalar context any more,

Indeed, it is in list context. If we perform the sort statically,
the code you gave is equivalent to

  $s = \qw(a b c);

and the refgen distributes, making this effectively

  $s = (\"a", \"b", \"c");

which ultimately behaves as

  $s = \"c";

                                    or else the first example should

give an undefined $$s.

No. Undefined behaviour means there is no specific thing that it
"should" do, not even being consistent with its undefined behaviour
under other circumstances.

There is no bug here, in either the behaviour or the documentation.

-zefram

[p5pRT]

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

[p5pRT]

From @hakonhagland

Thanks for the quick reply!

Indeed, it is in list context.

That is exactly what I am asking. Why is it list context? On the
left-hand side of the equation there is clearly a scalar context​:

$ perl -E '$s =\sort qw(a b c); say $$s'
c

I can make it list context by for example writing​:

$ perl -E '($s) =\sort qw(a b c); say $$s'
a

2017-03-25 23​:37 GMT+01​:00 Zefram via RT <perlbug-followup@​perl.org>​:

Hakon Haegland wrote​:

Apparently when using the backslash operator, sort does not consider
itself to be in scalar context any more,

Indeed, it is in list context. If we perform the sort statically,
the code you gave is equivalent to

    $s = \\qw\(a b c\);

and the refgen distributes, making this effectively

    $s = \(\\"a"\, \\"b"\, \\"c"\);

which ultimately behaves as

    $s = \\"c";

                                    or else the first example should

give an undefined $$s.

No. Undefined behaviour means there is no specific thing that it
"should" do, not even being consistent with its undefined behaviour
under other circumstances.

There is no bug here, in either the behaviour or the documentation.

-zefram

[p5pRT]

From Eirik-Berg.Hanssen@allverden.no

On Sat, Mar 25, 2017 at 11​:36 PM, Zefram <zefram@​fysh.org> wrote​:

There is no bug here, in either the behaviour or the documentation.

  Well, the documentation is not wrong. But I'd argue it is lacking.

  Given how important context is when programming in Perl, I'm surprised
perlop doesn't tell us what context the various operators impose on their
operands, or if they propagate context.

  I note that among the Symbolic Unary Operators, C<< \ >> is the only one
that imposes list context on its operand – C<< + >> propagates (void,
scalar, list) context, and the others impose scalar context.

  That the others impose scalar context is consistent with the "default"
previously given in perlop​: "With very few exceptions, these all operate on
scalar values only, not array values."

  That C<< + >> propagates context is implied (but IMO could better be
explicit) by perlop.

  That C<< \ >> imposes list context is not even implied by perlop.

  It seems to me Less Than Awesome that this exception for C<< \ >> is not
documented in perlop.

Eirik

[p5pRT]

From zefram@fysh.org

Hakon Haegland wrote​:

That is exactly what I am asking. Why is it list context?

Because the refgen operator supplies list context to its operand.
The context in which the refgen operator is placed is irrelevant.
Most Perl operators behave in this kind of manner, statically imposing
a context on their operands rather than passing through the outer context.

-zefram

[p5pRT]

From zefram@fysh.org

Eirik Berg Hanssen wrote​:

Given how important context is when programming in Perl, I'm surprised
perlop doesn't tell us what context the various operators impose on their
operands, or if they propagate context.

Yes, good point. I agree that the context behaviour of \ in particular
seems underspecified.

-zefram

[p5pRT]

From @khwilliamson

On Sun, 26 Mar 2017 01​:10​:47 -0700, zefram@​fysh.org wrote​:

Eirik Berg Hanssen wrote​:

Given how important context is when programming in Perl, I'm surprised
perlop doesn't tell us what context the various operators impose on their
operands, or if they propagate context.

Yes, good point. I agree that the context behaviour of \ in particular
seems underspecified.

-zefram

Can someone suggest a patch?
--
Karl Williamson

[p5pRT]

From @cpansprout

On Wed, 03 May 2017 09​:25​:15 -0700, khw wrote​:

On Sun, 26 Mar 2017 01​:10​:47 -0700, zefram@​fysh.org wrote​:

Eirik Berg Hanssen wrote​:

Given how important context is when programming in Perl, I'm surprised
perlop doesn't tell us what context the various operators impose on their
operands, or if they propagate context.

Yes, good point. I agree that the context behaviour of \ in particular
seems underspecified.

-zefram

Can someone suggest a patch?

I am too busy right now to suggest a patch, but I can outline the behaviour, including details that are currently undocumented​:

\ gives its operand list context, regardless of its own context, but it behaves specially when it comes to sigilled items.

\@​foo and \%foo do not flatten the aggregate. Similarly, \&foo does not call the subroutine.

Parentheses around an aggregate (\(@​foo), \(%foo)) cause flattening, but make no difference to other sigils.

Those parentheses only have that effect when they surround nothing else (except perhaps a unary + or trailing comma). So​:

\(@​foo, @​bar) # does not flatten either array
\(@​foo, (@​bar)) # flattens only @​bar

--

Father Chrysostomos

[p5pRT]

From zefram@fysh.org

Documentation patched in commit 39dc9d1.

-zefram

[p5pRT]

@cpansprout - Status changed from 'open' to 'pending release'

[p5pRT]

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

[p5pRT]

@khwilliamson - Status changed from 'pending release' to 'resolved'