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]>
