Backward compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
90 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Raphael Gaschignard



On Fri, May 3, 2013 at 4:37 PM, Simon Peyton-Jones <[hidden email]> wrote:

One of the great things about the Haskell mailing lists is the supportive, respectful tone that is the dominant mode of discourse.  I sense that things are getting a little out of control in this particular thread.  Even though this particular issue is clearly extremely frustrating for those involved, it would be great to turn down the emotional temperature.


I don’t know why Haskell folk tend to be so generous and helpful, but they really are. (Maybe it’s the hylomorphisms.)  Anyway, let’s keep it that way.


Agreed, the thing that surprised me the most when I started reading this list was how nice people were, even when faced with some pretty hostile people.

I think we all agree that dependency management is hard in any system, especially with a lot of generally unmaintained pieces. And the fact that 100% backwards compatibility doesn't seem to be a directive in the language committee like it might be for languages like C++ might frustrate people.

I'm pretty sure most of us have experienced some issue with dependencies breaking , and its probably the most frustrating problem we can have have in any language. It's hard not to take this all a bit personally. Maybe if we think more about how to solve this (getting people to maintain their stuff, for example) we can make the world a better place instead of bickering about issues that are more or less language-agnostic really.

On a side note is there a place where we can see what packages have broken on recent releases?


 

Simon

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Gregory Collins
Sent: 03 May 2013 08:27
To: Adrian May
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Backward compatibility

 

On Fri, May 3, 2013 at 6:48 AM, Adrian May <[hidden email]> wrote:

May I venture a guess that you never tried to manage a 5-10 million line project?

 

I build a project a couple orders of magnitude bigger than that dozens of times every day. Similar stories are not uncommon among people who inhabit this list. But thanks, citing that figure as an excuse to be condescending to that person was really worth a giggle this morning. :)

 

 

That's what I do. I'm not a programmer, I'm a manager. I run teams of a few dozen people on subprojects within huge telecom-related projects, and my job is to try and keep it all from collapsing in a heap of bugs. 

 

If you had any experience of that you'd run a mile from any technology with this hit and miss attitude.

 

You keep saying things like this. Actually, you're in this situation because one or more people within your organization have made a succession of very bad choices. Haskell is not to blame. Personally, I almost can't believe you're taking this tack on the list now that the details of your situation are apparent: you've let a 5-10 million line project spiral out of control without putting the necessary software engineering infrastructure and controls in place.

 

 

I can't tell people what version they should be using because half of them work for a completely different company. They have their own dependencies coming from other projects that I'm not even allowed to know about.


... and the truth emerges. This issue you're having reflects a lot more strongly on your technical culture than it does on any instability in GHC.

 

Listen: someone within your organization decided to build a product based on a very old library which is no longer maintained by anyone. If this library were actually critical to your business, you would fork it and either get someone in-house or pay a contractor to fix bugs and keep it up to date. (And there are plenty of people here who might be interested in a contract gig to fix this for you if you asked).

 

Repeatedly claiming in the most histrionic terms that GHC ought to freeze forever and never deprecate anything again so that you can avoid doing your job properly is simply not realistic, especially given Haskell's social culture (newsflash: it's a research platform), and is not going to garner you any sympathy on this list, either. You could practically be the poster boy for why we have the motto "avoid success at all costs".

 

