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

Reply via email to