A few misc. questions that arose. (I made a version of the code that takes the opposite choices on these things)
Why not support Assign to a tuple in source code? It is quite easy to do, since the language already supports it after allocation is exposed.
It is not at all obvious that expose_allocation should come before `remove_complex_operands', since (a) this forces expose_allocation to do the work of RCO for the initial expressions, and (b) it is quite easy to avoid generating complex operands in the exposed allocation template. The opposite order works well.
Why is GlobalValue treated as a (complex) expression? It can easily be treated as an atom.
Tuples are immutable in Python. The challenge section introduces the Python list type, which is mutable, and also introduces subscript assignment.
That's a good point. It didn't occur to me that RCO would handle the issue regarding the initializing expressions. I've added a sentence saying expose_allocation can go before or after RCO.
Looks like there was no good reason. I've switched GlobalValue to atomic.
Thanks!
A few misc. questions that arose. (I made a version of the code that takes the opposite choices on these things)
Assign
to a tuple in source code? It is quite easy to do, since the language already supports it after allocation is exposed.expose_allocation
should come before `remove_complex_operands', since (a) this forces expose_allocation to do the work of RCO for the initial expressions, and (b) it is quite easy to avoid generating complex operands in the exposed allocation template. The opposite order works well.GlobalValue
treated as a (complex) expression? It can easily be treated as an atom.