Am 29. Jun 2005 um 11.03 Uhr schrieb Simon Marlow:
On 28 June 2005 14:11, Bulat Ziganshin wrote:3) many users complaining about non-compatibility between GHC versions. if they mean library interfaces changes then how about using Pesco's library versioning scheme? (see http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory)I've read that article, and I think it's an interesting idea. I can't disagree with the arguments put forward, but somehow, the cure seems a bit painful.
Maybe a slightly painful cure would be preferable to a protracted disease? ;)
Metaphors aside, I have specifically tried to minimize developer pain with ECT. Can you be specific as to where you fear it? In adoption? In maintenance?
In the survey summary, you state that you "will strive to clearly indicate which features and libraries are considered experimental". While that means users of GHC can better avoid breakage, it obviously does so at the cost of prohibiting their use of those often very appealing new developments. Also, extra stress is put on the library developers to "get everything right" when a library is moved to stable status and, at the same time, to change as little as possible afterwards. With a growing number of users (as it seems to be currently happening), pressure to not change anything will likewise rise. The effect can already be seen in the Haskell 98 libraries, to some of which considerable improvements have become available. Still we cannot change them. H98 is not so bad, because the amount of libraries is relatively small and contained, but as can be seen in GHC 6.4, our library base is growing fast. People will want to use these libraries but they /will/ need change in the future, lest evolution stagnate.
But I should stop preaching to the choir. As the survey shows, backwards-compatibility is very important /and/ users praise rapid evolution. Thus we should work to solve the apparent dichotomy.
ECT can do it, but, as you state, the question is just, is it too painful? I think not, because:
1. Initial adoption consists of
- renaming modules - easy to automate,
- changing imports - also possible to automate, and
- creating the "short cut" modules - very easy to automate.
The semester ends in two weeks and I'd be happy to contribute.
If there is interest, I will get to work.
2. Proper maintenance means paying attention to notice
incompatible interface changes. Surely this is currently no
different.
Then, upon an interface change:
- renaming the module - trivial, and
- retaining the old version in some form, either by
o keeping a copy of the old code in place - trivial but
bloaty,
o implementing a compatibility adaptor, or
o if the change was actually backwards-compatible (as it will
undoubtedly happen as well), re-export the new version - a
convenience script job.
What am I missing?
Anyway, thanks for reading my article!
With best regards,
Pesco alias Sven Moritz
PGP.sig
Description: Signierter Teil der Nachricht
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
