> 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.
Works better to think of only 'set' semantics.
I think of it like this, and it makes things
work out very nicely:
Think of registers as little boxes. Now think of
the contents of registers as little tickets you
can store in the boxes. The tickets aren't the
objects themselves, they are merely references
to the objects, which stored in the back room.
The only difference between PMCs and integers is
that you don't actually need to store any integers
in the back room, as the references on the tickets
contain all the information you could ever want
about the integer, anyway (all their bits).
Now, you can swap tickets into boxes
(we call this "set", or "="), but we can
also go into the back room and alter the
values referenced by tickets (we call
this "assign", and TOGoS suggests that
we have a "<-" operator for it)
So you can't _assign_ a value to an
integer, as there is not actually
anything in the back room:
I0 = 5
assign I0, 6
would mean to put 5's ticket in I0, and then
change 5. But you can't change 5. 5 is just
5 and that's all there is to it. If you changed
5's value to 6, then it wouldn't be 5 anymore!
Anyone who tries to do
5 = 6
deserves whatever errors come to them ;-)
However, you can _set_ the value in an integer
register to an integer
I0 = 5
I0 = 6
with no problem. Here you are simply putting a
different ticket in the box.
Similarly
P0 = 3
Should not alter the PMC stored in the back
room referenced by the ticket in P0, but
just replace the ticket with a different one. Or
else raise an error saying that IMCC doesn't
know how to do put an integer ticket into a PMC
box. But what it shouldn't do is go into the
back room and screw with your PMCs, as that
would be inconsistent with the syntax/symantics
for assigning values to non-PMCs.
Currently,
I0 = I1 + I2
only changes which int is in the register I0,
while
P0 = P1 + P2
leaves the ticket alone and alters the
PMC referenced by P0. Now everywhere
you referenced that PMC, you'll be getting the
new value, whereas with the ints you still have
the old value. It may be the case that that's what
you wanted, but you shouldn't pretend that
going into the back room and changing values
is the same thing as swapping a ticket into a box.
> But in this case, we're doing it
> because:
> a. It speeds things up.
> b. It avoids a very difficult DWIM.
I understand why you might not want
to have 'set' _semantics_ for add(pmc),
(higher opcode count, as Leo pointed out)
but I was just talking about _syntax_, here.
It's fine if the PMC add op only has
assign semantics for practical reasons,
as long as it doesn't pretend to have
set semantics by using the same syntax
as the int add op which does have set
semantics.
> c. It simplifies the syntax.
It makes one operator mean 2 completely
different things depending on context.
I guess it depends what kind of simplicity
you want. You seem to prefer fewer operators,
while I would prefer each operator to only mean
one thing. Having separate operators for set
and assign would arguably make IMCC code (and
compilers that target IMCC) more maintainable.
I wouldn't worry so much about the PASM syntax:
add(p1,p2,p3) # OK, whatever
add(i1,i2,i3)
As that is low level enough that you'll
have to read the docs to know exactly
how to use it, anyway.
But IMCC seems high-level enough (it's got infix
operators, for one thing) that it should be
disambiguated. IMCC syntax seems to imply a certain
meaning more than PASM opcode names do, so it's
more important that the implied meaning is the true
meaning.
P1 = new PerlInt
P1 <- P2 + P3 # When you see "<-" instead of "=",
# You know that it's operating on
# an existing value, not just
# altering the contents of
# registers, as your experience
P0 = P1 # would suggest happens when
I0 = I1 + I2 # you use the "=" operator.
> 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.
Ints never use 'new' or 'assign'. But when
ints and PMCs share a common syntax, as they
do with
a = b + c
, it should mean basically the same thing for both.
> # 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...)
Yes, and I was suggesting that maybe that's
not what we always wanted to do. When we do
want to do that, though, it should be obvious
from the syntax that we're doing an assign,
and not a set.
Summary of my argument:
the "=" operaror should always put a new value in
the specified register, whether it be a PMC, and
int, or whatever. If you're not putting a new value
in the register, but modifying the value already in
there, then use the "<-" operator! :-)
(Now, I don't care if you replace "=" and "<-"
with different strings, as long as they're
different from each other.)
*creak* OK I'll shut up, now.
About this, anyway.
For now.
:-)
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
