On Sat, Aug 27, 2005 at 17:38:26 +0200, Ingo Blechschmidt wrote:
> Hi,
> * my @array = <a b c d>;
>   @array[1] = "new";
>   # Array elements are, of course, new (rw) containers.
> * my @array = ($foo, $bar);
>   @array[0] =:= $foo;
>   # False -- array element are new containers.
>   @array[0] = $baz;
>   # $foo unchanged
> I think these semantics are pretty clear. But what about lists?
>   ($foo, $bar)[0] =:= $foo;
>   # False (i.e. no difference to arrays) or true?

I think this is true, because you can say:

        ($foo, $bar) = (1, 2);

And more curiously:

        for ($foo, $bar) { $_ = "Value" }; # implcit is rw
        for ($foo, $bar) -> $bah { $bah = "Value" }; # not is rw... is
        # it a different elem? or the same elem with behavior changed
        # for this scope?

If flattenning becomes involved, then it gets harder to decide:

        ($foo, @array)[2] =:= @array[1]; # i don't know about this
        ($foo, [EMAIL PROTECTED])[2] =:= @array[1]; # i think this is 
definately false
There are two types of lists though - ones that pass call boundry
and ones that don't.

Those that don't are more like syntactic constructs than data types.
They could be implemented as lazy arrays whose elements are aliased
to containers they contain.

Lists that cross call boundries are more like lists of values - we
return to the is rw issue from the for loop (those who like closure
will notices that subs that 'is rw'). In this sense, the moment a
list is bound as a parameter or returned from a call, and the
boundry is not marked 'is rw', then the list doesn't have the same
nested containers anymore. I think that furthermore, even if it's
optimized to not duplicate read only containers that were flattenned
into it, they are still not the same id.

 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!

Attachment: pgp2pjMeM0smQ.pgp
Description: PGP signature

Reply via email to