<div dir="ltr"><div dir="ltr">On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="font-family:tahoma,sans-serif">In short, why are the design considerations for stack frames different to heap objects?  I think of a stack frame simply as a heap object that happens to be allocated on the stack</div></div></div></blockquote><div><br></div><div>I agree with this perspective—I think it is generally an accurate one. Indeed, I think it may very well be true that what I’ve described largely applies to heap objects as well as stack frames, and working on continuations just means I’ve much more time thinking about stacks. Perhaps if I were working on the garbage collector I would be asking the same question about heap objects.<br></div><div><br></div><div>For example, we have MVAR_CLEAN and MVAR_DIRTY, but each of those types is only used by one statically-allocated infotable, as far as I can tell. In some parts of the code, we check that the closure type is MVAR_CLEAN or MVAR_DIRTY, but in other places, we check whether the infotable is stg_MVAR_CLEAN_info or stg_MVAR_DIRTY_info. Meanwhile, we have both stg_TVAR_CLEAN_info and stg_TVAR_DIRTY_info, but they share the same TVAR closure type!</div><div><br></div><div>The decisions here seem fairly arbitrary. But perhaps there is some method to the madness, or perhaps someone prefers one approach over the others, in which case I would like to hear it! And if not, well, at least I’ll know. :)</div></div></div>