Ryan The discussion was in this thread [1], but went off list at some point.
The relevant part of the off-list discussion, quoting Philip Hölzenspies is "UndecidableInstances comes from having to constrain the type that the PostTcType-family projects to, besides the arguments of the AST-types; instance (Data (PostTcType id), Data id) => Data (HsIPBinds id) where ... If we could derive that from the definition of PostTcType (and I don't see why we couldn't from a closed family; not sure about the open ones), we would only need to constrain "id" and, thus, we could actually just use "deriving". Of the diff, btw, I don't get why PendingRnSplice is suddenly parameterised... Thoughts? Ph." and SimonPJ responded " Why do we need UndecidableInstances? I still (currently) think we can use open type families perfectly well. Why won’t that work? (Could switch to closed after GHC’s bootstrap caught up.) Simon " So basically there is a mention that it may be possible. Alan [1] https://mail.haskell.org/pipermail/ghc-devs/2014-July/005808.html On Wed, May 25, 2016 at 9:09 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote: > > I recall there was some discussion when the PostRn/PostTc stuff went in > around the closed type family solution being better, and I thought it was > that the Data instances would be more easy to define. > > Do you happen to know where this discussion can be found online? To be > honest, I'm not sure whether closed vs. open type families is even a > relevant distinction in this case. Regardless of where NameOrRdrName > is open or closed, the following code won't compile: > > data Foo a = Foo (NameOrRdrName a) deriving Data > > And that's simply because GHC hasn't enough information to know > whether Foo a will always resolve to something that's a Data instance. > Even if NameOrRdrName is closed, someone could still use types like > NameOrRdrName Char. > > If NameOrRdrName were somehow made to be injective, then it'd be a > different story. But I doubt that such a thing is possible in this > case (based on the definition of NameOrRdrName you gave), so I think > we'll just have to settle for turning on UndecidableInstances and > writing code that we know won't throw the typechecker into a loop. > > Ryan S. > > On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman > <alan.z...@gmail.com> wrote: > > Ryan / Simon, thanks. > > > > I have been working it in the way the PostRn stuff was done, but then it > > struck me there may be an easier way. > > > > I recall there was some discussion when the PostRn/PostTc stuff went in > > around the closed type family solution being better, and I thought it was > > that the Data instances would be more easy to define. > > > > And I also seem to recall that the closed type families should be able to > > get rid of the UndecidableInstances pragma, but I do not recall the > details. > > > > We are now able to use closed type families in GHC source, as it is > > supported from GHC 7.8 onwards > > > > Regards > > Alan > > > > > > On Wed, May 25, 2016 at 8:42 PM, Ryan Scott <ryan.gl.sc...@gmail.com> > wrote: > >> > >> Simon is right, you cannot use a type family as an instance head. But > why > >> do you need to? Typically, if you're deriving a Data instance that > involves > >> type families, the type families would be inside another data type. A > >> real-world example is HsBindLR [1]: > >> > >> data HsBindLR idL idR > >> = FunBind { > >> ... > >> bind_fvs :: PostRn idL NameSet, > >> ... > >> } | ... > >> > >> where PostRn is a type family [2]. Now, you can't simply derive Data for > >> HsBindLR, because GHC has no way of knowing what PostRn will evaluate > to! > >> But you can use standalone deriving to get what you want: > >> > >> deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR > >> idL idR) > >> > >> And in fact, this is what GHC does [3], using a convenient type synonyms > >> for the long, sprawling context you need [4]. > >> > >> So in your example, while you can't directly create a Data instance for > >> NameOrRdrName itself, you can quite easily create Data instances for > >> anything that might use NameOrRdrName. Does that work for your use > cases? > >> > >> Ryan S. > >> ----- > >> [1] > >> > http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111 > >> [2] > >> > http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47 > >> [3] > >> > http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264 > >> [4] > >> > http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102 > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs