Repository navigation
Fail to derive Generic with record argument referenced through type synonym #1443
Description
type MyArray = Array String
type MyString = String
type MyNumber = Number
type MyInt = Int
type MyBoolean = Boolean
type MyProduct = Maybe String
type MyRecord = { x :: Number, y :: Number }
data Foo = Foo MyArray -- fine
MyString -- fine
MyNumber -- fine
MyInt -- fine
MyBoolean -- fine
MyProduct -- fine
MyRecord -- FAIL
derive instance fooGeneric :: Generic Foofails with
No instance found for Data.Generic.Generic MyModule.MyRecord<>
Activity
garyb commentedon Aug 31, 2015
I assume
MyRecordwas calledPointwhen you ran the compiler?zudov commentedon Aug 31, 2015
@garyb Yes, sorry. Fixed now.
garyb commentedon Aug 31, 2015
Just checking :)
Does it work when
MyRecordis not a synonym in theFooconstructor? I don't know whether we can derive generics for records...zudov commentedon Aug 31, 2015
Yes it does. Records are a part of our
Genericdata type https://github.com/purescript/purescript-generics/blob/master/src/Data/Generic.purs#L34garyb commentedon Aug 31, 2015
Cool, it's just "type synonyms again" then. I really need to get around to trying my idea for handling them...
zudov commentedon Aug 31, 2015
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 synonympaf31 commentedon Oct 28, 2015
The error is now
paf31 commentedon Nov 14, 2015
This happens because type synonym desugaring happens after derived instances get elaborated.
8 remaining items
gbaz commentedon Apr 26, 2016
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.
paf31 commentedon Apr 27, 2016
@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.gbaz commentedon Apr 27, 2016
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 :-)
jqyu commentedon Sep 28, 2016
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.
garyb commentedon Sep 28, 2016
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. 😄
jqyu commentedon Sep 28, 2016
Ah, no wonder I couldn't find the type synonym code, it's in the typechecking pass not the desguaring pass. Thanks for clarifying!