I sent something similar to this about 6 hours 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