Warning, if this message is too long, please skim to the bottom and read
the part marked IDEA, lest it get lost in the rant.
<rant>
Why make keyed access of arrays any more complicated than it
needs to be?
The Ix regs are for optimization, so it seems natural
for Ix or ICx simply return the i-th element, rather than
the "keyed" element. Internally the KEY is converted _back_
to INTVAL if it is native, or calls the get_integer method
of the PMC.
Maybe the problem is we are using the same interface for arrays
as hashes?
If in Perl I say:
push @list, "0th";
push @list, "1st";
print $list[0] . "\n";
print $list[1] . "\n";
I get:
0th
1st
Not being quite the seasoned Perl hacker that some of you are,
can someone point out to me why _arrays_ need accessors
converted to a KEY, then right back to an int. If Perl wants that, fine,
but why force it on the Parrot implementation.
Most languages require array indexes to be integer types, and I thought
Perl did the same.
I figure a lot of code will be of the type
foreach $s (@list) {
print $s;
}
set I0, 0
NEXT:
set S0, P0[I0]
jundef S0, LAST
print S0
inc I0
LAST:
Could this be how chop @list is implemented? Possibly.
I'm not sure, but I know for/foreach is a typical construct in most Perl
programs.
Finally, even though I've heard Dan's reasons, the 75% treatment
of the I, S and N regs still bugs me (can't store globals, cant use
in keyed access). Some languages don't need PMCs at
all for the basic types. They deal with strictly typed items,
and aren't interested in polymorphism of builtin types, rather
they need _support_ for implementing their own polymorphism.
I always hoped that we could rip out most of the PMCs and have
a working VM (keeping certain ones for handling opaque system
objects like IO handles, subroutine handles, symbol tables, etc.)
Right now I don't see this happening. I see lists and hashes
implemented, but called Perl*, not Parrot*. Are we expecting
people to provide a full set of PMCs when they wish to implement
their language on Parrot? What happens to the common runtime then?
Oops, you can't run your Ruby code, you haven't installed libVMRuby.so..
Er, I can't use PerlArray because my language Foo needs arrays
to do X, Y and Z. So I either implement it at the Parrot level, or
write a PMC.
I also don't like the idea of the classes/ directory being full of
every language's PMCs, eek.
That is not my idea of what a VM is.
We are providing a non-orthogonal implementation for other
languages, in my opinion. Granted, if the language wishes
to be compatible with Perl and others running on the same VM,
then they need to follow a few fules, since Perl is 1st priority.
IDEA:
On PMCs themselves: PerlInt is nothing but a wrapper
for a native int. It knows how to call vtable methods of other
objects when it is involved in an operation with that object, and
most importantly it knows how to morph itself, but it is STILL just
a wrapper. Why is this? Wouldn't it make more sense if everything
were 'PerlScalar'. It seems PerlInt, PerlString and PerlNum could
be all combined into a 'PerlScalar'. Then we could go back to
letting things that are ints, be ints. Whee!
</rant>
:)
-Melvin
