[Haskell-cafe] Backward compatibility

[Adrian May]

On 3 May 2013 18:56, Ertugrul Söylemez <es at ertes.de> wrote:

> Adrian May <adrian.alexander.may at gmail.com> wrote:
>
> > > Changes already made in the base library or in one of the platform
> > > libraries:
> >
> > So could you pick the most unassailable and tell me more about it
> > please?
>
> I'll just pick a random example:  Eq and Show are no longer superclasses
> of Num.  I'm the author of the Netwire library, a library for functional
> reactive programming.  Before that change you would write the following
> code to express a clock that runs twice as fast as the real time clock
> and oscillates up and down while gradually increasing:
>
>     liftA2 (\t o -> 2*t + sin o) time (integral_ 0 . v)
>
> Thanks to the change you can now write it as:
>
>     2*time + sin (integral_ 0 . v)
>
>
I never doubted that people add new stuff for valid reasons. What I'm
interested in is whether or not it could have been done without breaking
anything. But having thought about it for a while, I'm tending to think
that version controlling all the standard modules is the only general
solution.

You'd have them all in a git ... ahem ... darcs repo which every dev would
clone the entire history of. Something prominent in the project would say
which version you want. (We could brainstorm about hierarchies of that but
it probably wouldn't work anyway.) GHC would just switch its internals
according to that number and fetch the right version of the module out of
darcs as part of the compilation process.

If you really wanted to protect people from future changes, you'd make it
obligatory to tell ghc which version you want, but seeing as I seem to be
more worried about this than anybody else around here, I might as well
assume you'd default to the latest, but please, at least issue a warning so
that people know this offbeat system even exists.
)
I could have my project source in a completely different source control
system cos this darcs interaction is internal to the compiler.

This ain't gonna mean I don't have to maintain stuff, but having the choice
about when to do so would be a great help. Better still, I could take a
fifty year old codebase, build it out of the box, and nudge the version
along one step at a time so I have some kind of chance, which would render
my original post completely redundant.

But best of all, I'd no longer care which dev had which Haskell Platform
version. They'd just get nagged into upgrading ghc whenever it saw a too
racy module version. That would mean I could let them finish what they were
doing on their own branch, check it into the old-style mainline and then
tell them to merge it onto the new-style mainline, expecting a few puzzles
along the way. For their next feature they'd branch off the new mainline
and in a few weeks the old one would be history. (I'm not sure you've all
figured out that those few weeks are necessary.)

Seeing as you guys like theoretical rigour so much, maybe I should put it
this way: if you show me a lump of text and call it source code for a
program, I'll think you mean that it contains all the information I need to
turn it into one. If it fails to specify which versions of which external
libraries it assumes are hanging around somewhere, then it hardly meets
that definition. Looking at it that way, compiler errors are not the worst
thing that could happen: it might build an entirely different program. I've
seen two huge projects hit the trash can because of build system vagueness,
and that's what I learned out of it.

Just imagine never having to negotiate with the backward-compatibility
whingers anymore!

Adrian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130503/b12ea47b/attachment.htm>