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