Perl6 - value vs. reference issues

Replies are listed 'Best First'.
Re: Perl6 - value vs. reference issues by hossman (Prior) on Sep 13, 2002 at 23:23 UTC
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.)	[reply] [d/l]
Re: Re: Perl6 - value vs. reference issues by John M. Dlugosz (Monsignor) on Sep 16, 2002 at 20:05 UTC
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	[reply] [d/l] [select]
Re: Perl6 - value vs. reference issues by chromatic (Archbishop) on Sep 13, 2002 at 21:33 UTC
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.	[reply]
Re: Perl6 - value vs. reference issues by Zaxo (Archbishop) on Sep 13, 2002 at 22:53 UTC
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	[reply]
Perl6: same great references, new improved syntax by blssu (Pilgrim) on Sep 14, 2002 at 13:42 UTC
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.	[reply] [d/l] [select]
Re: Perl6 - value vs. reference issues by pdcawley (Hermit) on Sep 14, 2002 at 12:07 UTC
I think you're missing the distinction between `$a = $b` and `$a = %b`. The first assigns the value of `$b` to `$a`, the second sets `$a` to be a reference to `%b`. If you to set `$a` to be a references to `$b` then you'd do `$a = \$b` (or possibly `$a := $b`). 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.	[reply]
Re: Re: Perl6 - value vs. reference issues by jryan (Vicar) on Sep 14, 2002 at 19:30 UTC
`$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]	[reply] [d/l] [select]
Re: Perl6 - value vs. reference issues by John M. Dlugosz (Monsignor) on Jun 01, 2009 at 19:26 UTC
Well, it's almost 7 years later and Perl 6 is still a work in progress. But I know the answer to this issue: it works because the `Int` object is immutable. A `Dog` object can change its attributes, so two variables sharing the same object (`$b=Dog::new;$a=$b;`) will perceive the sharing. But an Int will never change. There are no mutating methods on it. Changing the value, e.g. `++$a`, requires lvalue access to the variable, as this is `$a= 1+$a;` and assigns a different `Int` object to `$a`, leaving `$b` to still point to the original unchanged. —John	[reply] [d/l] [select]