TOGoS:
# syntax. As it is, the add(ints) op and the
# add(pmcs) ops do very different things (one
# has 'set' while the other has 'assign' semantics),
# but they look exactly the same. If not at
I think that's mostly because there's no difference between set
semantics and assign semantics for ints. You can think of them as both
having assign semantics, if you like.
# I sense the 'only people who really know
# what they're doing wil use this interface,
# anyway, so we don't have to make it nice'
# attitude in a few other places... most
# notably the Windows API.
You don't have to lecture me on the Windows API--I use Windows, and I
have the scars to prove it. ;^) But in this case, we're doing it
because:
a. It speeds things up.
b. It avoids a very difficult DWIM.
c. It simplifies the syntax.
Sure, you don't need to use 'new' on an I register, while you do on a P
register--but you *never* need to use 'new' on an I, if memory serves.
So that's a consistent...uh...inconsistency between I and P registers.
# But aside from all that, I still think
# that the set semantics for add, etc. would
# make a lot of sense in many cases, because
# the PMC that is being addded will know
# how best to return.
The thing is, the target PMC needs a way to react to the fact that it's
being assigned to. The real semantics we want are something like:
assign $P0, (add $P1, $P2)
(Assuming that ops behaved that way...)
I don't think any vtable ops actually allocate new PMCs and return
them--to my knowledge, they always operate on a target PMC. I believe
that this is done for speed reasons, although I'm not sure about
that--after all, it's much cheaper to allocate target PMCs only when you
need them than to allocate them when you don't.
--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."
