Some handwaving in overloading mitigates this. But I see the issues getting worse in Perl6.

I'm certainly no expert on Perl6, but my understanding of this from the literature I've seen is that:

• All things are objects of some class...
• ...even primative types/classes like "scalar" and "array".
• All operators can be defined on a per class basis...
• ...even primative types/classes like "scalar" and "array".

Which when you add it all up, means that clases like "scalar" and "array" can define the assignment operator to make a new copy of the rvalue and return that copy, while the assignment operator for whatever Abstract Base class all user defined classes subclass by default will probably have the assignment operator defined to return a reference to the rvalue.

(Assuming of course, that the Perl6 design folks want assignment of scalars/arrays/objects to work exactly the same way it does in Perl5 -- and even if they don't I'm sure Damian will write a "copyprmativesbyvalue" pragama that people can use.)

Today in "use overload", the so-called assignment operator can be defined. If an overloaded operator is called on an object that is not unique but shares a reference, this function is called to duplicate it. That is, it's uses as a lazy copy-on-write mechanism.

This means that Perl must know that the reference is shared, and which functions are indeed "mutators". I can have a complex number class appear to have value semantics when an assignment is followed by an overloaded operator such as "+", but not for a named method call.

So, something like

$a= $b;
++ $a;
[download]

can indeed be made to work like built-in numbers, calling

$a= $b;
$a->set_imaginary (5);
[download]

cannot, and would set the imaginary part of $b as well.

Perhaps Perl6 simply needs to have the lazy copy function applied uniformly whenever a mutator is called, whether you must identify mutators or it figures it out by itself.

Meanwhile, why write the copy code every time? Simply saying that a class is "by value" should be enough to automatically generate the copy function, which copies all the data members of the object.

—John

As long as things are polymorphically sound, I don't see the problem. If you don't know what kind of thing you're dealing with, you'll have trouble. That happens today, and it's really hard to get away from that.

Do you have a code example that shows this? I'm afraid I don't see the big deal.

I've been making a nuisance of myself on this issue now and then. My impression is that explicit references will be gone, that they will be just the same, that they will do what I mean, and that I'm not supposed to worry my head about it.

That does make me worry.

After Compline,
Zaxo

Perl 6 still has references -- you can still take an explicit reference like \@array. However, Perl 6 will automatically take a reference or dereference a reference depending on context. Here are a few examples of Perl 6 with the Perl 5 in the comment.

my %x = ( a => 1 );   # same
my $y = %x;           # $y = \%x
%x{a} = 1;            # $x{a} = 1
$y{a} = 1;            # $y->{a} = 1
[download]

This can surprise a Perl 5 veteran because the code $length = @array won't work the same anymore. (This is a good thing for beginning Perl 6 programmers though!)

However, Perl 6 has more contexts than Perl 5 -- numeric and boolean contexts -- so some Perl 5 idioms still work. For example, if (@array) ... still works because the 'if' uses boolean context. $length = @array + 0 works because '+' uses numeric context.

Of course, arrays are now objects, so the simplest way to get the length of an array is @array.length.

For more information about variables in Perl 6 check out Apocalypse 2.

As I understand it, the 'automatic taking of references' thing only applies when you're dealing with an array/hash/sub in a scalar context.

Judging by the work that's going on in parrot, $a = $b won't copy the value of $b immediately, but will create a 'copy on write reference'. A copy will only be made if either of $a or $b is modified.

$a = \$b should set $a to be a reference of $b (a reference being an actual separate object), and $a := $b should set $a to be an alias of $b (an alias being only a name reference that is resolved at compile-time). I think thats the case, at least :)




:^) # Fear the wrath of the hyper smiley!
[download]

—John