in reply to Re^6: no chunk is too small
in thread Last undefines a for loop's itererator?

It’s not a special case. All iterator constructs alias their iterator variable: foreach, map and grep all do.

while(<>), which is not an iterator construct in the strict sense, is the sole exception, and we already have to tell people to always local $_; before they while(<>). I’d campaign for it to be brought in line, if it were an option at this time.

Do you really want to have to write

@foo = do { local $_; map bar( $_ ), @baz };

[download]

every time you use those constructs, to be safe from accidentally trampling a caller’s $_? I have always considered this piece of magic to DWIM.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^8: no chunk is too small
by BrowserUk (Patriarch) on Nov 14, 2005 at 01:45 UTC

    I would not change any other constructs, nor the way $_ is localised.

    I would prefer it if this 

    my $i;
for $i ( 0 .. 10 ) {
    last if <somecondition>;
    ...
}
my $x = substr $somestring, 0, $i;

    [download]

    was consistant with 

    my $i=0;
{
    ...
    last if <somecondition>;
    $i++;
    redo;
}
my $x = substr $somestring, 0, $i;

    [download]

    or 

    $i=0; 
do{ 
    ...
    $i++ 
} until <somecondition>;
my $x = substr $somestring, 0, $i;

    [download]

    If you stop getting hung up on the magic of $_, which I wouldn't change anyway, I think that lexicals that automagically revert to some previous value after the programmer has explicitly modified that value is a mysterious and non-useful behaviour that definitely doesn't DWIM.

    If the programmer wants that behaviour, he could still get it by using nested scopes to achieve it 

    my $i=42; 
for my $i (1..10){ 
    print $i; 
} 
print $i;
## gives
1 2 3 4 5 6 7 8 9 10 42

    [download]

    As is, the current behaviour is a special case (of a pre-existing lexical that gets automagically localised), that doesn't fit the pattern of other looping constructs (map & grep can't use lexicals as their iterator variables) and a special case that removes flexibility, adds nothing and is confusingly non-useful.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

      I’m just trying to think of a rule by which this could be made consistent and non-surprising, but failing to. I suppose it would be okay to disambiguate the desired behaviour for lexicals on the presence of a my on the loop construct – but then what about globals? Should they always be aliased? I don’t like that – I’d definitely want parity here, else people are going to have to be taught about the subtlety that foreach behaves differently when given a global than when given a lexical. Maybe require foreach our $pkgvar to get aliasing for package variables? That would be strange, though, considering the actual semantics of our. And then what about $_ – do we leave it as a strange exception case?

      Given that it would be so difficult to find sane semantics to support the non-aliasing behaviour, as well as that IME you want the aliasing behaviour 99.9% of the time, I think it’s clear why my preference is to just punt on this issue. I understand why you would prefer it otherwise, and I agree that it would be nice to have this behaviour, but I think there are just too many issues to untangle once you venture past the use case in your sample code.

      Maybe TimToady could let this all stew for a while and come up with one of his trademark lucid decompositions, but I can’t think of anything more desirable than the current 80/20 solution.

      Makeshifts last the longest.

[reply]
[d/l]
[select]
        but then what about globals? Should they always be aliased? ... And then what about $_ – do we leave it as a strange exception case?

        $_ already is a "strange exception", it gets used without being mentioned and has a myriad of magical behaviours associated with it (that I wouldn't want to loose), this would continue the tradition of that variable.

        In the case of other globals, I hadn't really thought about them much as I don't make use of them much, but having thought about it, I don't think that there is a case for localisation.

        If they already exist in the symbol table, they have been used before, and should not be localised. The programmer has explicitly indicated that they wish to re-use this variable, and any changes should persist. Trust that the programmer knows what they are doing.

        If the programmer wants to both re-use an earlier global, and retain it's original value afterward, he has the option to localise it himself--just as he would have to in any other situation.

        If the variable does not yet exist in the symbol table, there is no great value in localising it, and you remove the potential for using it's final value subsequent to the loop.

        So basically, $_ is special--because it is already special--and for any other variable, the user controls localisation through the keywords my or local, just as he would for any other construct.

        Seems to me that would be the most logical, useful and consistant behaviour. Still, it's all academic anyway.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom