class aliases (was: Making decisions)

Petr Pudlák petr.mvd at gmail.com
Thu May 23 17:05:22 CEST 2013


Dne 05/23/2013 09:48 AM, Simon Peyton-Jones napsal(a):
> One other thing.  I'd certainly consider well-argued proposals for changing GHC to better support backward compatibility in the face of library change.  One such proposal was the "class alias" story, but that was a big, complex general mechanism (and arguably big benefits).  Because of its complexity it is currently stalled.  But there may be other much more modest things we could do to help; the question about ad-hoc deprecation of Monad without Functor is a  small, highly-specific, ad-hoc idea.
Is it this proposal? http://repetae.net/recent/out/classalias.html
Looks very interesting! How does it compare to Default superclass 
instances 
<http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances>? 
 From the first glance it seems to me that class aliases are strictly 
stronger. Are there some know design problems with this extension, which 
make it complex and which need to be solved first, or is it just a lot 
of work to implement?

(I'd be willing to do some work on it, although I'd probably spend a lot 
of time just figuring out how GHC intenals works.)

   Best regards,
   Petr



More information about the Libraries mailing list