Re: [Haskell-cafe] Backward compatibility

On Fri, May 3, 2013 at 6:34 AM, Adrian May wrote:

On 3 May 2013 18:56, Ertugrul Söylemez wrote:

...

Adrian May 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.

Seeing how type class constraints were removed, obviously, the change could not have been done without breaking code. On the other hand, the solution is a regular expression away. Even a 5-10 million line project could survive that, even if it means issuing a ticket, going through testing and QA, etc. GHC changes are an issue management needs to consider, but the maintenance burden they introduce are minimal and typically mechanically fixable. If management is unwilling to allocate resources to deal with these issues, then it behooves management to settle on a single version of the Haskell Platform (or even just GHC, if appropriate) or move on to another language, and lose the productivity benefits of Haskell.

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.

Surely, as a manager, you have taken at least a basic course in economics. And you understand how resources, such as open source developer time, are allocated. Everybody's time is valuable, and the professional academics who work on GHC will use the same economic principles you use (making changes with the highest marginal benefit). The hobbyist open source developers will do the same thing, except their utility functions will include their personal preferences. Do you really want this done? I suggest cash payments to the experience Haskell developer of your choice. )

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.

You already have that choice.