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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
Url : http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20050629/f7e2a70c/PGP.bin