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. But this is what
languages like Python or Ruby would expect to be able
to do, as they don't need Perl's fancy variable
objects -- a register is good enough. The current
sementics of
$P1 = $P2 + $P3
look more like this:
(behavior B)
somepmc1.value = somepmc2 + somepmc3
Which is obviously different than the semantics of
behavior A. That's not to say it's useless, as Leo
pointed out, it could be used in cases like
> a = global "$a" # or fetch a lexcical or ...
> a = b + c
But it certainly is different.
One problem is that the current semantics use behavior
B, but appear to use behavior A ('a = b + c' acts
differently if you're talking about ints or PMCs). The
other problem is that we often want behavior A, but
have to jump through hoops to implement it using
behavior B. The argument that we shouldn't implement
behavior A because it would add more opcodes seems
akin to arguing that we shouldn't waste opcodes making
a subtraction op since we already have one for
division. They're very different things, and shouldn't
be confused or mangled to serve the purpose of the
other.
My proposal still stands, then:
$P1 = $P2 + $P3
should have the semantics of
pmc1 = pmc2 + pmc3 (Ruby/Python code)
rather than it's current behavior of
pmc1.value = pmc2 + pmc3
And if the latter behavior is common enough, then it
should have its own instruction. 'content_add' or
something. Same goes for the other PMC modifying ops.
- TOGoS
__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
