Re: [Haskell-cafe] Extending Type Classes
See http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances | -Original Message- | From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf | Of Henning Thielemann | Sent: 26 August 2013 20:07 | To: Frantisek Farka | Cc: Haskell Cafe | Subject: Re: [Haskell-cafe] Extending Type Classes | | | The problem of refinement of type classes annoys me from time to time | when I work on the NumericPrelude. It is an experimental type class | hierarchy for mathematical types. Sometimes a new data type T shall be | implemented and it turns out that you can implement only a part of all | methods of a certain class. Then a natural step is to split the class | into | two classes A and B: 'A' contains the methods we can implement for T and | 'B' contains the remaining methods and 'B' is a sub-class of 'A'. | First, this means that all client code has to be rewritten. Second, | code | for instances becomes very lengthy, because over the time code tends to | contain one instances for every method. However the many small instances | actually carry information: Every instance has its specialised | constraints. E.g. you would certainly try to use only Applicative | constraints in an Applicative instance and not Monad constraints. | However, | if there is a way to define Applicative and Monad instances in one go, | the | Applicative instance may get Monad constraints. | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending Type Classes
The problem of refinement of type classes annoys me from time to time when I work on the NumericPrelude. It is an experimental type class hierarchy for mathematical types. Sometimes a new data type T shall be implemented and it turns out that you can implement only a part of all methods of a certain class. Then a natural step is to split the class into two classes A and B: 'A' contains the methods we can implement for T and 'B' contains the remaining methods and 'B' is a sub-class of 'A'. First, this means that all client code has to be rewritten. Second, code for instances becomes very lengthy, because over the time code tends to contain one instances for every method. However the many small instances actually carry information: Every instance has its specialised constraints. E.g. you would certainly try to use only Applicative constraints in an Applicative instance and not Monad constraints. However, if there is a way to define Applicative and Monad instances in one go, the Applicative instance may get Monad constraints. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Extending Type Classes
Hello all, I was looking for my master thesis topic and my supervisor suggested an idea of extending class system so it enables refactoring Type Class hierarchy without affecting client source code which is using refactored classes. One example is Functor - Applicative - Monad problem and corresponding proposal [1]. But this proposal instead of allowing the change through extending Type Classes forces client code to prepare for the new class layout and then switch the classes to the new layout. My goal is rather to allow direct changes in class hierarchy without affecting client source code. I have found different proposals approaching this problem on HaskellWiki, some of them are overlapping, some of them refer each other. The most promising to me seems Default superclass instances proposal [2]. This one is somehow implemented in the Strathclyde Haskell Enhancement (SHE) [3] but I haven't found much reference or user experience really. So the reason why I write this email is to ask you for some tips where above mentioned problem occurs in real source code. I would like to investigate some real examples before designing some ad hoc changes to the Type Classes system. Besides that I'd appreciate anyone who has used default superclass instances in SHE to share his experience. And last but not least I am always grateful for any comments and suggestions. Best wishes Frantisek [1] http://www.haskell.org/haskellwiki/Functor_hierarchy_proposal [2] http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances [3] https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
