Honestly, the main issue is that even if you have the ability to describe default definitions for how to implement superclasses, it isn't really all that useful. :(<div><br></div><div>e.g. Every monad transformer still needs each of its instances crafted by hand. This even applies to simpler types:</div>
<div><br></div><div>Given</div><div><br></div><div>instance (Traversable f, Traversable g) => Traversable (Compose f g)</div><div><br></div><div>you don't want the derived instances for Functor and Foldable, </div>
<div><br></div><div>instance (Traversable f, Traversable g) => Functor (Compose f g)</div><div><div>instance (Traversable f, Traversable g) => Foldable (Compose f g)</div></div><div><br></div><div>you want the more permissive ones you can roll by hand.</div>
<div><br></div><div><div>instance (Functor f, Functor g) => Functor (Compose f g)</div><div>instance (Functor f, Functor g) => Foldable (Compose f g)</div></div><div><br></div><div>or</div><div><br></div><div>newtype Const a b = Const a</div>
<div><br></div><div>where</div><div><br></div><div>instance Functor (Const a)</div><div><br></div><div>isn't the superclass default you'd get from</div><div><br></div><div>instance Monoid m => Applicative (Const m)</div>
<div><br></div><div><div>We've held up any sort of serious reform of the class hierarchy because we keep hoping that some kind of solution to this problem will swoop in and save us.</div></div><div><br></div><div>This is one of those situations where the hope for a better solution being 'right around the corner' for the last few years has crippled our resolve to proceed with the things we _could_ fix.</div>
<div><br></div><div>I'm pessimistic enough not to see how progress can be made. </div><div><br></div><div>In the absence of the silver bullet that I don't think<i> </i><b>can</b> exist, "wiser" heads will continue to prevail and I'll continue to have to implement most of my combinators 2 or more times to deal with Monad vs. Applicative, etc, cluttering my namespaces and duplicating effort.</div>
<div><br></div><div>This is one area where a more traditional OOP language has a serious benefit over Haskell. It is far easier to retroactively add levels to a C++ class hierarchy without breaking any code, than it is to add them to a Haskell class hierarchy at all.</div>
<div><br></div><div>-Edward<br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 10:06 AM, Dan Burton <span dir="ltr"><<a href="mailto:danburton.email@gmail.com" target="_blank">danburton.email@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Adding new superclasses breaks a lot of code for little gain for most people. We need a technical solution to this problem first, before we can refactor our type hierarchy.</blockquote>
<div><br></div></div><div>A technical solution, eh?</div><div><br></div><div><a href="http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances</a></div>
<div><br></div><div>What is the status on this? How hard would this be to implement as a GHC extension? Are there any reasons this should not be baked into, say, Haskell 2014?</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>-- Dan Burton</div>
</font></span><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>