local $#array isn't.

[p5pRT]

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

Searchable as RT10041$

[p5pRT]

From @abigail

Created by @abigail

  @​array = (1 .. 3);   {   local $#array = 6;   print $#array\, "\n";   }   print $#array\, "\n";

  __END__   6   6

I would have expected that either the second print would have printed 3\, or that the local would have caused an error.

Abigail

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.8.0: Configured by abigail at Fri Jun 21 18:20:52 CEST 2002. Summary of my perl5 (revision 5.0 version 8 subversion 0 patch 17339) configurat ion: Platform: osname=linux, osvers=2.4.5, archname=i686-linux-64int-ld uname='linux hermione 2.4.5 #6 fri jun 22 01:38:20 pdt 2001 i686 unknown ' config_args='-des -Uversiononly -Dmydomain=.foad.org -Dcf_email=abigail@foad ..org -Dperladmin=abigail@foad.org -Doptimize=-g -Dusemorebits -Dusedevel -Dusenm =false -Darchlib=/opt/perl/5.8.0-RC2/lib/5.8.0-RC2/i686-linux -Dprivlib=/opt/per l/5.8.0-RC2/lib/5.8.0-RC2 -Dman1dir=/opt/perl/5.8.0-RC2/man/man1 -Dman3dir=/opt/ perl/5.8.0-RC2/man/man3 -Dprefix=/opt/perl/5.8.0-RC2' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=unde f useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/ opt/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/opt/local /include' ccversion='', gccversion='2.95.3 20010315 (release)', 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='long double', nvsize=12, Off_t='off_t' , lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib -L/opt/local/lib' libpth=/usr/local/lib /opt/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib -L/opt/local/lib' Locally applied patches: DEVEL17339 @INC for perl v5.8.0: /home/abigail/Perl /home/abigail/Sybase /opt/perl/5.8.0-RC2/lib/5.8.0-RC2/i686-linux /opt/perl/5.8.0-RC2/lib/5.8.0-RC2 /opt/perl/5.8.0-RC2/lib/site_perl/5.8.0/i686-linux-64int-ld /opt/perl/5.8.0-RC2/lib/site_perl/5.8.0 /opt/perl/5.8.0-RC2/lib/site_perl . Environment for perl v5.8.0: HOME=/home/abigail LANG (unset) LANGUAGE (unset) LC_ALL=POSIX LD_LIBRARY_PATH=/home/abigail/Lib:/usr/local/lib:/usr/lib:/lib:/usr/X11R6/li b:/opt/gnome/lib LOGDIR (unset) PATH=/home/abigail/Bin:/opt/perl/bin:/usr/local/bin:/usr/local/X11/bin:/usr/ bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/games:/opt/povray/b in:/opt/gnome/bin:/opt/opera/bin:/usr/share/texmf/bin:/opt/Acrobat4/bin:/opt/jav a/blackdown/j2sdk1.3.1/bin:/usr/local/games/bin:/opt/gnuplot/bin:/opt/mysql/bin PERL5LIB=/home/abigail/Perl:/home/abigail/Sybase PERLDIR=/opt/perl PERL_BADLANG (unset) SHELL=/usr/bin/bash ```

[p5pRT]

From @JohnPeacock

Abigail wrote​:

[Please enter your report here]

@​array = \(1 \.\. 3\);
\{
    local $\#array = 6;
    print $\#array\, "\\n";
\}
print $\#array\, "\\n";

\_\_END\_\_
6
6

I would have expected that either the second print would have printed 3\, or that the local would have caused an error.

@​array = (1 .. 3); print $#array\, "\n"; {   local @​array;   $#array = 6;   print $#array\, "\n"; } print $#array\, "\n";

__END__ 2 6 2

Under no circumstances should anything print 3 here. ;~)

It appears that the assignment (which autovivifies the array size) predates the localization; is that a bug? Should local bind more tightly than anything else?

John

-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5747

[p5pRT]

From @jhi

It appears that the assignment (which autovivifies the array size) predates the localization; is that a bug? Should local bind more tightly than anything else?

This looks like Yet Another People Want A Full Rollback System Which local() Ain't. (The recent local vs tie discussion is another example.)

In other words​: people localize X where X has side effects in addition to just the value\, and they expect all the side effects of X to become magically undone at the scope exit. (Or\, presumedly\, at a new local() in the same scope.) Unless there is a full transactional thing going on underneath\, ain't gonna happen.

-- $jhi++; # http​://www.iki.fi/jhi/   # There is this special biologist word we use for 'stable'.   # It is 'dead'. -- Jack Cohen

[p5pRT]

From @ysth

In article \20020711203125\.S1007@​alpha\.hut\.fi\, Jarkko Hietaniemi \jhi@​iki\.fi wrote​:

