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


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

You seem to be operating from the point of view that "It's self-evident that literals should create non-modifiable values." Yet that's currently not the case in 50% of the examples I posted.

«1» in «for (1)» could return a non-modifiable value, but it intentionally returns a modifiable value (in a sense) some of the times.

«1..3» in «for (1..3)» could return non-modifiable values, but it returns modifiable values, and it's intentionally not getting changed because people want literals to return modifiable values.

It's not self-evident that literals should create non-modifiable values.

Replies are listed 'Best First'.
Re^14: ref to read-only alias ... why? (notabug)
by dk (Chaplain) on Jan 06, 2012 at 22:26 UTC
    Sorry, I didn't make myself clear. I do see that these values are modifiable. But my objection is that for(1..3) construct doesn't do aliasing, which is 50% of the original bug. If my example above did print 3 instead of 2, then yes, I'd accept that as a proof.

    Same thing on $_++ for 1 - it dies, because of aliasing comes into play. And I neither get what does "intentionally returns a modifiable value (in a sense) some of the times" mean. For what I see, it just doesn't return a modifiable value, at all.

      But my objection is that for(1..3) construct doesn't do aliasing

      That's not true. Exactly the same aliasing occurs for both for(1..3) and for(1).

      "intentionally returns a modifiable value (in a sense) some of the times" mean

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

        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
        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?