class aliases (was: Making decisions)

[Simon Peyton-Jones]

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 at gmail.com]
| Sent: 23 May 2013 16:05
| To: Simon Peyton-Jones; libraries at 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