Twan Sorry for slow reply -- I've been away.
Is this still 'live'? I'm not sure what you mean by (1). Perhaps you can show some output? Concerning (2), TcDeriv is very complicated, because it does so much ad-hoc stuff (by design). A big reason for the split that you see is that to *work out* the context for a deriving clause is quite difficult: see "Inferring missing contexts" in TcDeriv. It's not impossible that it could be done more neatly, or in a modular way. Combining checkSideConditions and the binding generation is probably the most promising opportunity, but I have spent bizarrely large amounts of time in this module and I'm not rushing to do more. Meanwhile, just adding Functor, in the same style as the code that is there already, should be straightforward. By all means send me a revised patch (against the HEAD). | By the way: is there any advantage (besides readability) to generating the code | "fmap f" instead of "\x -> fmap f x"? I don't think it should matter. thanks Simon | -----Original Message----- | From: [email protected] [mailto:glasgow-haskell-users- | [email protected]] On Behalf Of Twan van Laarhoven | Sent: 07 December 2008 01:22 | To: [email protected] | Subject: Deriving Functor | | Hello Ghc people, | | | I have been working on adding support for "derive Functor" to ghc. I have a | patch that mostly works, but there are some problems: | | | 1. Ghc reports the correct instance when I use -ddump-deriv:, but that instance | is not subsequenctly used. Instead I get a warning like: | | Warning: No explicit method nor default method for `fmap' | In the instance declaration for `Functor (Cont r)' | | What could be going on here? The full output is attached. | | | 2. As far as I understand the code, there would need to be three traversals of a | data type T to derive an instance Functor T: | | - First to determine whether the deriving should be allowed at all | (checkSideConditions) | - Then to determine the constraints needed (mk_data_eqn) | - Finally to make the body of the instance (gen_Functor_binds) | | This seems a bit redundant, and currently the code only does the last pass. | It would make more sense to report any errors during this pass as well. | | I don't understand how the constraints are determined in TcDeriv, for | instance for the type | | data T1 a b c = T1 a deriving (Eq) | | it seems as if Eq constraints are added for all of {a,b,c}, but somehow only | a constraint Eq a ends up in the final instance. How does that work? | | | | The (experimental) patch was too large to attach, it can be found at | http://twan.home.fmf.nl/files/deriv-functor-experimental1.patch.gz | | | By the way: is there any advantage (besides readability) to generating the code | "fmap f" instead of "\x -> fmap f x"? | | | Twan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
