Re: More Higher-Kinded Typeclass Instances
Yeah, that is a lot of instances (especially all 62 types of tuples). I think you're right that it makes more sense to do this with an extension to the deriving mechanism, especially since even if I wrote them now, it would probably make sense to redo them with a deriving clause later. At the moment, I don't really need any of them but Proxy, which is already done, some I'm happy to wait this one out. Thanks. -Andrew Martin On Tue, Mar 29, 2016 at 9:10 AM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote: > Well, if we're going to be thorough, we need to also get: > > * Tuple types > * All (* -> *)-kinded datatypes in Data.Monoid > * Data.Type.Equality.(:~:) and Data.Type.Coercion.Coercion > * Fixed > * ST, STRef > * Chan > * MVar, IORef, TVar > > A lot of these types' existing Eq/Ord/Read/Show instances are > currently derived, however, and you might find it incredibly tedious > to type all them out by hand (not to discourage you from going for it > if you need them now, but we warned). Given that the window for new > 8.0 features is almost closed, perhaps it would be better to wait > until I've implemented an extension which derives these classes > automatically? > > (I wanted to get such an extension implemented sooner, but time ran > out. I'll try to find some time to write a wiki page proposing a > design so that we can get the ball rolling soon after the 8.0 final > release.) > > Ryan S. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- -Andrew Thaddeus Martin ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More Higher-Kinded Typeclass Instances
Earlier today, I wrote Proxy's instances for Eq1, Ord1, Show1, and Read1 and they were accepted for base-4.9.0.0. All in all, the process went way more smoothly than I expected, and so I started thinking about what other types from base are currently missing these instances, and this is what I've come up with: - Down (from Data.Ord) - Complex (from Data.Complex) - Ratio (from Data.Ratio) - First, Last (from Data.Monoid) - ZipList (from Control.Applicative) - Ptr, FunPtr (from Foreign.Ptr, only Eq1 and Ord1) - StablePtr (from Foreign.StablePtr, only Eq1) - K1, U1, Par1, Rec1, etc. (from GHC.Generics) - StableName (from System.Mem.StableName, only Eq1, requested here: http://hub.darcs.net/ross/transformers/issue/17) Since most of these are trivial to implement, I'd like to try to get them in for GHC-8.0. Does anyone have in mind any other data types that would benefit from these? -- -Andrew Thaddeus Martin ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
VisibleTypeApplication and AllowAmbiguousTypes
I'm posting this because Richard said it would be the best place to raise this issue. I know it's a little bit late in the GHC8 development process, but I would like to get the idea out there. To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn on AllowAmbiguousTypes. I think that a better behavior for most end users would be to not have this happen. I need AllowAmbiguousTypes turned on in modules where I want to declare functions that are presently uncalled. At a call site though, I only need VisibleTypeApplication, not both extensions. The only reason I bring this up is because having AllowAmbiguousTypes on is usually bad. It makes it possible to write functions that don't work, but you don't learn that until you get to the call site. If I write libraries that require VisibleTypeAppliaction to call certain functions, I don't want users accidentally ending up turning on AllowAmbiguousTypes in their own code. -- -Andrew Thaddeus Martin ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
