stacked declarators (my/our/state) shouldn't be legal

[p5pRT]

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

Searchable as RT125587$

[p5pRT]

From @nwc10

Created by @nwc10

$ perl -wle 'my (my $a) = 3; print $a'
3

The optree deparses as if there is only one my​:

$ perl -MO=Deparse -e 'my (my $a) = 3;'
my($a) = 3;
-e syntax OK

Shouldn't chained my be a syntax error?
(and yes, you can do silly things in 5.10nearly with state and my)

Nicholas Clark

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.8:

Configured by mstevens at Wed Jul 11 21:30:26 BST 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=freebsd, osvers=6.2-release-p4, archname=i386-freebsd-64int
    uname='freebsd saigo.etla.org 6.2-release-p4 freebsd 6.2-release-p4 #2: sun apr 29 08:28:44 bst 2007 root@saigo.etla.org:usrobjusrsrcsyssaigo2 i386 '
    config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.8/mach -Dprivlib=/usr/local/lib/perl5/5.8.8 -Dman3dir=/usr/local/lib/perl5/5.8.8/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.8/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.8 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.8/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -Doptimize=-O2 -fno-strict-aliasing -pipe -march=pentium4 -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=undef
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include',
    optimize='-O2 -fno-strict-aliasing -pipe -march=pentium4',
    cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include'
    ccversion='', gccversion='3.4.6 [FreeBSD] 20060305', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -Wl,-E -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lm -lcrypt -lutil
    perllibs=-lm -lcrypt -lutil
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -Wl,-R/usr/local/lib/perl5/5.8.8/mach/CORE'
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib'

Locally applied patches:
    defined-or


@INC for perl v5.8.8:
    /usr/local/lib/perl5/5.8.8/BSDPAN
    /usr/local/lib/perl5/site_perl/5.8.8/mach
    /usr/local/lib/perl5/site_perl/5.8.8
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.8.8/mach
    /usr/local/lib/perl5/5.8.8
    .


Environment for perl v5.8.8:
    HOME=/home/nick
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/nick/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/nick/bin:/usr/local/sbin:/sbin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

[p5pRT]

From @cpansprout

On Sat Sep 08 05​:33​:17 2007, nicholas wrote​:

$ perl -wle 'my (my $a) = 3; print $a'
3

The optree deparses as if there is only one my​:

$ perl -MO=Deparse -e 'my (my $a) = 3;'
my($a) = 3;
-e syntax OK

Shouldn't chained my be a syntax error?

I’d call that a feature. :-)

Isn’t that what allows my(undef) to work?

[p5pRT]

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

[p5pRT]

From @mauke

Created by @mauke

% perl -wE 'our (my $x)'
% perl -wE 'my (state $x)'
%

I don't think perl should allow this. What does it even mean?

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.22.0:

Configured by mauke at Sat Jul  4 14:56:57 CEST 2015.

