[Haskell-cafe] Backward compatibility

Alexander Solla alex.solla at gmail.com
Fri May 3 15:53:28 CEST 2013


On Fri, May 3, 2013 at 6:34 AM, Adrian May
<adrian.alexander.may at gmail.com>wrote:

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130503/614b2e2a/attachment.htm>


More information about the Haskell-Cafe mailing list