Hi, On Tue, Nov 29, 2011 at 21:28, Romain Guillebert <romain.py@gmail.com> wrote:
Probably because he (as a clojure developer) likes immutability of data structures.
No, it's really needed for the way it is written: by creating a new dict, the old purefunction results no longer apply. But we are (indeed) using a slightly different approach in PyPy by not copying the dict, but instead creating a new empty 'signature' object that we pass to the purefunction too. We don't have anything exactly similar in PyPy, I think. I would go for something along the lines of: class Cell(object): _immutable_fields_ = ['content?'] # quasi-immutable content = None _all_cells = {} @elidable # same as @purefunction def get_cell(key): return _all_cells.setdefault(key, Cell()) or, depending on the usage, maybe @elidable_promote, if the key should always be a jit-constant. In this way the user gets a Cell corresponding to the key he asked for, and then he can read the 'content' field, which is initially None but may be set to something else. Because it is a quasi-immutable field, this is all done with no machine code produced. If later the same Cell has its 'content' field modified, then the old machine code is discarded and new code is produced. Note the indirection: the JIT should not see the @elidable code, but just call it at tracing time; but the JIT must see the read of the 'content' field, to be able to use the fact that it's a quasi-immutable. A bientôt, Armin.