Re: lexicals are all the same scalar and never go out of scope?

Try this:

use Devel::Peek;
...
sub save {
    Dump $_[0];
    push(@savearr, \$_[0]);
    readonly_on(${$savearr[-1]});
    Dump ${$savearr[-1]};
}
...

__END__
SV = PV(0x75cbc8) at 0x88d238            #
  REFCNT = 1
  FLAGS = (PADTMP,POK,pPOK)
  PV = 0x77e340 "begin 0 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75cc68) at 0x75ef48
  REFCNT = 1
  FLAGS = (POK,READONLY,pPOK)
  PV = 0x77e940 "begin 0 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75cbc8) at 0x88d238            #
  REFCNT = 1
  FLAGS = (PADTMP,POK,pPOK)
  PV = 0x77e340 "begin 1 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75cce8) at 0x7836b8
  REFCNT = 1
  FLAGS = (POK,READONLY,pPOK)
  PV = 0x78cc60 "begin 1 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75cbc8) at 0x88d238            #
  REFCNT = 1
  FLAGS = (PADTMP,POK,pPOK)
  PV = 0x77e340 "begin 2 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75ccf8) at 0x783700
  REFCNT = 1
  FLAGS = (POK,READONLY,pPOK)
  PV = 0x87bb70 "begin 2 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75cbc8) at 0x88d238            #
  REFCNT = 1
  FLAGS = (PADTMP,POK,pPOK)
  PV = 0x77e340 "begin 3 end"\0
  CUR = 11
  LEN = 16
SV = PV(0x75cd08) at 0x783748
  REFCNT = 1
  FLAGS = (POK,READONLY,pPOK)
  PV = 0x87bcd0 "begin 3 end"\0
  CUR = 11
  LEN = 16
$VAR1 = [
          \'begin 0 end',
          \'begin 1 end',
          \'begin 2 end',
          \'begin 3 end'
        ];
[download]

Note that the marked instances are in fact the same scalar. A new one isn't created before pushing it onto the array.

Comment on Re: lexicals are all the same scalar and never go out of scope? Download Code

Replies are listed 'Best First'.
Re^2: lexicals are all the same scalar and never go out of scope? by ikegami (Patriarch) on Dec 06, 2011 at 09:55 UTC
By your logic, the following never deallocates the referenced array: `use Devel::Peek; $x = []; Dump($x, 1); $x = undef; $x = []; Dump($x, 1);` [download] `SV = IV(0x51a420) at 0x51a424 REFCNT = 1 FLAGS = (ROK) RV = 0x61b29c SV = PVAV(0x61c248) at 0x61b29c REFCNT = 1 FLAGS = () ARRAY = 0x0 FILL = -1 MAX = -1 ARYLEN = 0x0 FLAGS = (REAL) SV = IV(0x51a420) at 0x51a424 REFCNT = 1 FLAGS = (ROK) RV = 0x61b29c SV = PVAV(0x61c248) at 0x61b29c REFCNT = 1 FLAGS = () ARRAY = 0x0 FILL = -1 MAX = -1 ARYLEN = 0x0 FLAGS = (REAL)` [download] But that's just not true. It just got reallocated at the same address. Looking at the address is not meaningful. (I'm not saying that it isn't the same scalar. I'm saying you haven't shown that it is the same scalar.)	[reply] [d/l] [select]
Re^3: lexicals are all the same scalar and never go out of scope? by Eliya (Vicar) on Dec 06, 2011 at 10:32 UTC
By your logic, the following never deallocates the referenced array: ... This isn't even remotely what I said. I said the scalar (i.e. the SV, what you call TARG) is the same, and a copy of it is created when a reference to it is pushed onto the array — nothing more. That's in essence the same you pointed out in your reply.	[reply]
Re^4: lexicals are all the same scalar and never go out of scope? by ikegami (Patriarch) on Dec 06, 2011 at 10:44 UTC
I said the scalar (i.e. the SV, what you call TARG) is the same, You also posted a code snippet and its output. With no explanation, the implication is that it supports the accompanying claim. And it does no such thing. That's in essence the same you pointed out in your reply. Reaching the correct conclusion doesn't make how you reached it correct.	[reply]
Re^2: lexicals are all the same scalar and never go out of scope? by patcat88 (Deacon) on Dec 06, 2011 at 10:02 UTC
But if it is infact 1 scalar, why did the reference become a reference to a copy? Thats not what references do. I'll save everyone the drama and point to the culprit pp.c#l522 in perl.git So why does perl make copies instead of real references when you think your making a reference? I dont see this in perldoc anywhere. How do I fix this problem when I need to readonly on and save a reference to the SV in XS? Copy what srefgen does by checking PADTMP? Why doesn't newRV sv.c#l8654 in perl.git do the copy for me just like srefgen does? Shouldn't making a ref in XS be identical to making a ref in Perl? Why doesn't entersub clone PADTMPs into unique mortal SVs if PADTMPs are found on the stack automatically so subs (Perl and XS) don't encounter these "supposed to be scoped but are global scalars"? Or get rid of the copying in srefgen and if you run into read only modification fatal error updating a stack scalar in a sub, thats your fault for not eval probing it or checking its readonly flag using Internals:: and the callers fault (assuming its documented all lexicals are private sub level statics/closures and not autos) for passing a lexical instead of something store permanently in an array/hash? Should I be bringing this up on P5P instead?	[reply]
Re^3: lexicals are all the same scalar and never go out of scope? by ikegami (Patriarch) on Dec 06, 2011 at 10:43 UTC
So why does perl make copies instead of real references when you think your making a reference? `$s = $x . $y;` [download] Wouldn't it be nice if concat didn't have to allocate a scalar that will just end up being copied into $s and deallocated? Well guess what, it doesn't. That instance of the concat operator will always return the same scalar. This saves allocating a scalar and deallocating a scalar. But of course, doing that alone would break weird code like following: `my @b = map { \($prefix.$_) } @a;` [download] So the deref operator must be complicit and make a copy of the scalar if it comes from concat. Why doesn't entersub clone PADTMPs into unique mortal SVs if PADTMPs are found on the stack automatically Cause that defies the whole point of avoiding the creation of those scalars. Shouldn't making a ref in XS be identical to making a ref in Perl? Sure, but it's not Perl's fault your XS code isn't identical to its code. Should there be a function for creating references that checks PADTMP? Maybe. Yes, p5p would be appropriate for this.	[reply] [d/l] [select]