Hi. Thanks for the very useful replies to my recent question! I am still exploring some updating techniques for my pet STG machine. This time I am turning over an idea about closures returning primitive (unboxed) values. These ones, regardless other updating considerations, obviously cannot be updated directly, because the results are not closures. However, I think we could use a special closure for updating in these cases, with a single field holding the primitive result, which, when entered, should simply return its stored primitive value. operationals of my trick: -"someclosure", a zero-arg-closure which eventually returns a primitive value, is entered. -Before starting its evaluation, an update frame is pushed on the stack. -eventually, evaluation is done and a primitive value is returned. -a continuation is popped from the stack and entered, which turns to be actually the previously pushed update frame. -the update frame overwrites the closure to be updated with the a special closure, which holds the result value and, when entered, returns it. I think the same effects can be achieved using boxed values wherever commoning up the evaluation is required, but I think it may be slower (and it may use more heap space). And, of course, this trick only makes sense if the compiler front-end builds lots of zero-arg-closures which returns primitive values as result of large computations involving not many boxed values (which could capture, when updated, many intermediate steps of the computation). does someone knows if some similar trick has been implemented? (I have tried to read the GHC RTS (and some others), but it is too hard to understand!). Perhaps this trick is not useful? Or not possible due to some reason? Thanks in advance, Jose David --------------------------------------------- Este mensaje lo ha enviado un Alumno de la Universidad de Malaga. http://www.alumnos.uma.es/