Re: Breaking Changes and Long Term Support Haskell
On 21.10 17:42, Gregory Collins wrote:
All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.
I think that how the changes are handled can make a large difference. E.g. if A) Most of Hackage (including dependencies) compiles with new GHC. (stack & stackage helps somewhat) B) There is an automated tool that can be used to fix most code to compile with new versions of GHC without warnings or CPP. C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat) Then I think much of the complaints would go away. - Taru Karttunen
On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen
E.g. if
A) Most of Hackage (including dependencies) compiles with new GHC. (stack & stackage helps somewhat)
B) There is an automated tool that can be used to fix most code to compile with new versions of GHC without warnings or CPP.
C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat)
Then I think much of the complaints would go away.
If we had those things, indeed they would! However, beyond A (GHC 7.10 was tested more extensively against hackage/stackage than any previous release of Haskell by far!), the others require various degrees of engineering effort, including some way to deal with refactoring code that already has CPP in it, more extensive build-bot services, etc. and those sort of non-trivial artifacts just haven't been forthcoming. =/ I would be very happy if those things showed up, however. -Edward
On 2015-10-22 at 08:04:10 +0200, Taru Karttunen wrote: [...]
B) There is an automated tool that can be used to fix most code to compile with new versions of GHC without warnings or CPP.
Fyi, Alan is currently working on levaraging HaRe[1] in https://github.com/alanz/Hs2010To201x (the `parsing-only` branch) and it's already showing great promise. However, tools like this will only be able to handle the no-brainer cases, as in general it's a NP hard problem. But luckily, those boring mechanical refactorings usually represent the vast majority, and that's the tedious work we want tooling to assist us most with.
C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat)
I.e. something like http://matrix.hackage.haskell.org/package/text ? :-) [1]: Btw, here's a recent talk which also mentions the use-case of using HaRe to update between Haskell Report revisions or `base` versions: https://skillsmatter.com/skillscasts/6539-a-new-foundation-for-refactoring-g...
On 22.10 09:04, Herbert Valerio Riedel wrote:
Fyi, Alan is currently working on levaraging HaRe[1] in
https://github.com/alanz/Hs2010To201x (the `parsing-only` branch)
and it's already showing great promise. However, tools like this will only be able to handle the no-brainer cases, as in general it's a NP hard problem. But luckily, those boring mechanical refactorings usually represent the vast majority, and that's the tedious work we want tooling to assist us most with.
Yes, getting it 99% there as an automated tool would be enough for most cases.
C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat)
I.e. something like
Yes! Is there a reason that it is not displayed on http://hackage.haskell.org/package/text which only displays a link to Status of a 7.8.3 build? How many percent of Hackage is built with matrix.h.h.o and is there a plan to integrate it into Hackage pages? - Taru Karttunen
participants (3)
-
Edward Kmett -
Herbert Valerio Riedel -
Taru Karttunen