unexpected parsing of "pp $_[0]" into "$_->pp([0])" #16793

p5pRT · 2018-12-22T21:24:18Z

Migrated from rt.perl.org#133736 (status was 'open')

Searchable as RT133736$

p5pRT · 2018-12-22T21:24:18Z

From @djerius

Created by @djerius

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected. Changing from $_ to a defined array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl 5.28.1:

Configured by dj at Mon Dec 17 10:30:49 EST 2018.

Summary of my perl5 (revision 5 version 28 subversion 1) configuration:
   
  Platform:
    osname=linux
    osvers=4.9.0-8-amd64
    archname=x86_64-linux_debian-9-thread-multi
    uname='linux macabre 4.9.0-8-amd64 #1 smp debian 4.9.110-3+deb9u5 (2018-09-30) x86_64 gnulinux '
    config_args='-de -Dprefix=/proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9 -Uinstallusrbinperl -Dperladmin=none -Dlocincpth=/proj/axaf/ots/include -Darchname=x86_64-linux_debian-9 -Dusethreads -Dotherlibdirs=/proj/axaf/simul/lib/perl5:/proj/axaf/simul/x86_64-linux_debian-9/lib/perl5 -Dloclibpth=/proj/axaf/ots/x86_64-linux_debian-9/lib -Dglibpth=/lib /usr/lib -Dldflags=-L/proj/axaf/ots/x86_64-linux_debian-9/lib -Wl,-rpath=/proj/axaf/ots/x86_64-linux_debian-9/lib -Duseshrplib'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/proj/axaf/ots/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-O2'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/proj/axaf/ots/include'
    ccversion=''
    gccversion='6.3.0 20170516'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags ='-L/proj/axaf/ots/x86_64-linux_debian-9/lib -Wl,-rpath=/proj/axaf/ots/x86_64-linux_debian-9/lib -fstack-protector-strong'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /proj/axaf/ots/x86_64-linux_debian-9/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
    libs=-lpthread -lnsl -lgdbm -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.24.so
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.24'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E -Wl,-rpath,/proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/5.28.1/x86_64-linux_debian-9-thread-multi/CORE'
    cccdlflags='-fPIC'
    lddlflags='-shared -O2 -L/proj/axaf/ots/x86_64-linux_debian-9/lib -fstack-protector-strong'



@INC for perl 5.28.1:
    /proj/axaf/simul/lib/perl5/x86_64-linux_debian-9-thread-multi
    /proj/axaf/simul/lib/perl5
    /home/dj/research/lib/perl5
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/site_perl/5.28.1/x86_64-linux_debian-9-thread-multi
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/site_perl/5.28.1
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/5.28.1/x86_64-linux_debian-9-thread-multi
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/5.28.1
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/site_perl/5.28.0/x86_64-linux_debian-9-thread-multi
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/site_perl/5.28.0
    /proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/lib/site_perl
    /proj/axaf/simul/lib/perl5/x86_64-linux_debian-9-thread-multi
    /proj/axaf/simul/lib/perl5
    /proj/axaf/simul/x86_64-linux_debian-9/lib/perl5


Environment for perl 5.28.1:
    HOME=/home/dj
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_MEASUREMENT=en_US.UTF-8
    LC_MONETARY=en_US.UTF-8
    LC_NUMERIC=en_US.UTF-8
    LC_PAPER=en_US.UTF-8
    LC_TIME=en_US.UTF-8
    LD_LIBRARY_PATH=/soft/SYBASE15.7/DataAccess64/ODBC/lib:/soft/SYBASE15.7/DataAccess/ODBC/lib:/soft/SYBASE15.7/OCS-15_0/lib:/soft/SYBASE15.7/OCS-15_0/lib3p64:/soft/SYBASE15.7/OCS-15_0/lib3p:
    LOGDIR (unset)
    PATH=/home/dj/.plenv/libexec:/home/dj/.plenv/plugins/link-axaf/bin:/home/dj/.plenv/plugins/perl-build/bin:/home/dj/.plenv/plugins/plenv-contrib/bin:/soft/SYBASE15.7/OCS-15_0/bin:/home/dj/.rbenv/shims:/home/dj/.rbenv/bin:/home/dj/.pyenv/plugins/pyenv-virtualenv/shims:/home/dj/.pyenv/shims:/home/dj/.pyenv/bin:/home/dj/.plenv/shims:/home/dj/.plenv/bin:/home/dj/root/bin:/home/dj/root/bin/hosts:/home/dj/research/bin:/proj/axaf/ots/pkgs/perl-5.28/x86_64-linux_debian-9/bin:/proj/axaf/bin:/proj/axaf/simul/bin:/proj/axaf/simul/x86_64-linux_debian-9/bin:/proj/axaf/ots/x86_64-linux_debian-9/bin:/proj/axaf/ots/bin:/usr/local/bin:/usr/sbin:/bin:/usr/bin:/soft/saord/bin
    PERL5LIB=/proj/axaf/simul/lib/perl5:/home/dj/research/lib/perl5
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2018-12-22T21:36:49Z

