Re: Optimizing "counting" GADTs

Excerpts from David Feuer's message of 2016-06-18 19:47:54 -0700: > I would think the provided equalities could be constructed in a view > pattern, possibly using unsafeCoerce. Yes, this does work. {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE

Re: Optimizing "counting" GADTs

I would think the provided equalities could be constructed in a view pattern, possibly using unsafeCoerce. Dictionaries are harder to come by, but reflection might be an option. My two biggest gripes about pattern synonyms are really 1. The constraints for "constructor" application are forced to

Re: Optimizing "counting" GADTs

David, Carter, It would be nice to use pattern synonyms for this task but they do not work quite as expected as they don't cause type refinement. I quickly assembled this note to explain why. http://mpickering.github.io/posts/2016-06-18-why-no-refinement.html Matt On Fri, May 27, 2016 at 4:50

Re: Inferring instance constraints with DeriveAnyClass

On Sat, Jun 18, 2016 at 12:51 PM, Simon Peyton Jones wrote: > > > But no need to look at the data type’s constructors, as deriving(Functor) > does. > Yes, that's right. I believe we've used the "derive Functor" strategy for inferring constraints simply because all

RE: Inferring instance constraints with DeriveAnyClass

Yes, but none of that has anything to do with a walk over the data type, as deriving(Functor) does! You are right that what we need is the result of simplifying the instantiated constraint (Generic [a], GC (Rep [a])) Simplify that constraint (simplifyDeriv does that),