note
tilly
Several of these changes look like they are moving more
towards like Ruby and Python today. Some of the automatic
dereferencing things make me wonder whether Larry is toying
with changing Perl's copy-by-value on assignment rule
as well.<P>
What do I mean by that?<P>
Well in Perl 5 if you say:
<code>
$foo = $bar;
</code>
a new value is made of $bar and copied into $foo. If I
later say:
<code>
$foo .= $baz;
</code>
then $foo is modified in place. By contrast in Ruby if
you say:
<code>
foo = bar;
</code>
you copy by reference. So later on if you say:
<code>
foo += baz
</code>
that expands to:
<code>
foo = foo + baz;
</code>
and you create a new string and copy a reference of that
to foo. To get the fast in-place modification you have to
instead try:
<code>
foo << baz;
</code>
which will also modify bar.<P>
Anyways if Perl changed this basic semantic, here is what
would be affected:
<ol>
<li> You save memory.
<li> Copying data speeds up.
<li> Incrementally building large strings slows down unless
you provide an operator for it with explicit side-effects.
<li> Subroutines that expect to change their arguments by
reference would be hard to rewrite from Perl 5 to Perl 6.
</ol>
Does anyone have any idea what Larry's thinking is on this
issue? Will Perl continue to copy-by-value on assignment?
80736
80736