On Tue, May 16, 2006 at 03:24:20PM -0500, Patrick R. Michaud wrote: > On Tue, May 16, 2006 at 09:00:17AM -0700, Chip Salzenberg wrote: > > On Fri, Apr 14, 2006 at 06:17:01PM -0500, Patrick R. Michaud wrote: > > > How would you envision doing something like the following > > > Perl 6 in PIR? > > > > > > sub foo($x is rw) { > > > $x = new SomeClass > > > } > > > > > > @z = 0..2; > > > foo( @z[1] ); > > > > I suspect that this problem is quite deep and may require significant > > changes to Parrot. But I don't want to jump to conclusions, because my Perl > > 6 is not as good as yours. > > It's entirely possible my Perl 6 isn't accurate here, either. > My intent is that after the call to 'foo', @z[1] should be an > instance of SomeClass because $x was a rw parameter in foo.
I sympathize with your desire for an answer, but it's probably a good idea for you to get the sample code and desired behavior right in all its Perl 6 details before we go further. As for me, I'm not sure what the "=" in &foo is *supposed* to do in Perl 6. I think it does what you suggest, but I'm not entirely sure. And I'm even less sure whether ":=" in the same place would be legal, and if it were, what it would mean. Furthermore, I think you'll need to ask Audrey or Larry about the implications of the Perl 6 container/value dichotomy on your example. Now that Perl 6 scalars consist of containers that hold values, every Perl 6 scalar is made up of two distinct PMCs[*], so it seems to me that you're likely to be able to do what you want with current Parrot. [*] except for the containers that can't hold PMCs, e.g. C<my int $i>. The reason I think you need to do this first is that "is rw" with "=" is a common case, while supporting ":=" probably isn't. As an extreme possibility, if "is rw" makes a deep enough alias to amount to call-by-name, Perl 6 may need to pass all "is rw" parameters as implicit references, and dereference them automatically and invisibly at each use. Look before I leap. > AFAIK "foo"(z[1]) isn't a valid call in Parrot. I meant that to be the equivalent of $P0 = z[1] "foo"($P0) > I suppose it could be made to be valid. But even then, I wonder > about: > > .sub foo > .param pmc x > $P0 = new .SomeClass > x = $P0 > .return () > .end > > [... ] Assuming that "assign" was meant here [...] It was, mea culpa. > I think [changing '= new SomeClass' to '= 1' is] OK only if we change the > naive PIR to use 'assign' instead of 'set', and then only because $x > happens to already be an Int when foo is called. To bring it down to base > types, what about: > > sub foo($x is rw) { $x = 'hello'; } > > my $y = 3; > foo($y); > > Can Parrot make this work if the Int type (.Integer) isn't automatically > morphing into a Str (.String)? I infer that in Perl 6, assigning '1' is at root the same problem as assigning 'new SomeClass', because morphing is *not* assumed to be an ability of most types, so it may be necessary to store a new value of a completely new type in the given target container. -- Chip Salzenberg <[EMAIL PROTECTED]>