On 3 May 2013 18:56, Ertugrul Söylemez <es@ertes.de> wrote:
Adrian May <adrian.alexander.may@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.