From @xenu

On Sat, 22 Dec 2018 13:24:18 -0800
"Diab Jerius $via RT$" <perlbug-followup@perl.org> wrote:

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

This is a bug report for perl from djerius@cpan.org,
generated with the help of perlbug 1.41 running under perl 5.28.1.

-----------------------------------------------------------------
[Please describe your issue here]

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected. Changing from $_ to a defined array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

It's called "indirect object syntax" and it's one of the worst perl
misfeatures: https://perldoc.pl/perlobj#Indirect-Object-Syntax

It's possible to disable it using indirect.pm pragma from CPAN: https://metacpan.org/pod/indirect

p5pRT · 2018-12-22T21:36:49Z

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

p5pRT · 2018-12-22T21:52:02Z

From @demerphq

Not sure that that fully explains things here, as $_ was not mentioned. It
might explain things if it parsed as

$_[0]->pp()

But as the OP noted it does not get parsed that way at all.

Yves

On Sat, 22 Dec 2018, 22:37 Tomasz Konojacki <me@xenu.pl wrote:

On Sat, 22 Dec 2018 13:24:18 -0800
"Diab Jerius $via RT$" <perlbug-followup@perl.org> wrote:

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

This is a bug report for perl from djerius@cpan.org,
generated with the help of perlbug 1.41 running under perl 5.28.1.

-----------------------------------------------------------------
[Please describe your issue here]

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected. Changing from $_ to a defined array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

It's called "indirect object syntax" and it's one of the worst perl
misfeatures: https://perldoc.pl/perlobj#Indirect-Object-Syntax

It's possible to disable it using indirect.pm pragma from CPAN:
https://metacpan.org/pod/indirect

p5pRT · 2018-12-22T22:38:29Z

From @djerius

On Sat, Dec 22, 2018 at 4:52 PM yves orton via RT <perlbug-followup@perl.org>
wrote:

Not sure that that fully explains things here, as $_ was not mentioned. It
might explain things if it parsed as

$_[0]->pp()

Sorry, I should have noted that this is how I expected it to be parsed.

But as the OP noted it does not get parsed that way at all.

Yves

On Sat, 22 Dec 2018, 22:37 Tomasz Konojacki <me@xenu.pl wrote:

On Sat, 22 Dec 2018 13:24:18 -0800
"Diab Jerius $via RT$" <perlbug-followup@perl.org> wrote:

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

This is a bug report for perl from djerius@cpan.org,
generated with the help of perlbug 1.41 running under perl 5.28.1.

-----------------------------------------------------------------
[Please describe your issue here]

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected. Changing from $_ to a defined
array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

It's called "indirect object syntax" and it's one of the worst perl
misfeatures: https://perldoc.pl/perlobj#Indirect-Object-Syntax

It's possible to disable it using indirect.pm pragma from CPAN:
https://metacpan.org/pod/indirect

p5pRT · 2018-12-22T23:12:33Z

From @Leont

On Sat, Dec 22, 2018 at 10:25 PM Diab Jerius (via RT)
<perlbug-followup@perl.org> wrote:

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected.

