It sounds awfully special-case to store these type macros in a new field of `TcGblEnv` instead of as just another kind of `TyCon`.
But all this is just in your personal fork of GHC, so you can be as
special-case as you like. I'd just plough ahead and do the easiest thing.
If you make a proposal, and persuade the committee, we can look again.
Until then it's probably not worth us spending a lot of time making the
implementation beautiful.
Simon
On Tue, 26 Jul 2022 at 04:14, ÉRDI Gergő
On Mon, 25 Jul 2022, Richard Eisenberg wrote:
I see this substitution as happening before any type-checking, so zonking shouldn't be an issue. That is, I would expect a
substHsTy :: UniqFM Name (HsType GhcRn) -> HsType GhcRn -> HsType GhcRn
to do the work, entirely before type-checking.
If I were to do this fully during renaming, how do I even find out that a `Name` refers to a type macro? During typechecking I can look up the `TyThing`, see if it's a `MacroTyCon`, and get the rhs from that. But I don't think we store anything about already-renamed declarations during renaming the same way we store info about already-typechecked things during typechecking in `tcg_type_env`.
It sounds awfully special-case to store these type macros in a new field of `TcGblEnv` instead of as just another kind of `TyCon`.