It appears that the assignment (which autovivifies the array size) predates the localization; is that a bug? Should local bind more tightly than anything else?

This looks like Yet Another People Want A Full Rollback System Which local() Ain't. (The recent local vs tie discussion is another example.)

In other words​: people localize X where X has side effects in addition to just the value\, and they expect all the side effects of X to become magically undone at the scope exit. (Or\, presumedly\, at a new local() in the same scope.) Unless there is a full transactional thing going on underneath\, ain't gonna happen.

I don't think Abigail expected anything unreasonable; either "local $#..." should work (for some value of work) or give an syntax error (the way "local *FOO{BAR}" does\, for instance).

[p5pRT]

From @JohnPeacock

Yitzchak Scott-Thoennes wrote​:

I don't think Abigail expected anything unreasonable; either "local $#..." should work (for some value of work) or give an syntax error (the way "local *FOO{BAR}" does\, for instance).

I don't think it would be unreasonable for the parser to treat this

  local $#array = 6;

as if it were

  local @​array; $#array = 6;

but it just doesn't right now. Patches welcome (after 5.8.0 is released of course;~)...

John

[p5pRT]

From [Unknown Contact. See original ticket]

John Peacock wrote​:

Yitzchak Scott-Thoennes wrote​:

I don't think Abigail expected anything unreasonable; either "local $#..." should work (for some value of work) or give an syntax error (the way "local *FOO{BAR}" does\, for instance).

I don't think it would be unreasonable for the parser to treat this

    local $\#array = 6;

as if it were

    local @​array; $\#array = 6;

ITYM\, it should be treated as if it were​:   local @​array = @​array; $#array = 6;

Perlsonally\, though\, I'd prefer it be as if it were treated as​:   my $old = $#array;   LAST { $#array = $old };   $#array = 6;

But with the old value stored on the stack\, rather than in a variable.

but it just doesn't right now. Patches welcome (after 5.8.0 is released of course;~)...

John

-- tr/`4/ /d\, print "@​{[map --$| ? ucfirst lc : lc\, split]}\,\n" for pack 'u'\, pack 'H*'\, 'ab5cf4021bafd28972030972b00a218eb9720000';

[p5pRT]

From @ysth

In article \3D310162\.81F40F10@​earthlink\.net\, Benjamin Goldberg \goldbb2@​earthlink\.net wrote​:

John Peacock wrote​:

Yitzchak Scott-Thoennes wrote​:

I don't think Abigail expected anything unreasonable; either "local $#..." should work (for some value of work) or give an syntax error (the way "local *FOO{BAR}" does\, for instance).

local(keys %x) is a better example since that is an lvalue and *FOO{BAR} isn't (but ought to be!).

I don't think it would be unreasonable for the parser to treat this

    local $\#array = 6;

as if it were

    local @​array; $\#array = 6;

ITYM\, it should be treated as if it were​: local @​array = @​array; $#array = 6;

Since you can explicitly do either of those\, I don't see the point. I'd rather see a syntax error.

Perlsonally\, though\, I'd prefer it be as if it were treated as​: my $old = $#array; LAST { $#array = $old }; $#array = 6;

But with the old value stored on the stack\, rather than in a variable.

That's more what I'd expect it to do. But it doesn't seem worthwhile to make it work since\, if I recall correctly\, $# will go away for Perl6.

[p5pRT]

From @rgarcia

Yitzchak Scott-Thoennes wrote​:

ITYM\, it should be treated as if it were​: local @​array = @​array; $#array = 6;

Since you can explicitly do either of those\, I don't see the point. I'd rather see a syntax error.

Uh\, but there should be more than one way to do it.

Perlsonally\, though\, I'd prefer it be as if it were treated as​: my $old = $#array; LAST { $#array = $old }; $#array = 6;

But with the old value stored on the stack\, rather than in a variable.

That's more what I'd expect it to do. But it doesn't seem worthwhile to make it work since\, if I recall correctly\, $# will go away for Perl6.

But not the ability to get the length of an array as a lvalue :

temp @​foo.length;

[p5pRT]

From [Unknown Contact. See original ticket]

Is there a good mailing list for PERL programming questions? I could not seem to find one...

Any suggestions?

Chip Cuntz Worldcom v622.1305/719.535.1305

[p5pRT]

From @IlyaM

On Mon\, 15 Jul 2002 16​:47​:04 -0600\, Chip Cuntz \chipperc\.cuntz@​wcom\.com said​:

CC> Is there a good mailing list for PERL programming questions? I could not CC> seem to find one...

It is not maillist but try http​://www.perlmonks.org/.

-- Ilya Martynov (http​://martynov.org/)

[p5pRT]

@abigail - Status changed from 'open' to 'resolved'