Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Mar 25, 2017 · 13 comments
Closed

Comments

@p5pRT
Copy link

p5pRT commented Mar 25, 2017

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

Searchable as RT131061$

@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2017

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
Copy link
Author

p5pRT commented Mar 25, 2017

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
Copy link
Author

p5pRT commented Mar 25, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Mar 26, 2017

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
Copy link
Author

p5pRT commented Mar 26, 2017

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
Copy link
Author

p5pRT commented Mar 26, 2017

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
Copy link
Author

p5pRT commented Mar 26, 2017

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
Copy link
Author

p5pRT commented May 3, 2017

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
Copy link
Author

p5pRT commented May 5, 2017

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
Copy link
Author

p5pRT commented Dec 5, 2017

From zefram@fysh.org

Documentation patched in commit 39dc9d1.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2018

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 p5pRT closed this as completed Jun 23, 2018
@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant