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