Great stuff guys! I updated the post with your code.
David, you raise two valid points. I don't have anything else to add
to them at this time but it is stuff that I think about.
On Sat, Jun 18, 2016 at 8:21 PM, Edward Z. Yang wrote:
> Excerpts from David Feuer's message of 2016-06-18 19:47:54 -
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 PatternSynonyms
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 b
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
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 generic functions (over Generi
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), including
I still don't think you can do it just from the default method's type. A
typical case is the following:
class C a where
op :: a -> Int
default op :: (Generic a, GC (Rep a)) => a -> Int
When giving an instance C [a], you might well find out that you need C a
=>, but this is not something
you c
