Allow Newtype deriving for newtypes that use type synonyms #2416

Activity

1. garyb

   added

   type: enhancement

   codegen

   on Nov 3, 2016
2. garyb

   added this to the 1.0 milestone on Nov 3, 2016
3. paf31 commented on Nov 7, 2016

   

   paf31

   on Nov 7, 2016

   Contributor

   More actions

   This is the same as the corresponding Generic deriving issue, right?
4. garyb commented on Nov 7, 2016

   

   garyb

   on Nov 7, 2016

   MemberAuthor

   More actions

   I don't know if it is exactly, the error is that you're not allowed to declare instances for type synonyms... is that the same reason it fails there?
5. paf31 commented on Nov 7, 2016

   

   paf31

   on Nov 7, 2016

   Contributor

   More actions

   Oh I see, then no, it's different.
6. joshuahhh commented on Dec 13, 2016

   

   joshuahhh

   on Dec 13, 2016

   Last edited by joshuahhh

   More actions

   [EDIT: This bug is actually an instance of #2481, a different issue.]

   I think I've run into this bug. My minimal reproduction is

   type MyString = String
   newtype WrappedString = WrappedString MyString
   derive newtype instance semigroupWrappedString :: Semigroup WrappedString
   

   which produces the error

       No type class instance was found for
   
         Data.Semigroup.Semigroup MyString
   
   
     while checking that expression #dict Semigroup
       has type { append :: WrappedString -> WrappedString -> WrappedString
                }
     in value declaration semigroupWrappedString
   

   even though

   newtype WrappedString = WrappedString String
   derive newtype instance semigroupWrappedString :: Semigroup WrappedString
   

   compiles without error.

   Am I covered by this issue, or is this something different?

   (Thanks!)
7. joshuahhh commented on Dec 13, 2016

   

   joshuahhh

   on Dec 13, 2016

   More actions

   OK – I just ran into a second, different bug, which actually uses capital-N Newtype deriving. Minimal reproduction is

   type MyString = String
   newtype WrappedString = WrappedString MyString
   derive instance newtypeWrappedString :: Newtype WrappedString _
   

   which produces the error

       Type class instances for type synonyms are disallowed.
   
     in type class instance
   
       Data.Newtype.Newtype WrappedString
                            MyString
   

   even though

   newtype WrappedString = WrappedString String
   derive instance newtypeWrappedString :: Newtype WrappedString _
   

   compiles without error.

   I'm guessing this is the bug referred to by this issue, and the bug I posted yesterday is a different one. Is that right?

   (Thanks even more!)
8. garyb commented on Dec 13, 2016

   

   garyb

   on Dec 13, 2016

   MemberAuthor

   More actions

   The second one is the case that this is for, yep :)

   The first one might actually be yet another issue though! As it's for lowercase-n newtype deriving.
9. LiamGoodacre commented on Dec 13, 2016

   

   LiamGoodacre

   on Dec 13, 2016

   Member

   More actions

   Aren't these all the same issue based around when we replace type synonyms?
10. garyb commented on Dec 13, 2016

    

    garyb

    on Dec 13, 2016

    MemberAuthor

    More actions

    They fall into that general category yeah. But on the other hand I think we shouldn't normally allow instances for type synonyms, to avoid confusion. So we want them to be desugared for deriving, but not for a hand written instance.
11. adamw commented on Dec 17, 2016

    

    adamw

    on Dec 17, 2016

    More actions

    Just hit the same thing (https://groups.google.com/forum/#!topic/purescript/HG7uiRChNhE). I suppose the same argument as why instances for functionally-dependent record types are allowed would apply to type synonyms?
12. paf31

    closed this as completedin #2516on Jan 1, 2017