Summary of my perl5 (revision 5 version 22 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=4.0.1-1-arch, archname=i686-linux
    uname='linux simplicio 4.0.1-1-arch #1 smp preempt wed apr 29 12:15:20 cest 2015 i686 gnulinux '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='5.1.0', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12, longdblkind=3
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/i686-pc-linux-gnu/5.1.0/include-fixed /usr/lib /lib
    libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.21.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.21'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'



@INC for perl 5.22.0:
    /home/mauke/usr/lib/perl5/site_perl/5.22.0/i686-linux
    /home/mauke/usr/lib/perl5/site_perl/5.22.0
    /home/mauke/usr/lib/perl5/5.22.0/i686-linux
    /home/mauke/usr/lib/perl5/5.22.0
    .


Environment for perl 5.22.0:
    HOME=/home/mauke
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=POSIX
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/mauke/perl5/perlbrew/bin:/home/mauke/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
    PERLBREW_BASHRC_VERSION=0.69
    PERLBREW_HOME=/home/mauke/.perlbrew
    PERLBREW_ROOT=/home/mauke/perl5/perlbrew
    PERL_BADLANG (unset)
    PERL_UNICODE=SAL
    SHELL=/bin/bash

[p5pRT]

From @ap

* l.mai@​web.de <perlbug-followup@​perl.org> [2015-07-09 22​:30]​:

% perl -wE 'our (my $x)'
% perl -wE 'my (state $x)'
%

I don't think perl should allow this.

Why? Did you just write that accidentally and spent 3 days looking for
the problem?

What does it even mean?

It means you can write things like these​:

  my ($foo, undef, $bar) = split ' ';
  ($foo, my $bar, $baz) = get_record_columns();

Because these are legal, your examples happen to also be legal.

Your first example declares a lexical variable and the second a state
variable, in case you are wondering. The rule is that the inner-most
declarator wins. It’s very simple and predictable, and easy to read
correctly.

To still allow examples I gave, but disallow the ones you showed, perl
would have to go out of its way to check for such cases so it can croak.
Do you think this would be effort and code complexity well spent?

[p5pRT]

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

[p5pRT]

From @Abigail

On Sat, Jul 11, 2015 at 02​:41​:30AM +0200, Aristotle Pagaltzis wrote​:

* l.mai@​web.de <perlbug-followup@​perl.org> [2015-07-09 22​:30]​:

% perl -wE 'our (my $x)'
% perl -wE 'my (state $x)'
%

I don't think perl should allow this.

Why? Did you just write that accidentally and spent 3 days looking for
the problem?

What does it even mean?

It means you can write things like these​:

my \($foo\, undef\, $bar\) = split ' ';
\($foo\, my $bar\, $baz\) = get\_record\_columns\(\);

Because these are legal, your examples happen to also be legal.

Neither example is a case of stacked declarations. The fact that the
one implies the other seems like an artifact of the implementation,
not a necessity.

Your first example declares a lexical variable and the second a state
variable, in case you are wondering. The rule is that the inner-most
declarator wins. It’s very simple and predictable, and easy to read
correctly.

To still allow examples I gave, but disallow the ones you showed, perl
would have to go out of its way to check for such cases so it can croak.
Do you think this would be effort and code complexity well spent?

That's a completely different question. I don't think having stacked
declaration causes problems that often -- a check for this belongs,
IMO, in Perl​::Critic.

I do remember having written 'local our $var' (or 'our local $var') in
the past, but I don't recall whether it was really the best option in
that case, or whether it was just a proof of concept.

Abigail

[p5pRT]

From @mauke

On Fri Jul 10 17​:42​:02 2015, aristotle wrote​:

* l.mai@​web.de <perlbug-followup@​perl.org> [2015-07-09 22​:30]​:

% perl -wE 'our (my $x)'
% perl -wE 'my (state $x)'
%

I don't think perl should allow this.

Why?

Because it looks like semantic nonsense to me.

Did you just write that accidentally and spent 3 days looking for the problem?

No, I was actually looking for B​::Deparse bugs, but why does that matter?

What does it even mean?

It means you can write things like these​:

my \($foo\, undef\, $bar\) = split ' ';
\($foo\, my $bar\, $baz\) = get\_record\_columns\(\);

Because these are legal, your examples happen to also be legal.

That doesn't follow. Like, at all.

1) Your example tells me nothing about what "my (our $x)" should do. What are the semantics of declaring a declaration, and why should that be part of the language?

2) 'my ($foo = 42);' could have a sensible interpretation but it's illegal​:
Can't declare scalar assignment in "my" at -e line 1, near ");"

In fact, almost all syntactic constructs are not allowed in a 'my' list and 'undef' is a special case. Why make my/our/state a special case, too?

I don't see how '($foo, my $bar, $baz)' is related; it doesn't use 'my (...)'.

Your first example declares a lexical variable and the second a state
variable, in case you are wondering. The rule is that the inner-most
declarator wins. It’s very simple and predictable, and easy to read
correctly.

You just made that "rule" up. It's certainly not documented anywhere and I doubt it was intended to work this way. Maybe it's a consequence of how the parser happens to set flags but do you want to guarantee to preserve this behavior in future versions?

