Wildcards in type synonyms

Simon Peyton Jones simon.peytonjones at gmail.com
Tue Jul 26 08:03:48 UTC 2022


>
> 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ő <gergo at erdi.hu> wrote:

> 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`.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220726/c62334ce/attachment.html>


More information about the ghc-devs mailing list