You have two options: stay on GHC 6.x (the bits didn't get deleted from the internet), and if that isn't practical, fix Wash (or pay someone to do it if you don't know how) and get on with your life.

 

G

--
Gregory Collins <[hidden email]>


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Ertugrul Söylemez
In reply to this post by Adrian May
Adrian May <[hidden email]> wrote:

> I really don't know why somebody can't make a simple and well
> intentioned point without getting attacked by people who feel
> threatened over every little thing.

It's because we're failing to see the problem.  I mean, if you can
pinpoint the source of your problems we could work on a solution, and we
would be happy to do that.  However, it is important to keep in mind
that Haskell is very active and things change a lot.  This is not a
problem, it's the mindset of this community.  If you are turning it into
a problem, feel free, but then the only suggestion I can make here is
that Haskell is probably not the right choice for your particular
development strategy.

In other words, for Haskell it's simply wrong to assume that you can use
legacy code that hasn't been maintained for many years.  Regardless of
whether you like it, this is the way to go.  If you want to use Haskell,
be prepared to maintain your code.  This usually boils down to making
small adjustments.  When the big breaking change in the base library
came I had to adjust a number of type signatures in my projects and I
was done.  These adjustments become necessary from time to time, and you
should be ready to perform them.


> I said from the start that I think Haskell is cool.

Unfortunately that doesn't really help.  What you are trying to achieve
is a shift in our fundamental philosophy, which is very unlikely to
happen, even if the shift is small.  Using Haskell is great, but does
require you to keep up to date.

The other option is to go with old compiler and library versions.  They
are all available, if you need them for your project, but this is a bad
solution.


> I'd just like it to pay a bit more attention to practical issues
> whilst making progress with its theoretical ones.

It's very difficult to combine those.  Communities solve these problems
differently.  Most communities try to keep compatible at the expense of
eliminating much of the potential for innovation.  The Haskell community
prefers to go the innovation route and is prepared to repair occasional
breakages.  They do occur, and we fix them.


> Why don't you just put it in the forum rules that nobody is ever
> allowed to criticise anything?

Because that's wrong.  I criticize things a lot, sometimes with a much
stronger tone than you did. =)


> At the end of the day, I'm just a typical manager who's atypical in
> wishing he could tell his programmers to study a bit of Haskell
> without making it a synch for the manager next door to knife him in
> the back for suggesting something that looks this unstable. This is
> the real deal on how Haskell looks out there in the mass market. You
> can lead a horse to water...

If it's your decision, you shouldn't be afraid to make it.  You are the
manager of your team!  Don't let yourself be stabbed by another manager.
Recognize that your choice can lead to higher productivity, if you don't
let yourself be distracted by this pointless matter.  And yes, it is
pointless.  If you simply move on and get to productive Haskell work,
you will find that this is a non-issue.

In particular, you want to make educated decisions, which means that you
should probably research the current standards in the Haskell community.
If you would have performed that research from the beginning, you would
have come to the conclusion that WASH was a bad choice to begin with,
which leads me to another very important point:

I have worked in many SCRUM-based teams.  While I could question the
general usefulness of this paradigm, I have to say that it has taught me
a number of very important things, and one thing in particular:
Programmer choices should be made by programmers.  You shouldn't have
made the decision about the web framework in the first place.  Get a
team of Haskell programmers and let them choose the best tool for the
job.


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Ertugrul Söylemez
In reply to this post by Raphael Gaschignard
Raphael Gaschignard <[hidden email]> wrote:

> I'm pretty sure most of us have experienced some issue with
> dependencies breaking , and its probably the most frustrating problem
> we can have have in any language. It's hard not to take this all a bit
> personally. Maybe if we think more about how to solve this (getting
> people to maintain their stuff, for example) we can make the world a
> better place instead of bickering about issues that are more or less
> language-agnostic really.

The problem can't be solved technically.  It's a human problem after all
and it's amplified by the experimentalism in this community.  I think
the best we can do is to acknowledge its existence, which places us way
ahead of mainstream programming communities.

We don't pretend that type X in lib-0.1.0 is the same as type X in
lib-0.2.0.  What we need to work on is the ability to actually combine
multiple versions of the same package conveniently, i.e. we shouldn't
view this combination as an error.


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Adrian May
In reply to this post by Simon Peyton Jones
How about this: can you guys give me a detailed example of a justified deprecation: one so extremely obviously called for that even I would agree. I just want to understand the kind of logic that's applied over these things.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Neil Davies
In reply to this post by Ertugrul Söylemez
Isn't this a problem of timescale?

Nothing can be backward compatible for ever (or at least nothing that
is being developed or maintained)

There will be, in the life of non-trival length project, change.

We rely (and I mean rely) on Haskell s/w that was written over 10 years ago - we accept that
when we want to recompile it (about every 2/3 years as the systems it interacts with are updated)
there will be a cost of change to bring it up to latest libraries etc.

But the joy is that (combined with the regression and property tests around it) we can have very high
confidence that once the "old" stuff recompiles it will operate the same. And as it is key to our business
that is a nice feeling - let's me sleep soundly at night.

The beauty of the Haskell ecosystem is that such change is nowhere as hazardous as with other approaches.
Therefore its total costs are less.

The experimentalism in this community is to be applauded and encouraged - it is spawning robust
solutions to the "real" underlying problems of constructing a society that can actually support the
technical infrastructure it is creating. Don't forget the motivation for Ada was that the projected
costs of supporting the US defence infrastructure was projected to exceed the projected GDP of
the US by 2012. Maintaining essential safety critical systems isn't an optional extra.

We see that the same Ada-like scenario is working its way out in companies today - large Telcos,
Goverment projects etc - I also see that formalism, such as embodied in Haskell, is the ONLY hope
we have to contain the costs of maintenance complexity.

Yes, the underlying issue is a human one - but it lies in the low value given to medium to long
term sustainability of organisations (e.g Telcos) compared to the relative high value that is given
to novelty. Perhaps this is an inevitable by-product of a marketing driven, short term driven
business culture?

Neil

On 3 May 2013, at 10:04, Ertugrul Söylemez <[hidden email]> wrote:

> Raphael Gaschignard <[hidden email]> wrote:
>
>> I'm pretty sure most of us have experienced some issue with
>> dependencies breaking , and its probably the most frustrating problem
>> we can have have in any language. It's hard not to take this all a bit
>> personally. Maybe if we think more about how to solve this (getting
>> people to maintain their stuff, for example) we can make the world a
>> better place instead of bickering about issues that are more or less
>> language-agnostic really.
>
> The problem can't be solved technically.  It's a human problem after all
> and it's amplified by the experimentalism in this community.  I think
> the best we can do is to acknowledge its existence, which places us way
> ahead of mainstream programming communities.
>
> We don't pretend that type X in lib-0.1.0 is the same as type X in
> lib-0.2.0.  What we need to work on is the ability to actually combine
> multiple versions of the same package conveniently, i.e. we shouldn't
> view this combination as an error.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Ertugrul Söylemez
In reply to this post by Adrian May
Adrian May <[hidden email]> wrote:

> How about this: can you guys give me a detailed example of a justified
> deprecation: one so extremely obviously called for that even I would
> agree. I just want to understand the kind of logic that's applied over
> these things.

Changes already made in the base library or in one of the platform
libraries:

  * base: Eq and Show independent of Num.  Broke a lot of code.  Reason:
    Makes function-like numeric types possible.

  * base: Deprecated and finally removed the old exception system.
    Replaced by extensible exceptions, added new masking system.  Broke
    a lot of code.  Reason:  Makes the whole exception handling more
    sensible.

  * mtl: Unified transformer and Identity variants.  Broke some code.
    Reason:  Makes the internals much more maintainable and the whole
    library design more sensible.

  * Haskell: Changed the type specializing behavior in local bindings.
    Broke a lot of code.  Reason:  Makes type inference infer more
    specialized types, makes code more concise, but occasionally
    requires a type signature when you specifically want more
    polymorphic types.

Often demanded changes that may or may not happen in the future:

  * base: Make Functor a superclass of Monad.  One of the two most
    commonly demanded change to the base library.  Will break lots and
    lots of code.  Reason:  Would greatly simplify a lot of code.

  * base: Fix the numeric type classes.  The other most commonly
    demanded change.  Will break lots and lots of code, including most
    of the base library.  Reason:  Would make numeric code much more
    sensible and algebraic.

My personal demands.  Unlikely to happen in the near future:

  * Add RankNTypes, ScopedTypeVariables, TupleSections and TypeFamilies
    to standard Haskell.  Shouldn't break any existing code.

  * Replace all special arrow classes by category classes, i.e. turn
    ArrowChoice and ArrowLoop into CategoryChoice and CategoryLoop.
    Introduce ApplicativeFix.  Will break some existing code.

  * Factor Applicative and Alternative into four classes:
      - (Functor f) => Apply f          (<*>)
      - (Apply f)   => Applicative f    pure
      - (Functor f) => Plus f           (<|>)
      - (Plus f)    => Alternative      empty
    Would break everything.  Everything.

I could go on.  The point is that you are probably the first person to
complain about those changes. =)


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Ertugrul Söylemez
In reply to this post by Neil Davies
Neil Davies <[hidden email]> wrote:

