Re: Does list construction create new containers?
Hi,
Yuval Kogman wrote:
> On Sat, Aug 27, 2005 at 17:38:26 +0200, Ingo Blechschmidt wrote:
>> ($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?
I'd say (and this is how it's implemented in PIL2JS currently [1]) it's
the same element, but wrapped in a proxy which dies on STORE requests.
I.e.:
for ($foo, $bar) -> $bah { $bah = "Value" } # is really
for ($foo, $bar) -> $bah is rw {
(new Proxy:
FETCH => { $bah },
STORE => { die "Can't modify readonly..." },
) = "Value";
}
> 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
Hm, I'd say both are true. Consider:
my $var;
sub foo ([EMAIL PROTECTED]) { @args[0] =:= $var };
foo($var, $other, $stuff);
# Should definitely be true, I think.
--Ingo
[1] FYI, here's the relevant snippet of PIL2JS's subroutine signature
handling code ([2], lines 263-265):
unless($self->{tpParam}{isWritable}) {
push @js, "$jsname = new PIL2JS.Box.ReadOnly($jsname);";
}
[2] http://svn.openfoundry.org/pugs/perl5/PIL2JS/lib/PIL/Params.pm
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon!|
Re: Does list construction create new containers?
On Sat, Aug 27, 2005 at 17:38:26 +0200, Ingo Blechschmidt wrote:
> Hi,
>
> * my @array = ;
> @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!!!
pgp2pjMeM0smQ.pgp
Description: PGP signature
Re: Does list construction create new containers?
Ingo Blechschmidt skribis 2005-08-27 17:38 (+0200): > I think these semantics are pretty clear. But what about lists? Lists are a language thing, not a data type. List elements can be lvalues. > ($foo, $bar)[0] =:= $foo; > # False (i.e. no difference to arrays) or true? I think this can be (but that doesn't mean will be) optimized to $foo =:= $foo which in turn could be optimized to truth. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
