Path: utzoo!utgpu!watserv1!watmath!att!att!emory!wuarchive!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: bug, feature, or what ??
Message-ID: <10160@jpl-devvax.JPL.NASA.GOV>
Date: 29 Oct 90 23:24:31 GMT
References: <4138@ruuinf.cs.ruu.nl>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 70

In article <4138@ruuinf.cs.ruu.nl> henkp@ruuinf.cs.ruu.nl (Henk P. Penning) writes:
: # Why is it that:
: 
: @row = 1..8 ;      print join(',',@row), ".\n" ;
: $#row = 3 ;        print join(',',@row), ".\n" ;
: splice(@row,0,4) ; print join(',',@row), ".\n" ;
: $#row += 4 ;       print join(',',@row), ".\n" ;
: 
: # prints out:
: # 1,2,3,4,5,6,7,8.
: # 1,2,3,4.
: # .
: # ,,,.
: 
: # instead of:
: # 1,2,3,4,5,6,7,8.
: # 1,2,3,4.
: # .
: # 5,6,7,8.

Because splice decided to shorten the array from the top end, where
top end is defined by $#row, not by how much is actually allocated.
(In other words, splice is also allowed to play with the value of $#row.)
Had splice decided to shorten the array from the front, you would have
got the "undead" elements back.  Note that if you only splice two elements
from the front instead of four, you'll get

1,2,3,4,5,6,7,8.
1,2,3,4.
3,4.
3,4,5,6,7,8.

: # Empty arrays can sometimes be (re-)extended, see fi:
: 
: @row = 1..8 ;      print join(',',@row), ".\n" ;
: $#row = -1 ;       print join(',',@row), ".\n" ;
: $#row = 7 ;        print join(',',@row), ".\n" ;
: 
: # prints out:
: # 1,2,3,4,5,6,7,8.
: # .
: # 1,2,3,4,5,6,7,8.

The resurrection of "undead" strings is a quasi-feature that depends on the
laziness of perl in not deallocating the strings when you decrease $#foo.
I have yet to see a use for it, and am somewhat sorry I documented it.

With that in mind, I don't see any point in making it copy down undead
strings on the speculation that someone might increase $#foo again.
At least with the current setup, it makes an interesting detector of which
way splice decided to work.

: Can I see through this mistery with the knowledge of 'The Book' ?

It won't be covered in the book.  The source code has to be useful for
something, after all...  :-)

: I couldn't find it in the One True Man Page.

It's vaguely derivable from the documentation about splice growing
or shrinking the array, if you assume that the array that's growing or
shrinking consists only of the elements from $[ .. $#foo.  (The fact
that splice is capable of shrinking arrays by upping the front pointer
as well as decreasing the length is not specifically mentioned anywhere
in the manual page, that I can recollect.  Note that s/// does the same
tricks with strings when it decides it can modify a string in place.  This
is part of the reason tokeners in 3.0 ran faster--the s/^keyword// construct
was no longer copying the line back and forth.)

Larry