> Isn't this a problem of timescale?
>
> Nothing can be backward compatible for ever (or at least nothing that
> is being developed or maintained)

I was referring to the Dependency Hell.  I don't consider breaking
changes a problem.


Greets,
Ertugrul

--
Key-ID: E5DD8D11 "Ertugrul Soeylemez <[hidden email]>"
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Adrian May
In reply to this post by Ertugrul Söylemez
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?


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Guy
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Guy
In reply to this post by Ertugrul Söylemez
Ertugrul Söylemez wrote:

> Often demanded changes that may or may not happen in the future:
>
>    * base: Make Functor a superclass of Monad.  One of the two most
>      commonly demanded change to the base library.  Will break lots and
>      lots of code.  Reason:  Would greatly simplify a lot of code.
>
>    * base: Fix the numeric type classes.  The other most commonly
>      demanded change.  Will break lots and lots of code, including most
>      of the base library.  Reason:  Would make numeric code much more
>      sensible and algebraic.

That's what I thought of when I saw the original complaint - GHC is too backwards compatible! There's far too much
boilerplate because of the Functor => Applicative => Monad mess. Float/Double being Enums is ridiculous. None of this
gets fixed because of the fear that new GHC won't compile old code.

Perhaps we need some system for maintainers to vote on whether they consider the value of a breaking change to be worth
the effort of fixing their packages to work with it. In my own code, I usually find that this effort is minor, and I'm
more than happy to do it in return for a better language/library.

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards
compatibility bogeyman always seems to trump something that will break a lot of code.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Tobias Dammers
On Fri, May 03, 2013 at 01:23:55PM +0300, Guy wrote:
> That's what I thought of when I saw the original complaint - GHC is
> too backwards compatible! There's far too much boilerplate because
> of the Functor => Applicative => Monad mess. Float/Double being
> Enums is ridiculous. None of this gets fixed because of the fear
> that new GHC won't compile old code.