To still allow examples I gave, but disallow the ones you showed, perl
would have to go out of its way to check for such cases so it can croak.
Do you think this would be effort and code complexity well spent?

Perl already checks for and disallows any expression but undef. This argument sounds too much like "but fixing this bug would be hard" for my liking.

[p5pRT]

From @mauke

On Fri Jul 10 23​:54​:31 2015, abigail@​abigail.be wrote​:

I do remember having written 'local our $var' (or 'our local $var') in
the past, but I don't recall whether it was really the best option in
that case, or whether it was just a proof of concept.

I've written 'local our $var' too, and it makes sense to me because 'local' is not a declarator.

I'm surprised to see that 'our(local $var)' is allowed and does the same thing. It feels analogous to 'our($var = undef)' to me (which is illegal).

[p5pRT]

From @mauke

On Fri Jul 10 17​:42​:02 2015, aristotle wrote​:

To still allow examples I gave, but disallow the ones you showed, perl
would have to go out of its way to check for such cases so it can croak.
Do you think this would be effort and code complexity well spent?

"What, like it's hard?" - Elle Woods

[p5pRT]

From @mauke

0001-PoC-disallow-stacked-declarators-125587.patch

From 4df2dafa76162572f99bf01c7222ea9601025375 Mon Sep 17 00:00:00 2001
From: Lukas Mai <l.mai@web.de>
Date: Sat, 11 Jul 2015 10:38:53 +0200
Subject: [PATCH] PoC: disallow stacked declarators [#125587]

---
 toke.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/toke.c b/toke.c
index 763baa5..560c2fa 100644
--- a/toke.c
+++ b/toke.c
@@ -7543,6 +7543,15 @@ Perl_yylex(pTHX)
 	case KEY_our:
 	case KEY_my:
 	case KEY_state:
+	    if (PL_in_my) {
+	        yyerror(Perl_form(aTHX_
+	                    "Can't redeclare \"%s\" in \"%s\"",
+			       tmp      == KEY_my    ? "my"    :
+			       tmp      == KEY_state ? "state" : "our",
+			       PL_in_my == KEY_my    ? "my"    :
+			       PL_in_my == KEY_state ? "state" : "our"
+	                    ));
+	    }
 	    PL_in_my = (U16)tmp;
 	    s = skipspace(s);
 	    if (isIDFIRST_lazy_if(s,UTF)) {
-- 
2.4.5

[p5pRT]

From zefram@fysh.org

See also [perl #121058].

-zefram

[p5pRT]

From @ap

* Abigail <abigail@​abigail.be> [2015-07-11 08​:55]​:

On Sat, Jul 11, 2015 at 02​:41​:30AM +0200, Aristotle Pagaltzis wrote​:

It means you can write things like these​:

my \($foo\, undef\, $bar\) = split ' ';
\($foo\, my $bar\, $baz\) = get\_record\_columns\(\);

Because these are legal, your examples happen to also be legal.

Neither example is a case of stacked declarations. The fact that the
one implies the other seems like an artifact of the implementation,
not a necessity.

That’s why I said “happens to be”. :-)

I don't think having stacked declaration causes problems that often

The only time I wrote stacked declarators is when I realised they must
be legal and tried it to confirm my hypothesis. Then I wrote a short
funny post on my blog about them and forgot them again. This was not too
long ago, ~20 years into doing Perl and never encountering them in any
code, mine or others’.

It’s possible that it is a good idea to ban them, although it seems
dubious to me based on the evidence so far. Just because a construct is
nonsense doesn’t mean it must be illegal, so long as users never stub
their toes on it. Hence my question about whether Lukas did.

I do remember having written 'local our $var' (or 'our local $var') in
the past, but I don't recall whether it was really the best option in
that case, or whether it was just a proof of concept.

And of course, that one has an obvious and sensical meaning…

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

[p5pRT]

From @ap

* l.mai@​web.de via RT <perlbug-followup@​perl.org> [2015-07-11 10​:35]​:

On Fri Jul 10 17​:42​:02 2015, aristotle wrote​:

Why?

Because it looks like semantic nonsense to me.

But nothing follows from that. Any generic system of rules allows you to
construct consistent but nonsensical expressions. Trying to legislate
that only useful expressions are permitted is a fool’s errand.

No, I was actually looking for B​::Deparse bugs, but why does that
matter?

Because that might be an actual reason to do or not do something.

What does it even mean?

It means you can write things like these​:

my \($foo\, undef\, $bar\) = split ' ';
\($foo\, my $bar\, $baz\) = get\_record\_columns\(\);

Because these are legal, your examples happen to also be legal.

That doesn't follow. Like, at all.

1) Your example tells me nothing about what "my (our $x)" should do.
What are the semantics of declaring a declaration, and why should that
be part of the language?

2) 'my ($foo = 42);' could have a sensible interpretation but it's illegal​:
Can't declare scalar assignment in "my" at -e line 1, near ");"

