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