>
> PS The proposal to fix Functor => Applicative => Monad has patches
> attached for GHC and base, but the backwards compatibility bogeyman
> always seems to trump something that will break a lot of code.

This kind of "breaks everything" changes would require something similar
to what Python is doing with the 2 -> 3 transition, and considering how
painfully slowly it is progressing there, I understand perfectly well why
people don't want to go there.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Adrian May
In reply to this post by Guy

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.

I think that should be fixed as well, but it would be tantamount to a new language. 

I guess you need some kind of versioning system for the libraries. Why not put them all in a public source control server and have ghc force people to say which snapshot they wanted. That would be your final breaking change, and it's a one-liner in the Makefile. Then you could thrash around as much as you liked and people like me would have nothing to complain about. Naturally, the compiler itself should keep supporting old modes.

Adrian.

 


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Ertugrul Söylemez
In reply to this post by Adrian May
Adrian May <[hidden email]> 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)


Greets,
Ertugrul

--
Key-ID: E5DD8D11 "Ertugrul Soeylemez <[hidden email]>"
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Michael Sloan
In reply to this post by Ertugrul Söylemez
Dependency breakage is certainly an unavoidable problem.  However, I think Haskell is also in a much better position for having a technical solution to the frustration of breakages.

Barring issues with changing datatypes / class instances, we can already express many of the API changes you'd want to make to some library [1].  Now, no one actually does what this proposal suggests - it's a lot of work, and it doesn't work in general.  However, the fact that Haskell makes something like this seem reasonable is heartening.

Of course, even if we had good tools that automatically refactored code to use new APIs, it wouldn't be possible for any non-superficial changes.  Even so, if a good enough refactoring tool existed, and it was popular with both authors and users, a lot of the annoyance of dependency breakages could be removed.

-Michael

[1] http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityInTheory



On Fri, May 3, 2013 at 2:04 AM, Ertugrul Söylemez <[hidden email]> wrote:
Raphael Gaschignard <[hidden email]> wrote:

> I'm pretty sure most of us have experienced some issue with
> dependencies breaking , and its probably the most frustrating problem
> we can have have in any language. It's hard not to take this all a bit
> personally. Maybe if we think more about how to solve this (getting
> people to maintain their stuff, for example) we can make the world a
> better place instead of bickering about issues that are more or less
> language-agnostic really.

The problem can't be solved technically.  It's a human problem after all
and it's amplified by the experimentalism in this community.  I think
the best we can do is to acknowledge its existence, which places us way
ahead of mainstream programming communities.

We don't pretend that type X in lib-0.1.0 is the same as type X in
lib-0.2.0.  What we need to work on is the ability to actually combine
multiple versions of the same package conveniently, i.e. we shouldn't
view this combination as an error.


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Adrian May
In reply to this post by Ertugrul Söylemez



On 3 May 2013 18:56, Ertugrul Söylemez <[hidden email]> wrote:
Adrian May <[hidden email]> 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.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

David Thomas
In reply to this post by Guy
I'd also like to see these two.  It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases.  It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where.

The idea is to allow definitions of superclass operations in subclass instances.  If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even).  I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad too, with some care).  It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate.  At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.


On Fri, May 3, 2013 at 3:23 AM, Guy <[hidden email]> wrote:
Ertugrul Söylemez wrote:
Often demanded changes that may or may not happen in the future:

   * base: Make Functor a superclass of Monad.  One of the two most
     commonly demanded change to the base library.  Will break lots and
     lots of code.  Reason:  Would greatly simplify a lot of code.

   * base: Fix the numeric type classes.  The other most commonly
     demanded change.  Will break lots and lots of code, including most
     of the base library.  Reason:  Would make numeric code much more
     sensible and algebraic.