In fact, almost all syntactic constructs are not allowed in a 'my'
list and 'undef' is a special case. Why make my/our/state a special
case, too?

I don’t believe declarators are special-cased here the way you seem
convinced they are. You cannot write `$foo = 42` anywhere a variable
name is expected, so it’s no stretch that it wouldn’t be allowed inside
a declarator’s variable name list either. You *can* throw declarators
into any expression anywhere a variable is expected, to declare and use
it en passant. It seems to me that this is how stacked declarators
happen to end up legal – i.e. how what you say doesn’t follow, like, at
all, actually does follow.

I don't see how '($foo, my $bar, $baz)' is related; it doesn't use 'my
(...)'.

OK, here you go​:

  ($foo, my ($bar, $baz), $quux) = get_record_columns();

Your first example declares a lexical variable and the second a state
variable, in case you are wondering. The rule is that the inner-most
declarator wins. It’s very simple and predictable, and easy to read
correctly.

You just made that "rule" up.

In my own memory of the incident, I tested a few years ago whether that
is how it works, and I found that it was. Is my recollection faulty?

It's certainly not documented anywhere and I doubt it was intended to
work this way. Maybe it's a consequence of how the parser happens to
set flags but do you want to guarantee to preserve this behavior in
future versions?

I don’t know. Maybe I am mistaken about how obviously it follows from
other rules. It would hardly be the first implementation-defined aspect
of Perl 5 in any case. Is the behaviour that fragile and likely to
break? This says maybe so​:

* Zefram <zefram@​fysh.org> [2015-07-11 13​:30]​:

See also [perl #121058].

If it is really so precarious, it may be worth banning after all. Very
little code would (probably) suffer anyhow.

* l.mai@​web.de via RT <perlbug-followup@​perl.org> [2015-07-11 10​:35]​:

To still allow examples I gave, but disallow the ones you showed,
perl would have to go out of its way to check for such cases so it
can croak. Do you think this would be effort and code complexity
well spent?

Perl already checks for and disallows any expression but undef. This
argument sounds too much like "but fixing this bug would be hard" for
my liking.

I believe you are far overestimating the special-casing for undef here,
as outlined above.

This is not about how hard it would be to fix, it’s about whether it
makes sense to make even a trivial effort to fix it, and then have to
keep that trivial effort working forever after. Just because it looks
stupid that you can do something doesn’t mean it has to be prohibited.

* l.mai@​web.de via RT <perlbug-followup@​perl.org> [2015-07-11 10​:40]​:

I'm surprised to see that 'our(local $var)' is allowed and does the
same thing. It feels analogous to 'our($var = undef)' to me (which is
illegal).

That surprised me too.

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

[p5pRT]

From @cpansprout

On Sat Jul 11 06​:49​:45 2015, aristotle wrote​:

OK, here you go​:

($foo, my ($bar, $baz), $quux) = get_record_columns();

You still don’t have stacked declarators there. I was about to say that I have actually used stacked declarators in my code, but I looked and the code actually has​:

(my $types, local our ($tokens,$prepped,$alt_types)) = _prep_val(@​_);

Though I *think* I may have used stacked declarators somewhere. I don’t think it would be good to remove them, because of the risk of breaking code.

--

Father Chrysostomos