Well I just realized something. Or at least realized a better way to explain it.
Let's say we have a HLL that is mapping HL variables to Parrot registers.
someint1 = someint2 + someint3
will, of course, map to something like
$I1 = $I2 + $I3
Now, if those ints were replaced by PMC references: (behavior A)
somepmc1 = somepmc2 + somepmc3
we Ruby folks would like to be able to do:
$P1 = $P2 + $P3
Which, of course, doesn't work.
Well... actually you don't want what you're asking for.
Specifically you don't want
foo = bar + baz
to access the foo, bar, or baz named slots in the global or lexical variable areas if you can possibly help it. Really, you don't--doing so likely needs a hash lookup (for globals) or an indirect slot lookup (for lexicals, if you're lucky. If not you have a hash lookup) You *definitely* don't want it to translate into:
$P0 = fetch_lex "bar" $P1 = fetch_lex "baz" add_new $P2, $P0, $P1 store_lex "foo", $P2
Because that's really inefficient if you've used foo, bar, or baz elsewhere in the compilation unit already. It's also very wrong if foo is *not* an object, because you don't want assignment to unconditionally rebind--the destination variable has to control what happens on assignment. Rebinding might be the right thing, but, then, it might not be. (If foo, for example, is a low-level 32 bit integer you would *not* want it rebinding)
The standard, and arguably correct, thing to do here is to introduce a mediating structure. It's a pretty common thing--you bind the name to the mediating structure essentially permanently, and then hand your object off that structure. Doing assignment then, rather than rebinding the name to the new object, instead rebinds the mediating structure to the new object. This allows the compiler to cache what is fetched from the symbol tables--since the binding to the mediating structure is permanent you can avoid multiple fetches and stores.
The added bonus here is that if the thing you got out of the symbol table *isn't* one of these mediating structures (because it's a PMC for an int, say, or a matrix) then assignment still Does The Right Thing, since the destination controls the assignment.
Right now the missing piece for Parrot is that mediating structure--ParrotObjects, rather than going directly into the symbol tables, really need to be hidden behind ParrotReference or ParrotObjectHandle PMCs to provide the appropriate level of indirection.
If we do that it all works out right, which is quite nice.
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
