Petr It's a complex design space. I can't even readily answer your question "are class aliases strictly stronger". Neither feature is fully specified yet. Each has variations. I'm also worried about implementing a complex feature that ultimately turns out not to solve the library-evolution problem. So although I can see the benefits (to library evolution in particular) I have consciously punted on this, hoping that someone will evolve a design that everyone says "aha, that's it". So by all means have at it; I'm sure we'd learn from the process. I just don't want to promise up-front to adopt the result. Simon | -----Original Message----- | From: Petr Pudlák [mailto:petr.mvd@gmail.com] | Sent: 23 May 2013 16:05 | To: Simon Peyton-Jones; libraries@haskell.org | Subject: class aliases (was: Making decisions) | | 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