
I'd pretty much just assumed that a class associated type with a default
definition was modeling the same thing as a default signature, just without
the 'default' keyword
-Edward
On Wed, Mar 9, 2016 at 7:39 AM, Simon Peyton Jones
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.4 http://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
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 https://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