That's what I thought of when I saw the original complaint - GHC is too backwards compatible! There's far too much boilerplate because of the Functor => Applicative => Monad mess. Float/Double being Enums is ridiculous. None of this gets fixed because of the fear that new GHC won't compile old code.

Perhaps we need some system for maintainers to vote on whether they consider the value of a breaking change to be worth the effort of fixing their packages to work with it. In my own code, I usually find that this effort is minor, and I'm more than happy to do it in return for a better language/library.

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Tom Ellis
In reply to this post by Adrian May
On Fri, May 03, 2013 at 09:34:21PM +0800, Adrian May wrote:
> 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.

I think you may be overestimating the severity of the "breakage" that
applies to the WashNGo package.

In Haskell2010 a number of module locations were renamed in order to reduce
clutter.  For example, IO became System.IO, List became Data.List and Monad
became Control.Monad.

I'm pretty sure that updating all of these module names will fix the
problem.  No one has bothered because the package is very old and there are
more suitable alternatives these days.

Tom

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Alexander Solla
In reply to this post by Adrian May



On Fri, May 3, 2013 at 6:34 AM, Adrian May <[hidden email]> wrote:



On 3 May 2013 18:56, Ertugrul Söylemez <[hidden email]> wrote:
Adrian May <[hidden email]> 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. 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Brandon Allbery
In reply to this post by Adrian May
On Fri, May 3, 2013 at 5:30 AM, Adrian May <[hidden email]> wrote:
How about this: can you guys give me a detailed example of a justified deprecation: one so extremely obviously called for that even I would agree. I just want to understand the kind of logic that's applied over these things.

This might not be possible because your notion of a justified change may not align with other people's. IIRC the removal of the Show constraint on Num was driven by type level natural numbers? which matter to the type hackers but not to someone whose main concern is getting an unmaintained web interface running. (OTOH it also may not have any effect on said web server, since it mostly affected people who take the somewhat risky action of defining their own Num instances; I suspect the exceptions change would have more impact on web stuff.)

As for the exceptions stuff, that was a multi-step change. Exception handling was somewhat unprincipled and came in two forms, which used the same function names but in different ways. There was support for IO exceptions in the Prelude and conflicting support for general exceptions, which behaved somewhat differently when handed an IO exception, in Control.Exception. One key behavior was that you had to handle all exceptions or none at all; the only way to choose specific exceptions was to handle all of them, inspect the exception object, and rethrow if it wasn't one you wanted to handle. And inspecting the exception object to see what it had in it could be tricky at times, because there wasn't much guidance with respect to user defined exceptions and some library exceptions did things slightly differently from the ones in the base.

The exception cleanup made IO exceptions and other exceptions behave consistently and got rid of the conflicting definitions. This did require source changes, as anyone relying on the Prelude exceptions had to add an import of Control.Exception and anyone using old-style exceptions generally had to add a type annotation to their handler; more ideally, they'd rewrite their exception code to handle specific exceptions or exception classes instead of poking at the exception object to determine whether it was one they cared about or not --- but this was not necessary to get older code running again, only the added type annotation was necessary.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Adrian May
In reply to this post by Michael Sloan

Barring issues with changing datatypes / class instances, we can already express many of the API changes you'd want to make to some library [1].  Now, no one actually does what this proposal suggests - it's a lot of work, and it doesn't work in general.  However, the fact that Haskell makes something like this seem reasonable is heartening.

[1] http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityInTheory


Thanks Michael, that seems to be what I was talking about, only 8 years earlier, better thought through, and somewhat more readable.

So why do you say it doesn't work in general?



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Ozgur Akgun
In reply to this post by Tobias Dammers
Hi,

On 3 May 2013 11:43, Tobias Dammers <[hidden email]> wrote:
> PS The proposal to fix Functor => Applicative => Monad has patches
> attached for GHC and base, but the backwards compatibility bogeyman
> always seems to trump something that will break a lot of code.

This kind of "breaks everything" changes would require something similar
to what Python is doing with the 2 -> 3 transition, and considering how
painfully slowly it is progressing there, I understand perfectly well why
people don't want to go there.

There is one very big advantage in the Haskell-world though. 
Most of the struggle will be at the compile time. The biggest headache caused by
the Python 2 -> 3 transition is how you get a runtime error 2 weeks after you think
you've fixed everything!

(Yeah, I know code coverage analysis is an option when you don't have static
type checking, but ...)

Cheers,
Ozgur


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345