I'm having a bit of trouble getting my brain around that, but if anybody
cares about attracting new users, that might be relevant in itself. Perhaps
I could be seen as an example of your swing-state. I'm no Haskell expert
but I'd like to push it if I could cos I'm so sick of seeing huge codebases
land in the dustbin due to the evils of imperative coding. The
version-controlled modules thing is immediately comforting for me cos I
know what it is and I could fire it at the manager next door who doesn't
know much but fancies my job.
On 3 May 2013 22:54, Guy
David Thomas wrote:
I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where.
The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that).
This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.
http://hackage.haskell.org/**trac/ghc/wiki/**DefaultSuperclassInstanceshttp://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code.
______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe