Set vs. Assign..?
Togos
ago but it never showed up so I think it
got spam filtered or something. <:-/
Anyway, just to clear things up, here
is my take on 'set' and 'assign':
set: replace the reference in the
destination register
assign: don't change the reference in the
destination register; tell the currently
referenced object to assign itself a new
value.
You can think of integer and float registers
as holding references to objects whose values
cannot be changed (so it doesn't make
any sense to assign to integers or floats)
Things work out very nicely, this way.
Currently (as far as I am aware) IMCC uses the
"=" operator to mean both set and assign, which,
as I described above, are very different
operations. The rules for whether the "="
operator implies set or assign semantics are
dependant on the semantics of the underlying
Parrot opcodes. Therefore, in order for the
programmer writing IMCC to know what their
"P0 = P1 + P2" actually does, they must be very
familiar with the underlying opcodes. Not that
there's anything wrong with being familiar with
opcodes (you'd pretty much have to be to write
anything useful with IMCC), but for those operations
which IMCC has infix operators for, having to know
the rules for when "=" has set or assign semantics
defeats much of the purpose of using the infix
operators.
I have been proposing that there
be 2 separate "=" operators. One for set and one
for assign [1]. That way it is obvious
from looking at the code what the semantics are.
If there is no way to do what is written
('assign' a value to an integer, for instance)
then IMCC should exit with an error message
saying so, but what it shouldn't do is pretend
that the code says <set-operator> where the
author meant <assign-operator>.
I don't unferstand the logic of having one
operator having 2 different sets of semantics
depending on rules which are non-obvious
and very implementation-bound ("P0 = P1" does
set, "I0 = I1 + I2" does set, but "P0 = P1 + P2"
does assign. WTF?). As IMCC is meant to provide
a more abstract interface to Parrot, having
this (quite useless, as far as I can tell)
implementation-bound set/assign Semantic
Surprise(TM) business for "=" is a Bad Thing.
So far I have not heard any reason why there
shouldn't be 2 separate operators. I would be
MUCH more comfortable writing my compiler to
target IMCC if this change was made.
And so my question is:
Can anyone give me a good reason why things should
be kept the way they are? Or are there plans to
change IMCC to use 2 '=' operators?
[1] I don't really care what the operators look like,
but here are the 2 suggestions I've seen:
":=" for set, "=" for assign
"=" for set, "<-" for assign
Maybe a cross between these would be
even better, as "=" could then be depricated:
":=" for set, "<-" for assign
[2] Current code to proposed code, assuming
":=" for set, "<-" for assign
I0 = I1 + I2 ... I0 := I1 + I2 # set
P0 = P1 + P2 ... P0 <- P1 + P2 # assign
I0 = P0 ... I0 := P0 # set
P0 = I0 ... P0 <- I0 # assign
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com