Repository navigation
Fail to derive Generic with record argument referenced through type synonym #1443
Description
Activity
I assume
MyRecordwas calledPointwhen you ran the compiler?Just checking :)
Does it work when
MyRecordis not a synonym in theFooconstructor? I don't know whether we can derive generics for records...Yes it does. Records are a part of our
Genericdata type https://github.com/purescript/purescript-generics/blob/master/src/Data/Generic.purs#L34Cool, it's just "type synonyms again" then. I really need to get around to trying my idea for handling them...
I think the issue arises because
Data.Genericdefines instances for everything I listed above, but record. When the record is present directly compiler derives it, but if it's behind a type synonym because of some bug compiler doesn't follow the type synonymThe error is now
Error found: in module Main at 1443.purs line 9, column 1 - line 9, column 39 No type class instance was found for Data.Generic.Generic { y :: Number , x :: Number } in value declaration fooGenericThis happens because type synonym desugaring happens after derived instances get elaborated.
8 remaining items
If there's anything I can do to help here, let me know and I'll take a wack. This is biting us too now that we're using generics in anger.
@gbaz That would be great, but it's not obvious to me how this will be fixed yet. Type synonyms are desugared in the typechecker after instance deriving is done. Perhaps there is a nice way to reuse the
Environmentif we move the instance deriving into the typechecker, like what I did in my recent PR for thePartialconstraint changes.I'm passing this along, and I think some people on our team want to start looking at it real soon. We'll keep you up to date if we make progress :-)
Is there a reason why type synonyms must be desugared after instance deriving is done? This bug is becoming a blocker for my team as well, and changing the desugaring order sounds like an easy fix.
Unfortunately it's not entirely straightforward as the desugaring happens in two different ways.
There's an initial desugaring pass that handles a lot of stuff, like making all names fully qualified, desugaring
donotation, object wildcards, etc. and the derived instances are also dealt with at this point.The type synonyms are desugared during the typechecking pass, which happens after all the other desugaring has been done (and in fact requires it to have been done, it will
errorif some of the sugar AST cases are encountered).I think @paf31 intends to move instance desugaring into the typechecking pass to resolve this, but I've not looked into it myself to see how involved that is. I'm pretty sure you can't just move the desugar function from one place to another though. 😄
Reacted by James YuAh, no wonder I couldn't find the type synonym code, it's in the typechecking pass not the desguaring pass. Thanks for clarifying!
fails with