Petr Pudlák wrote:
František Farka [1] worked in detail on a proposal that would make such refactorings painless, see *Maintainable type classes for Haskell* [2]
I am just reading the paper (from 2015) for the first time and have noted at least one factual error. On page 6 it says: """ a4 – remove a superclass constraint from an existing class This change does not cause any problems. Some instances from be- fore the change may be superfluous as these are no longer re- quired by superclass constraint. """ Even though it does not invalidate the essence of what the author is claiming (it merely weakens the argument slightly), this particular assessment is clearly wrong: If the superclass has methods, removing the superclass breaks all functions that use superclass methods and that have a type signature which mentions only the child class in the constraints. Such client code must be fixed by adding a constraint that mentions the former superclass to its type. The paper has clearly not been proofread by an expert(*), so I guess its results should be taken with a grain of salt. Which is sad because I do like the ideas expressed in it. Cheers Ben (*) For another illustration, note the erroneous use of Semigrupoid (yes, with this spelling) instead of Semigroup. (A semigroupoid would be something like a category without the requirement of identities, I have no idea if such a thing has been seriously studied by anyone.) -- "Make it so they have to reboot after every typo." ― Scott Adams