Re: Scope of variables in a function
Well, you shouldn't have to make that case.
Since no one else is speaking up for it, I will.
The current behaviour makes sense. The only way this could cause you a
problem is if you were already doing a number of other things wrong.
The current behaviour is exactly as I would expect reading the code.
1. Probably helps to understand the way scope works in the language you're
using
2. Write what you mean (fair enough, *maybe perlcritic could say something*?
or warnings.pm?)
3. People confuse themselves with shorthand conditional statements?
4. Be more explicit (set things to 0 or undef if they need to be empty or
untrue, so I don't have to go searching your code to figure out what's left
in your variable)
So far all I've heard is "artefact", which is all too often banded around
as an argument itself lately.
What's actually wrong with the current behaviour, assuming you've read the
manual for what you're trying to use (i.e. my)?
What people seem to be asking for is exactly the same as Dave described,
which would be bad, as he also described.
On 2 June 2013 22:43, Gordon Banner wrote:
> Also that would break
>
> my $var = "outer";
> {
> my $stashed_value = $var;
> my $var = "inner";
> ...
> }
>
> I don't have an instant example of why doing that would be a good thing,
> but it's quite clearly supported at present.
> Gordon
>
>
> On 02/06/2013 12:49, Dave Mitchell wrote:
>
>> The original patch was a proof-of-concept that hoisted the run-time
>> effects of my to the start of the containing scope. So that from a
>> run-time point of view,
>>
>> {
>> AAA;
>> my $x = ...;
>> BBB;
>> my $y = ...;
>> CCC;
>> my $z = ...;
>> DDD;
>>
>> }
>>
>> is executed like
>>
>> {
>> my ($x,$y,$y);
>> AAA;
>> $x = ...;
>> BBB;
>> $y = ...;
>> CCC;
>> $z = ...;
>> DDD;
>> }
>>
>> The main problem with it was that in something like the following:
>>
>> while (<>) {
>> next unless /rare condition/;
>> my ($lots, $of, $lexicals) = split;
>> ...
>> }
>>
>> all those lexicals would be initialised and cleared every time round the
>> loop, rather than just on rare occasions: which could be quite a
>> performance hit.
>>
>>
>>
>
Re: Scope of variables in a function
On Sun, Jun 02, 2013 at 10:43:02PM +0100, Gordon Banner wrote:
> Also that would break
>
> my $var = "outer";
> {
> my $stashed_value = $var;
> my $var = "inner";
> ...
> }
>
(except that it wouldn't). My example wasn't meant to be literal: it was
just a hand-wavy explanation of moving the *runtime* effects of my to the
start of the block. The compile-time effect (i.e. scope) was unaffected.
Sorry if this wasn't; clear.
NB: the run-time effect of 'my' is to push a note onto the save stack
saying "at scope exit, please decrement the reference count of this
lexical var, and do other misc bits of housekeeping"). This is why with
my $x if 0;
and
goto foo;
my $x;
foo:
the lexical doesn't get cleared at the end of scope, meaning its old value
is sill there on next entry to the block.
--
I've often wanted to drown my troubles, but I can't get my wife to go
swimming.
Re: Scope of variables in a function
Also that would break
my $var = "outer";
{
my $stashed_value = $var;
my $var = "inner";
...
}
I don't have an instant example of why doing that would be a good thing,
but it's quite clearly supported at present.
Gordon
On 02/06/2013 12:49, Dave Mitchell wrote:
The original patch was a proof-of-concept that hoisted the run-time
effects of my to the start of the containing scope. So that from a
run-time point of view,
{
AAA;
my $x = ...;
BBB;
my $y = ...;
CCC;
my $z = ...;
DDD;
}
is executed like
{
my ($x,$y,$y);
AAA;
$x = ...;
BBB;
$y = ...;
CCC;
$z = ...;
DDD;
}
The main problem with it was that in something like the following:
while (<>) {
next unless /rare condition/;
my ($lots, $of, $lexicals) = split;
...
}
all those lexicals would be initialised and cleared every time round the
loop, rather than just on rare occasions: which could be quite a
performance hit.
Re: Scope of variables in a function
On 2 Jun 2013, at 12:42, Dave Mitchell wrote:
> I'm not aware of any particular performance penalty:
>
>$ time perl5180o -E'for (1..100_000_000) { my $x = 1 }'
>
>real 0m5.638s
>
>$ time perl5180o -E'for (1..100_000_000) { my $x }'
>
>real 0m4.012s
>
>$ time perl5180o -E'for (1..100_000_000) { state $x = 1 }'
>
>real 0m3.060s
>
>$ time perl5180o -E'my $x; for (1..100_000_000) { $x }'
>
>real 0m2.787s
>
> Yes technically its slightly slower than a bare '$x', but it's a lot
> faster than a bare 'my $x';
I stand corrected. I thought I'd seen a warning in the docs at some point but
evidently I'm making it up.
/j
Re: Scope of variables in a function
On Sat, Jun 01, 2013 at 10:19:11PM -0700, Yitzchak Scott-Thoennes wrote:
> On Sat, Jun 1, 2013 at 10:23 AM, Dirk Koopman wrote:
> > Quite a lot of other perl artefacts have been deprecated and then removed.
> > Why does this one persist? In what way is it useful or intuitive?
>
> Because it is the result of an optimization - lexicals are reset upon leaving
> scope, not entering it, and only if the my() was reached during execution.
>
> Nevertheless, I believe Dave Mitchell had a patch to fix it that never
> quite made it in.
The original patch was a proof-of-concept that hoisted the run-time
effects of my to the start of the containing scope. So that from a
run-time point of view,
{
AAA;
my $x = ...;
BBB;
my $y = ...;
CCC;
my $z = ...;
DDD;
}
is executed like
{
my ($x,$y,$y);
AAA;
$x = ...;
BBB;
$y = ...;
CCC;
$z = ...;
DDD;
}
The main problem with it was that in something like the following:
while (<>) {
next unless /rare condition/;
my ($lots, $of, $lexicals) = split;
...
}
all those lexicals would be initialised and cleared every time round the
loop, rather than just on rare occasions: which could be quite a
performance hit.
--
Modern art:
"That's easy, I could have done that!"
"Ah, but you didn't!"
Perl School: Database Programming with Perl and DBIx::Class
Hi, I'm running my Perl School class on DBIC again this coming Saturday (June 8th). It's at Google Campus in London. It's a full-day course and tickets cost £30. Full details at http://prls.ch/dbic2lpm Do you know anyone who could benefit from a one-day introduction to DBIC? Please feel free to pass on this email to them. Cheers, Dave... -- Dave Cross :: d...@dave.org.uk http://dave.org.uk/ @davorg
Re: Scope of variables in a function
On Sat, Jun 01, 2013 at 07:03:18PM +0100, James Laver wrote:
> We did formalise an alternative, in the form of :state, but I don't know
> about how well it's used. It also incurs a performance penalty that
> people are presumably unhappy about (but then one assumes it's also
> incurred by the informal version too…)
I'm not aware of any particular performance penalty:
$ time perl5180o -E'for (1..100_000_000) { my $x = 1 }'
real0m5.638s
$ time perl5180o -E'for (1..100_000_000) { my $x }'
real0m4.012s
$ time perl5180o -E'for (1..100_000_000) { state $x = 1 }'
real0m3.060s
$ time perl5180o -E'my $x; for (1..100_000_000) { $x }'
real0m2.787s
Yes technically its slightly slower than a bare '$x', but it's a lot
faster than a bare 'my $x';
--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
-- Bill Royston
