instances for closed type families

Wed May 25 19:26:54 UTC 2016

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.scott at 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.zimm at 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.scott at 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 at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160525/d88d230c/attachment-0001.html>