From adam at bergmark.nl Tue Dec 10 14:11:49 2013 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 10 Dec 2013 15:11:49 +0100 Subject: [Hs-Generics] Bumping regular-extras upper bound on QuickCheck Message-ID: Hi, regular-extras doesn't allow QuickCheck 2.5 and 2.6, could someone bump it, please? I verified that it compiles with 2.6. Regards, Adam Bergmark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpm at cs.uu.nl Tue Dec 10 16:42:15 2013 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue, 10 Dec 2013 16:42:15 +0000 Subject: [Hs-Generics] Bumping regular-extras upper bound on QuickCheck In-Reply-To: References: Message-ID: Done: http://hackage.haskell.org/package/regular-extras-0.2.3 Cheers, Pedro On Tue, Dec 10, 2013 at 2:11 PM, Adam Bergmark wrote: > Hi, > > regular-extras doesn't allow QuickCheck 2.5 and 2.6, could someone bump > it, please? I verified that it compiles with 2.6. > > Regards, > Adam Bergmark > > > _______________________________________________ > Generics mailing list > Generics at haskell.org > http://www.haskell.org/mailman/listinfo/generics > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue Dec 10 20:31:14 2013 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 10 Dec 2013 21:31:14 +0100 Subject: [Hs-Generics] Bumping regular-extras upper bound on QuickCheck In-Reply-To: References: Message-ID: Oh that was quick, thank you Pedro! - Adam On Tue, Dec 10, 2013 at 5:42 PM, Jos? Pedro Magalh?es wrote: > Done: http://hackage.haskell.org/package/regular-extras-0.2.3 > > > Cheers, > Pedro > > > On Tue, Dec 10, 2013 at 2:11 PM, Adam Bergmark wrote: > >> Hi, >> >> regular-extras doesn't allow QuickCheck 2.5 and 2.6, could someone bump >> it, please? I verified that it compiles with 2.6. >> >> Regards, >> Adam Bergmark >> >> >> _______________________________________________ >> Generics mailing list >> Generics at haskell.org >> http://www.haskell.org/mailman/listinfo/generics >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Thu Dec 12 23:04:00 2013 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 13 Dec 2013 12:04:00 +1300 Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection Message-ID: <52aa40e0.1c7.2f3f.8066@clear.net.nz> (Jeremy's announcements and the occasional spam is meagre fare. I'm showing this list some love ;-) I asked a question on the cafe, starting here: http://www.haskell.org/pipermail/haskell-cafe/2013-October/111133.html and got some very helpful answers. Thank you. Only after that did I realise that I'd asked the wrong questions. I now have something that works (using Generics), but the types are scary (especially the instance constraints). John did warn me: "The types look bigger [than Data/Typeable], but the functions are probably simpler to grok. And once you start using generics the types get much easier to read." I'm looking for a little clarification of what value of "easier" I should expect. What am I trying to do? * As input have a tuple of newtypes: someTuple = (FooD 7, FooD2 True, FooD3 'X') (Think of it as a row in a databse table.) * As output I want a list of tuples of newtypes, each tuple describing an element: [(AttrAttr FooT. AttrBasedOn Int), (AttrAttr FooT2, AttrBasedOn Bool), (AttrAttr FooT3, AttrBasedOn Char)] (Think of this as the column specs for the database table. AttrAttr and AttrBasedOn are newtypes.) * The input tuple could have zero, one, two or more elements. * The elements could be newtypes or data with a single constructor and single based-on type. * Note that the tuples of the output also match this pattern. So I want to recurse inside the constructors, but only to a controlled depth. At first, I tried doing this with Data's gunfold. But in: newtype BarT = BarD alpha deriving (Data, ...) `alpha` is required to be in Data (and so through all its sub-constructors), and that's too stringent a constraint on the users of my package. Also some (base/abstract) types aren't in Data, especially TypeRep: newtype AttrBasedOn = AttrBasedOn TypeRep deriving (Data, ...) Then I turned to deriving Generic, which only requires Typeable of the based-on types. I've tried to follow the pattern in Generic.Deriving.Base and Generic.Deriving.ConNames. (Those are great examples! Pity that they don't seem to be pointed to from the wiki.) But I don't want to descend uniformly through the structures. So is the following appropriate?: {-# LANGUAGE KindSignatures, DataKinds, MultiParamTypeClasses, TypeFamilies, RankNTypes, FlexibleInstances, UndecidableInstances, PolyKinds, FlexibleContexts, FunctionalDependencies, OverlappingInstances, ScopedTypeVariables, NoMonomorphismRestriction, TupleSections, TypeOperators, DeriveDataTypeable, DeriveGeneric, DefaultSignatures #-} module TupleAttrGeneric where import Data.Typeable import GHC.Generics -- wrapper function tupToAttribs :: (Generic a, Rep a ~ (M1 D t1 (M1 C t3 t4)), BodyToAttribs t4 ) => a -> [(AttrAttrib, AttrBasedOn)] tupToAttribs x = map (\(xa, xd, xb) -> (AttrAttrib xa, AttrBasedOn xb)) $ bodyToAttribs body where (M1 (M1 body)) = from x -- worker class/method class BodyToAttribs f where bodyToAttribs :: f a -> [(TypeRep, String, TypeRep)] -- instance for empty tuple `()` instance BodyToAttribs U1 where bodyToAttribs _ = [] -- instance for a newtype element instance (Typeable t1, Generic t1, Rep t1 ~ (M1 D t1' (M1 C t3' (M1 S t4' (K1 t5' t6')))), Constructor t3', Typeable t6' ) => BodyToAttribs (M1 S t (K1 r t1)) where bodyToAttribs (M1 (K1 x)) = [(typeOf x, conName from2, typeOf xb)] where (M1 from2) = from x (M1 (M1 (K1 xb))) = undefined `asTypeOf` from2 -- instance for the products of elements instance (BodyToAttribs f, BodyToAttribs g) => BodyToAttribs (f :*: g) where bodyToAttribs (_ :: (f :*: g) a) = bodyToAttribs (undefined :: f a) ++ bodyToAttribs (undefined :: g a) Questions: * These pile-ups of types (M1 D ... (M1 C ... (...))) seem hairy. Is that the best way to control the depth of recursion? * The suggestion from John Lato (see gist from his message http://www.haskell.org/pipermail/haskell-cafe/2013-October/111139.html ) uses a different style for the class types, avoiding the mysterious unbound typevar class GConName a where getConName :: a -> String -- cp: class ... f where ... :: f a -> String Are there places where one or other is more suitable? (I did try John's style at first, but the constraints got uglier.) * The explicit data constructors in the pattern matching are a bit temperamental w.r.t. undefined values. (Specifically, my instance for (:*:) was crashing.) Should I use dummy `_` patterns throughout? (Then the type annotations are monsters!) Thank you AntC From jpm at cs.uu.nl Tue Dec 17 13:52:10 2013 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue, 17 Dec 2013 14:52:10 +0100 Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection In-Reply-To: <52aa40e0.1c7.2f3f.8066@clear.net.nz> References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: Hi AntC, On Fri, Dec 13, 2013 at 12:04 AM, Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > > > Questions: > * These pile-ups of types (M1 D ... (M1 C ... (...))) seem > hairy. > Is that the best way to control the depth of recursion? > I think I would define a generic function |typeOfRecord :: a -> TypeRep|, which expects a newtype |a| and returns the |TypeRep| of its argument. Then I'd use that function instead of your call to |from| expecting to match on |M1 (M1 (M1 (K1 x)))|. I'd define that function as a regular generic consumer (like generic show), and give runtime errors for unexpected values (such as sums, or products, as we don't expect those in newtypes). The advantage of the "hairy types" you have right now is that these would be (obscure) compile-time errors. > > * The suggestion from John Lato (see gist from his message > http://www.haskell.org/pipermail/haskell-cafe/2013-October/111139.html > ) > uses a different style for the class types, > avoiding the mysterious unbound typevar > > class GConName a where getConName :: a -> String > -- cp: class ... f where ... :: f a -> String > > Are there places where one or other is more suitable? > (I did try John's style at first, but the constraints got > uglier.) > Perhaps this is more or less what I suggest above? > > * The explicit data constructors in the pattern matching > are a bit temperamental w.r.t. undefined values. > (Specifically, my instance for (:*:) was crashing.) > Should I use dummy `_` patterns throughout? > (Then the type annotations are monsters!) > I don't see why you need |undefined| at all. Unless you are calling |tupToAttribs| with |undefined|; is that the case? Else, your generic function can just pattern-match on |a :*: b| on the product case, for example. Cheers, Pedro > > > Thank you > AntC > > _______________________________________________ > Generics mailing list > Generics at haskell.org > http://www.haskell.org/mailman/listinfo/generics > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Dec 17 22:54:42 2013 From: anthony_clayden at clear.net.nz (AntC) Date: Tue, 17 Dec 2013 22:54:42 +0000 (UTC) Subject: [Hs-Generics] =?utf-8?q?Request_for_code_review=3A_Generics_for?= =?utf-8?q?=09tuple/newtype_introspection?= References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: > Jos? Pedro Magalh?es cs.uu.nl> writes: Thanks Pedro, > > On Fri, Dec 13, 2013 at 12:04 AM, Anthony Clayden wrote: > > > > Questions: > > * These pile-ups of types (M1 D ... (M1 C ... (...))) seem > > hairy. > > ? Is that the best way to control the depth of recursion? > > > > ... The advantage of the "hairy types" you have right now > is that these would be (obscure) compile-time errors. > OK. For this functionality, I prefer compile-time fail to run-time. > > > > * The explicit data constructors in the pattern matching > > are a bit temperamental w.r.t. undefined values. ... > > I don't see why you need |undefined| at all. Unless you are > calling |tupToAttribs| with |undefined|; is that the case? Yes: a relation (aka database table) could be empty, in which case I have only the type of its tuple, no value. (And actually, for a bit of background, this was the main point of the exercise: I am in debate on another forum about whether a relation needs a "heading" -- whose main purpose seems to be to deliver the attributes and their based-on types even when the relation (body) is empty. (The counter-argument is along the lines: how can a non-existent value have a type?) I'm claiming that you don't need a "heading", because you can reify the schema from the tuple type -- even if you don't have a tuple. And I now have a function to prove it, thank you Generics!) Cheers AntC From nicolas.frisby at gmail.com Wed Dec 18 15:26:05 2013 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Wed, 18 Dec 2013 09:26:05 -0600 Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection In-Reply-To: <52aa40e0.1c7.2f3f.8066@clear.net.nz> References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: Disclaimer: I didn't read all of the previous emails. Does this do what you need? http://lpaste.net/97165 I'm on GHC 7.4 at the moment, but I think this will work with later versions. HTH. On Thu, Dec 12, 2013 at 5:04 PM, Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > (Jeremy's announcements and the occasional spam is meagre > fare. I'm showing this list some love ;-) > > I asked a question on the cafe, starting here: > http://www.haskell.org/pipermail/haskell-cafe/2013-October/111133.html > and got some very helpful answers. Thank you. > Only after that did I realise that I'd asked the wrong > questions. > > I now have something that works (using Generics), > but the types are scary (especially the instance > constraints). > > John did warn me: > "The types look bigger [than Data/Typeable], but the > functions are probably simpler to grok. And once you start > using generics the types get much easier to read." > > I'm looking for a little clarification of what value of > "easier" I should expect. > > > What am I trying to do? > * As input have a tuple of newtypes: > > someTuple = (FooD 7, FooD2 True, FooD3 'X') > > (Think of it as a row in a databse table.) > > * As output I want a list of tuples of newtypes, > each tuple describing an element: > > [(AttrAttr FooT. AttrBasedOn Int), > (AttrAttr FooT2, AttrBasedOn Bool), > (AttrAttr FooT3, AttrBasedOn Char)] > > (Think of this as the column specs for the database table. > AttrAttr and AttrBasedOn are newtypes.) > > * The input tuple could have zero, one, two or more > elements. > * The elements could be newtypes > or data with a single constructor and single based-on > type. > * Note that the tuples of the output also match this > pattern. > > > So I want to recurse inside the constructors, > but only to a controlled depth. > > At first, I tried doing this with Data's gunfold. But in: > > newtype BarT = BarD alpha deriving (Data, ...) > > `alpha` is required to be in Data > (and so through all its sub-constructors), > and that's too stringent a constraint on the users of my > package. > Also some (base/abstract) types aren't in Data, especially > TypeRep: > > newtype AttrBasedOn = AttrBasedOn TypeRep > deriving (Data, ...) > > Then I turned to deriving Generic, > which only requires Typeable of the based-on types. > > I've tried to follow the pattern in Generic.Deriving.Base > and Generic.Deriving.ConNames. > (Those are great examples! Pity that they don't seem to be > pointed to from the wiki.) > > But I don't want to descend uniformly through the > structures. > So is the following appropriate?: > > {-# LANGUAGE KindSignatures, DataKinds, > MultiParamTypeClasses, > TypeFamilies, RankNTypes, FlexibleInstances, > UndecidableInstances, PolyKinds, > FlexibleContexts, > FunctionalDependencies, OverlappingInstances, > ScopedTypeVariables, NoMonomorphismRestriction, > TupleSections, TypeOperators, > DeriveDataTypeable, DeriveGeneric, > DefaultSignatures #-} > > module TupleAttrGeneric where > > import Data.Typeable > import GHC.Generics > > -- wrapper function > > tupToAttribs :: (Generic a, > Rep a ~ (M1 D t1 (M1 C t3 t4)), > BodyToAttribs t4 ) > => a -> [(AttrAttrib, AttrBasedOn)] > tupToAttribs x = map (\(xa, xd, xb) -> (AttrAttrib xa, > AttrBasedOn xb)) > $ bodyToAttribs body > where (M1 (M1 body)) = from x > > -- worker class/method > > class BodyToAttribs f where > bodyToAttribs :: f a -> [(TypeRep, String, TypeRep)] > > -- instance for empty tuple `()` > instance BodyToAttribs U1 where > bodyToAttribs _ = [] > > -- instance for a newtype element > instance (Typeable t1, Generic t1, > Rep t1 ~ (M1 D t1' (M1 C t3' (M1 S t4' (K1 t5' > t6')))), > Constructor t3', Typeable t6' ) > => BodyToAttribs (M1 S t (K1 r t1)) where > bodyToAttribs (M1 (K1 x)) = [(typeOf x, conName > from2, typeOf xb)] > where (M1 from2) = from x > (M1 (M1 (K1 xb))) = undefined `asTypeOf` > from2 > > -- instance for the products of elements > instance (BodyToAttribs f, BodyToAttribs g) > => BodyToAttribs (f :*: g) where > bodyToAttribs (_ :: (f :*: g) a) = bodyToAttribs > (undefined :: f a) > ++ bodyToAttribs > (undefined :: g a) > > > Questions: > * These pile-ups of types (M1 D ... (M1 C ... (...))) seem > hairy. > Is that the best way to control the depth of recursion? > > * The suggestion from John Lato (see gist from his message > http://www.haskell.org/pipermail/haskell-cafe/2013-October/111139.html > ) > uses a different style for the class types, > avoiding the mysterious unbound typevar > > class GConName a where getConName :: a -> String > -- cp: class ... f where ... :: f a -> String > > Are there places where one or other is more suitable? > (I did try John's style at first, but the constraints got > uglier.) > > * The explicit data constructors in the pattern matching > are a bit temperamental w.r.t. undefined values. > (Specifically, my instance for (:*:) was crashing.) > Should I use dummy `_` patterns throughout? > (Then the type annotations are monsters!) > > > Thank you > AntC > > _______________________________________________ > Generics mailing list > Generics at haskell.org > http://www.haskell.org/mailman/listinfo/generics > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Fri Dec 20 07:44:23 2013 From: anthony_clayden at clear.net.nz (AntC) Date: Fri, 20 Dec 2013 07:44:23 +0000 (UTC) Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: > Nicolas Frisby gmail.com> writes: > > Disclaimer: I didn't read all of the previous emails. > Does this do what you need? > > I'm on GHC 7.4 at the moment, but I think this will work with later versions. > > HTH. > Thank you Nicolas (and yes it works on GHC 7.6). It does look 'cleaner' than the version I posted. But I still see plenty of pileups of (type and data) constructors. However, perhaps it looks 'cleaner' because it doesn't work in the corner cases you could have seen discussed in the previous emails? * There's no instance for the unit tuple `toAttrs ()` -- that's easily fixed: instance ToAttrsR U1 where toAttrsR _ = [] * It crashes '*** Exception: Prelude.undefined' when toAttrs' argument is undefined. I tried a quick fix to the (:*:) instance, similar to my version, but that wasn't enough. * (And a minor point: I wanted to be able to go feed toAttrs' output tuple into itself. -- that's fixable easily enough. My version for a bonus also grabbed the newtype's data constructor. -- that's also fixable, I think.) AntC From nicolas.frisby at gmail.com Fri Dec 20 19:25:02 2013 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Fri, 20 Dec 2013 13:25:02 -0600 Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection In-Reply-To: References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: For the "minor point", you'd like for example the following equivalence (modulo decomposing the Attr type)? toAttrs (FooD 7,BarD True,BazD 'X') == (Attr FooT Int,Attr BarT Bool,Attr BazT Char) If I understood correctly, take a look at the most recent edit of http://lpaste.net/97165 The code gets hairier, but you can now say > example = let (a,_,_) = toAttrs (FooD 7,BarD True,BazD 'X') in a If you do not specify the "container type" of the result (the pattern suffices in my example), there will be a type-error. Loosening that requirement would require a mapping that includes f a b goes to f Attr Attr where for example f = (,) f a b c goes to f Attr Attr Attr where for example f = (,,) f a b c d goes to f Attr Attr Attr Attr where for example f = (,,,) and so on But I don't know how to specify such a general one, since all (instances of) tuple types are distinct types that are not formally related to one another within the GHC type system. So: 1) Have I understood your specification correctly? 2) Other experts: is there safe trickery to generally specify this map? I think it might actually be doable in 7.4, but as far as I know, that was accidental generally-unsound functionality that was removed in 7.6+. HTH also. On Fri, Dec 20, 2013 at 1:44 AM, AntC wrote: > > Nicolas Frisby gmail.com> writes: > > > > Disclaimer: I didn't read all of the previous emails. > > Does this do what you need? > > > > I'm on GHC 7.4 at the moment, but I think this will work with later > versions. > > > > HTH. > > > > Thank you Nicolas (and yes it works on GHC 7.6). > > It does look 'cleaner' than the version I posted. But I still see plenty of > pileups of (type and data) constructors. > > However, perhaps it looks 'cleaner' because it doesn't work in the corner > cases you could have seen discussed in the previous emails? > > * There's no instance for the unit tuple `toAttrs ()` > -- that's easily fixed: > > instance ToAttrsR U1 where > toAttrsR _ = [] > > * It crashes '*** Exception: Prelude.undefined' > when toAttrs' argument is undefined. > I tried a quick fix to the (:*:) instance, similar to my version, > but that wasn't enough. > > * (And a minor point: I wanted to be able to go feed toAttrs' output > tuple into itself. > -- that's fixable easily enough. > My version for a bonus also grabbed the newtype's data constructor. > -- that's also fixable, I think.) > > AntC > > > > > _______________________________________________ > Generics mailing list > Generics at haskell.org > http://www.haskell.org/mailman/listinfo/generics > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sat Dec 21 08:21:36 2013 From: anthony_clayden at clear.net.nz (AntC) Date: Sat, 21 Dec 2013 08:21:36 +0000 (UTC) Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: > Nicolas Frisby gmail.com> writes: > For the "minor point", you'd like for example the following equivalence > (modulo decomposing the Attr type)??... Thanks Nicolas No, I do want a list result. it's a different list element I want. So I can go: toAttrs (undefined `asTypeOf` head (toAttrs (FooD 7, ...))) (Compare: typeOf $ typeOf ... The applicable Relational Theory here is that any data structure can be represented as a Set (List) of tuples, each tuple element being a Name with value of some type. And since that applies for _any_ data structure, it must also apply for the structure of structures.) So instead of returning Attr: data Attr = Attr TypeRep TypeRep deriving (Show) Return a tuple of: newtype AttrAttrib = AttrAttrib TypeRep deriving (Show, Typeable, Generic) newtype AttrBasedOn = AttrBasedOn TypeRep deriving (Show, Typeable, Generic) toAttrs :: (Generic product,ToAttrsR (Rep product)) => product -> [(AttrAttrib, AttrBasedOn)] toAttrs = map (\(Attr a b) -> (AttrAttrib a, AttrBasedOn b)) . toAttrsR . from > > So: > > 1) Have I understood your specification correctly? > No, but I've learnt something more about the power of Generics. > 2) Other experts: is there safe trickery to generally specify this map? > I think it might actually be doable in 7.4, but as far as I know, > that was accidental generally-unsound functionality that was removed in 7.6+. > From nicolas.frisby at gmail.com Sat Dec 21 15:54:14 2013 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Sat, 21 Dec 2013 09:54:14 -0600 Subject: [Hs-Generics] Request for code review: Generics for tuple/newtype introspection In-Reply-To: References: <52aa40e0.1c7.2f3f.8066@clear.net.nz> Message-ID: Ah. I took "feed toAttrs' output tuple into itself" too literally. Good luck to you. On Sat, Dec 21, 2013 at 2:21 AM, AntC wrote: > > Nicolas Frisby gmail.com> writes: > > > For the "minor point", you'd like for example the following equivalence > > (modulo decomposing the Attr type)? ... > > Thanks Nicolas > No, I do want a list result. it's a different list element I want. So I can > go: > > toAttrs (undefined `asTypeOf` head (toAttrs (FooD 7, ...))) > > (Compare: typeOf $ typeOf ... > The applicable Relational Theory here is that any data structure > can be represented as a Set (List) of tuples, > each tuple element being a Name with value of some type. > And since that applies for _any_ data structure, > it must also apply for the structure of structures.) > > So instead of returning Attr: > data Attr = Attr TypeRep TypeRep deriving (Show) > > Return a tuple of: > > newtype AttrAttrib = AttrAttrib TypeRep > deriving (Show, Typeable, Generic) > newtype AttrBasedOn = AttrBasedOn TypeRep > deriving (Show, Typeable, Generic) > > toAttrs :: (Generic product,ToAttrsR (Rep product)) > => product -> [(AttrAttrib, AttrBasedOn)] > toAttrs = map (\(Attr a b) -> (AttrAttrib a, AttrBasedOn b)) > . toAttrsR . from > > > > > So: > > > > 1) Have I understood your specification correctly? > > > > No, but I've learnt something more about the power of Generics. > > > 2) Other experts: is there safe trickery to generally specify this map? > > I think it might actually be doable in 7.4, but as far as I know, > > that was accidental generally-unsound functionality that was removed in > 7.6+. > > > > > > _______________________________________________ > Generics mailing list > Generics at haskell.org > http://www.haskell.org/mailman/listinfo/generics > -------------- next part -------------- An HTML attachment was scrubbed... URL: