> 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. :)
I suspect it's all just happenstance. Maybe @Ben Gamari <bgam...@gmail.com> knows. One you've had all responses, perhaps document your conclusions in a Note somewhere, and point to it copiously. On Tue, 27 Jun 2023 at 22:53, Alexis King <lexi.lam...@gmail.com> wrote: > On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones < > simon.peytonjo...@gmail.com> wrote: > >> 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 >> > > 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. > > 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! > > 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. :) >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