Indirect method calls are nasty like that :-(.

Changing from $_ to a defined array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

That is unexpected however.

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

p5pRT · 2018-12-23T01:28:57Z

From @djerius

On Sat, Dec 22, 2018, 6:12 PM Leon Timmermans via RT <
perlbug-followup@perl.org wrote:

On Sat, Dec 22, 2018 at 10:25 PM Diab Jerius (via RT)
<perlbug-followup@perl.org> wrote:

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected.

Indirect method calls are nasty like that :-(.

Is the split between $_ and [0] expected? That's what surprised me. I would
have expected $_[0] to stay together.

Changing from $_ to a defined array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

That is unexpected however.

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

p5pRT · 2018-12-23T05:04:07Z

From @Leont

On Sun, Dec 23, 2018 at 2:29 AM Diab Jerius <djerius@cpan.org> wrote:

Is the split between $_ and [0] expected? That's what surprised me. I would have expected $_[0] to stay together.

Yes, that is what anyone would hope for in this particular case, but
there is a clear reason for this behavior. Take for example this «new
Foo(1)». Clearly that should do «Foo->new(1)», not «Foo(1)->new».

The problem here is that a situation where *three* terms may follow
each other without an operator in between (e.g. «foo bar baz» is
perfectly valid). Because of this the invocant can't be a full
expression (otherwise it would usually consume the argument); it must
either be a (subset of) term or a block. $_ is a term so that gets to
be the invocant of the method call, and [0] gets to be the argument
even if together they'd make a fine expression.

Even if this could be fixed (I suspect it can't; but don't know the
lexer well), that would likely only introduce more similar edge-cases.

p5pRT · 2018-12-23T13:02:04Z

From gm@qwurx.de

From the keyboard of Leon Timmermans [23.12.18,06:03]:

On Sun, Dec 23, 2018 at 2:29 AM Diab Jerius <djerius@cpan.org> wrote:

Is the split between $_ and [0] expected? That's what surprised me. I would have expected $_[0] to stay together.

Yes, that is what anyone would hope for in this particular case, but
there is a clear reason for this behavior. Take for example this «new
Foo(1)». Clearly that should do «Foo->new(1)», not «Foo(1)->new».

The problem here is that a situation where *three* terms may follow
each other without an operator in between (e.g. «foo bar baz» is
perfectly valid). Because of this the invocant can't be a full
expression (otherwise it would usually consume the argument); it must
either be a (subset of) term or a block. $_ is a term so that gets to
be the invocant of the method call, and [0] gets to be the argument
even if together they'd make a fine expression.

Even if this could be fixed (I suspect it can't; but don't know the
lexer well), that would likely only introduce more similar edge-cases.

First case nicely explained, but that doesn't explain the - yes, bizarre
- second case:

perl -MO=Deparse -e 'my @X=(1);pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

where the $X is made into an array. It looks like the lexer, looking at
$X[0], decides first this, and in a subsequent rule, that, despite the
fact that the invocant cannot be an array syntactically in indirect
object notation

perl -MO=Deparse -e 'my @X=(1);pp @X[0]'
Array found where operator expected at -e line 1, at end of line
(Do you need to predeclare pp?)
syntax error at -e line 1, near "pp @X"
-e had compilation errors.
my(@X) = 1;

whereas an array in direct object notation resolves to its scalar value
as invocant:

perl -e 'my @X=("foo","bar");@X->pp([0])'
Can't locate object method "pp" via package "2" (perhaps you forgot to
load "2"?) at -e line 1.

That the '_' identifier is treated specially comes at no surprise, but
the whole thing is fishy.

0--gg-

--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

p5pRT · 2018-12-23T15:01:39Z

From Eirik-Berg.Hanssen@allverden.no

On Sun, Dec 23, 2018 at 2:03 PM shmem <gm@qwurx.de> wrote:

From the keyboard of Leon Timmermans [23.12.18,06:03]:

On Sun, Dec 23, 2018 at 2:29 AM Diab Jerius <djerius@cpan.org> wrote:

Is the split between $_ and [0] expected? That's what surprised me. I
would have expected $_[0] to stay together.

Yes, that is what anyone would hope for in this particular case, but
there is a clear reason for this behavior. Take for example this «new
Foo(1)». Clearly that should do «Foo->new(1)», not «Foo(1)->new».

The problem here is that a situation where *three* terms may follow
each other without an operator in between (e.g. «foo bar baz» is
perfectly valid). Because of this the invocant can't be a full
expression (otherwise it would usually consume the argument); it must
either be a (subset of) term or a block. $_ is a term so that gets to
be the invocant of the method call, and [0] gets to be the argument
even if together they'd make a fine expression.

Even if this could be fixed (I suspect it can't; but don't know the
lexer well), that would likely only introduce more similar edge-cases.

First case nicely explained, but that doesn't explain the - yes, bizarre
- second case:

perl -MO=Deparse -e 'my @X=(1);pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

where the $X is made into an array. It looks like the lexer, looking at
$X[0], decides first this

It may look like that, but are you sure it's not just a bug in the
deparse?

Compare:

perl -MO=Deparse -e "our @X=(1); pp $X[0];
our(@X) = 1;
$X->pp([0]);
-e syntax OK

Clearly the presence of the lexical @X changes something ... but does it
change the parse or the deparse?

Either way, the deparse can't be right:

perl -e "$X=foo; sub foo::pp { print qq(call on foo::pp\n) }
$sym=qq(1::pp); *$sym = sub { print qq(call on $sym\n) }; my @X=("baz"); pp
$X[0];"
Can't call method "pp" on an undefined value at -e line 1.

perl -MO=Deparse -e "$X=foo; sub foo::pp { print qq(call on foo::pp\n) }
$sym=qq(1::pp); *$sym = sub { print qq(call on $sym\n) }; my @X=("baz"); pp
$X[0];" | perl
-e syntax OK
call on 1::pp

Eirik

p5pRT · 2018-12-23T18:41:59Z

From @djerius

On Sun, Dec 23, 2018 at 12:04 AM Leon Timmermans <fawaka@gmail.com> wrote:

On Sun, Dec 23, 2018 at 2:29 AM Diab Jerius <djerius@cpan.org> wrote:

Is the split between $_ and [0] expected? That's what surprised me. I
would have expected $_[0] to stay together.

Yes, that is what anyone would hope for in this particular case, but
there is a clear reason for this behavior. Take for example this «new
Foo(1)». Clearly that should do «Foo->new(1)», not «Foo(1)->new».

The problem here is that a situation where *three* terms may follow
each other without an operator in between (e.g. «foo bar baz» is
perfectly valid). Because of this the invocant can't be a full
expression (otherwise it would usually consume the argument); it must
either be a (subset of) term or a block. $_ is a term so that gets to
be the invocant of the method call, and [0] gets to be the argument
even if together they'd make a fine expression.

Even if this could be fixed (I suspect it can't; but don't know the
lexer well), that would likely only introduce more similar edge-cases.

Thanks for that very useful explanation. I didn't realize how tricky this
bit was.

p5pRT · 2018-12-23T18:44:35Z

From @djerius

On Sat, Dec 22, 2018 at 4:37 PM Tomasz Konojacki via RT <
perlbug-followup@perl.org> wrote:

On Sat, 22 Dec 2018 13:24:18 -0800
"Diab Jerius $via RT$" <perlbug-followup@perl.org> wrote:

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

This is a bug report for perl from djerius@cpan.org,
generated with the help of perlbug 1.41 running under perl 5.28.1.

-----------------------------------------------------------------
[Please describe your issue here]

Howdy!

The following behavior may simply be a byproduct of precedence rules,
but it caught me by surprise and made debugging just a bit harder.
Here's the code and runtime error:

% perl -e 'pp $_[0]'
Can't call method "pp" on an undefined value at -e line 1.

and here's the deparse:
% perl -MO=Deparse -e 'pp $_[0]'
$_->pp([0]);
-e syntax OK

which is not at all what I expected. Changing from $_ to a defined array

$ perl -e 'my @X = ( 1 ); pp $X[0]'
Can't call method "pp" on an undefined value at -e line 1.

gives this bizarre deparse:

$ perl -MO=Deparse -e 'my @X = ( 1 ); pp $X[0]'
my(@X) = 1;
@X->pp([0]);
-e syntax OK

The backdrop of this is that I did equivalent to this:

sub foo {
require 'T1';
$_ = 'no';
T1::func $_[0];
}

Note the forgotten parenthises around the argument to T1::func.

This resulted in a call of

T1::func( $_, [0] );

or

T1::func( 'no', [0] );

with no errors except garbage return from T1::func. Figuring out
why was somewhat of a trip down the rabbit hole.

It's called "indirect object syntax" and it's one of the worst perl
misfeatures: https://perldoc.pl/perlobj#Indirect-Object-Syntax

It's possible to disable it using indirect.pm pragma from CPAN:
https://metacpan.org/pod/indirect

Thanks. I haven't used that syntax in so long I didn't recognize it. I'm
considering adding

no indirect 'global';

To sitecustomize.pl just to see how much chatter that generates.

p5pRT added Severity Low type-core labels Oct 19, 2019

xenu removed the affects-5.28 label Nov 19, 2021

xenu removed the Severity Low label Dec 29, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unexpected parsing of "pp $_[0]" into "$_->pp([0])" #16793

unexpected parsing of "pp $_[0]" into "$_->pp([0])" #16793

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

p5pRT commented Dec 23, 2018

p5pRT commented Dec 23, 2018

p5pRT commented Dec 23, 2018

p5pRT commented Dec 23, 2018

p5pRT commented Dec 23, 2018

p5pRT commented Dec 23, 2018

unexpected parsing of "pp $_[0]" into "$_->pp([0])" #16793

unexpected parsing of "pp $_[0]" into "$_->pp([0])" #16793

Comments

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

From @djerius

Created by @djerius

p5pRT commented Dec 22, 2018

From @xenu

p5pRT commented Dec 22, 2018

p5pRT commented Dec 22, 2018

From @demerphq

p5pRT commented Dec 22, 2018

From @djerius

p5pRT commented Dec 22, 2018

From @Leont

p5pRT commented Dec 23, 2018

From @djerius

p5pRT commented Dec 23, 2018

From @Leont

p5pRT commented Dec 23, 2018

From gm@qwurx.de

p5pRT commented Dec 23, 2018

From Eirik-Berg.Hanssen@allverden.no

p5pRT commented Dec 23, 2018

From @djerius

p5pRT commented Dec 23, 2018

From @djerius