If and when that feature lands would it be possible to use it to bypass a current limitation in class associated types? Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind. e.g. I have some classes which are technically polykinded but where 90% of the instances instantiate that kind as *. The status quo prevents me from putting in a type default that would only be valid when the kind argument is *. -Edward On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg wrote:

On Mar 8, 2016, at 7:17 PM, Evan Austin wrote:

The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families:

https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequa...

Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?

No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.

Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.

Thanks! Richard

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I see no good reason for this restriction -- I think that we should just remove the restriction instead of cooking up a workaround. Have you brought this up before? Perhaps make a ticket. Richard On Mar 8, 2016, at 8:24 PM, Edward Kmett wrote:

If and when that feature lands would it be possible to use it to bypass a current limitation in class associated types?

Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind.

e.g. I have some classes which are technically polykinded but where 90% of the instances instantiate that kind as *. The status quo prevents me from putting in a type default that would only be valid when the kind argument is *.

-Edward

On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg wrote:

On Mar 8, 2016, at 7:17 PM, Evan Austin wrote:

...

The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequa...

Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?

No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.

Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.

Thanks! Richard

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind. This is the same situation as holds for default class methods. BUT for the latter we invented default method signatures –XdefaultSignatures (user manual Section 9.8.1.4http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#class...), which can be more restrictive than the signature implied by the method signature of the class. Maybe we can do the same for default declarations for associated types? Would someone like to open a ticket and tell the story? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 March 2016 01:32 To: Edward Kmett Cc: ghc-devs Subject: Re: Constrained Type Families? I see no good reason for this restriction -- I think that we should just remove the restriction instead of cooking up a workaround. Have you brought this up before? Perhaps make a ticket. Richard On Mar 8, 2016, at 8:24 PM, Edward Kmett mailto:ekmett@gmail.com> wrote: If and when that feature lands would it be possible to use it to bypass a current limitation in class associated types? Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind. e.g. I have some classes which are technically polykinded but where 90% of the instances instantiate that kind as *. The status quo prevents me from putting in a type default that would only be valid when the kind argument is *. -Edward On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg mailto:eir@cis.upenn.edu> wrote: On Mar 8, 2016, at 7:17 PM, Evan Austin mailto:e.c.austin@gmail.com> wrote: The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequa... Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere? No, it didn't make it. The motivating test case seemed contrived and so we punted on this one. Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond. Thanks! Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devshttps://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c548849e42ffa4b50f01208d347ba9228%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QKme1PQXRrwAkxAODUaPscdFk7ovwwwxHAFhDxpBXb8%3d

I think it's more like the non-keyworded default definitions of class methods, for the same reasons; the default definition has to potentially be valid for all instances of the class​. It's the difference between class Applicative m => Monad m where return :: a -> m a return = pure -- always valid, but can be overridden in instance declarations and class Fuctor f => Applicative f where (<*>) :: f (a -> b) -> f a -> f b default (<*>) :: Monad f => f (a -> b) -> f a -> f b (<*>) = ap -- only valid if matches the type signature above

I unfortunately don’t have the exact code I was working on in front of me, but I was playing around with the -XTypeInType extension to see if I could use it to implement some notion of sub-kinding to start doing “Data Types a la Carte” style things at the type level. Constrained type families seemed like the most natural way to “promote” those concepts, but maybe there’s a more obvious way I’m missing. I’d be happy to send you a follow up email tomorrow when I’m back at the office if you think this would be a good motivating use case for the feature. V/r, -Evan

On Mar 8, 2016, at 8:21 PM, Richard Eisenberg wrote:

On Mar 8, 2016, at 7:17 PM, Evan Austin mailto:e.c.austin@gmail.com> wrote:

...

The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequa... https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequa...

Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?

No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.

Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.

Thanks! Richard