in reply to Fringe case slice behavior

Um, most of this is documented behaviour. For instance if you assign a scalar to a list, you actually assign a list of length 1 to a list, and extra entries get undef.

Secondly you're misrepresenting the defined behaviour of comma in scalar context. It isn't that comma acts that way, it is that lists act that way and comma normally delimits lists. Unless precedence gets in the way as in @foo = 1, 2; which is parsed (@foo = 1), $bar = 2;

Of course when you later look at +=, the same list behaviour shows up on the left hand side, resulting in the last element in the list being incremented.

The hash slice behaviour is all, of course, undefined since the order of keys is arbitrary (even more so in recent Perls).

The exact warnings that you get from various situations are, however, more likely to change from version to version.

UPDATE: Oops, ysth is (of course) correct. My bad.

Replies are listed 'Best First'.
Re: Re: Fringe case slice behavior
by ysth (Canon) on Jan 13, 2004 at 20:01 UTC
    The hash slice behaviour is all, of course, undefined since the order of keys is arbitrary (even more so in recent Perls).
    Slices are always in the order in which you specify the keys.
[reply]
Re: Re: Fringe case slice behavior
by Anonymous Monk on Jan 14, 2004 at 04:10 UTC
    Secondly you're misrepresenting the defined behaviour of comma in scalar context. It isn't that comma acts that way, it is that lists act that way and comma normally delimits lists

    I'm inclined to respectfully disagree here. According to perlop, "Binary "," is the comma operator. In scalar context it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value. This is just like C's comma operator. " I feel like this is a better way to think about it, since it's consistent with the doctrine of "there's no such thing as a list in scalar context."

[reply]

In Section Meditations