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 <guytsalmave...@yahoo.com> wrote: > 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/**DefaultSuperclassInstances<http://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-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe