Backwards-Compatibility [Was: Re: ANNOUNCE: GHC survey results]

[Sven Moritz Hallberg]

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