Bob Rogers <[EMAIL PROTECTED]> wrote:
> From: Leopold Toetsch <[EMAIL PROTECTED]>
> It probably just depends on the implementation of Perl5 references.
> Hmm. I'm probably missing something (it wouldn't be a first), but if
> the reference points to $a itself rather than the PMC to which $a
> refers, then you could implement this without morphing, at the cost of
> an extra indirection for each Perl deref.
Yep, I was thinking about that too. The cost of one indirection per
deref is really small. The problem with that approach is: what does "$a"
mean. It's currently a slot in the ScratchPad PMC, which is an
OrderedHash. By adding more lexicals this ScratchPad PMC is likely to
resize, which can easily change the location of the "$a" PMC.
Combined with my proposal that the lexicals storage is part of the
persistent register range, this approach would be trivial.
$r = \$a
would just translate to an equivalent of:
Pr = &Pa
whatever is stored in the register slot named "$a" is refered to by the
reference Pr. Pr is of course still a Ref PMC, but that doesn't matter
for this POV.
> But, without PMC morphing, referencing the middle of an array is more
> problematic:
> my @b = (1, 2, 3);
> my $c = \$b[1];
> $$c *= 4;
> # prints "1 8 3\n".
> print(join(' ', @b), "\n");
> To make this work, $c would need to contain a pointer (i.e. a reference
> PMC) into the middle of @b, which could be trickier for GC.
Not really. The ref "$c" can be a bound Key PMC that contains the
array and the index (where index is an arbitrary possibly nested Key).
> The concept reminds me of "locative pointers" in the old Lisp
> Machines;
[ ... ]
> ... If the ref PMC also has
> a pointer to the header of the containing object, then GC marking is
> trivial.
Rather the latter.
> You may be way ahead of me here, but I am beginning to think that a
> morph-free Parrot might be feasible. I am going out on a limb to
> suggest all of this because, IMHO, it might make Parrot simpler and more
> robust overall, and certainly ought to interoperate better between Perl
> and non-Perl.
Yeah. Interoperbility is another strong argument. Having a mixture of
morphing and immutable (scalar) PMCs could really be dangerous.
> So, tell me, what have I missed?
I don't think that you missed something.
> -- Bob Rogers
leo
