http://qs1969.pair.com?node_id=946908


in reply to Re^15: ref to read-only alias ... why? (notabug)
in thread ref to read-only alias ... why?

Exactly the same aliasing occurs for both for(1..3) and for(1).

I'm sorry, but you're dead wrong here: 


my $a = 2;
$_++ for 1..$a;
print "$a\n";
# 2

my $a = 2;
$_++ for $a;
print "$a\n";
# 3

[download]
clearly, there are two different mechanisms: the first does not do aliasing, whereas the second does.

But anyway, I still don't understand the "working case" you referred to that my patch will break. Could you please produce that?

Intentionally coded to return a value that can be changed without causing a read-only error.

Is there any proof of that intention? Best in perldoc?

Replies are listed 'Best First'.
Re^17: ref to read-only alias ... why? (notabug)
by ikegami (Patriarch) on Jan 09, 2012 at 09:59 UTC

    clearly, there are two different mechanisms: the first does not do aliasing, whereas the second does.

    How can you claim that for(1..3) doesn't alias when you can clearly see ++$_; having an effect on what it returns?

    In both for(1..3) and for(1), $_ is aliased to each value returned by the expression in the parens.

    I'm sorry, but you're dead wrong here:

    First, your example does not demonstrate a lack of aliasing. It just shows that $_ isn't aliased to $a. That's to be expected, because 1..$a doesn't return $a anymore than 0+$a does.

    Second, you pulled a switcheroo. I said for(1..3) aliases (and proved that it does), but your code uses for(1..$a). for(1..$a) is implemented differently; it's a counting loop and not a foreach loop. It still aliases, though.

    Is there any proof of that intention? Best in perldoc?

    There was code written to specifically perform this effect. By definition, the effect must be intentional.

[reply]
[d/l]
[select]
      Ok, I agree about for (1..3), that's reasonable. But I don't agree on this:

      There was code written to specifically perform this effect. By definition, the effect must be intentional.

      If it were true, why then threaded and non-threaded perl give different results in \ $_[0] ? Was that also intentional? Even if it was, that's bad intention to me, and bad design. A bug, basically.

[reply]

        If it were true, why then threaded and non-threaded perl give different results in \ $_[0] ?

        I don't know why that code isn't reached for non-threaded Perls.

        Even if it was, that's bad intention to me, and bad design. A bug, basically.

        You're wrong to simply declare that it's a design flaw.

        Three people in this thread and many of the core Perl5 developers (if not all) know that it's not self-evident that literals should create non-modifiable values.

        You're wrong to simply declare that it's a bug.

        It's only a bug if it doesn't behave as intended, and some of the core Perl5 developers have explicitly stated they believe literals should return modifiable values.

        I was hoping you'd come around to expressing an opinion or making an argument, but all we got were empty declarations.

[reply]
[d/l]
Re^17: ref to read-only alias ... why? (notabug)
by LanX (Saint) on Jan 08, 2012 at 21:04 UTC 
    my $a = 2;
$_++ for 1..$a;
print "$a\n";
# 2

    [download]

    thats a confusing example, nothing else than

    my $a = 2;
$_++ for 1..2;
print "$a\n";

    [download]

    I don't understand what it's supposed to prove.

    Cheers Rolf

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom