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

in reply to Re: lexicals are all the same scalar and never go out of scope?
in thread lexicals are all the same scalar and never go out of scope?

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?

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]

In Section Seekers of Perl Wisdom