Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Geoffrey Mainland
On 10/22/2015 02:25 PM, Edward Kmett wrote: > > On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland > > wrote: > > On 10/22/2015 01:29 PM, Edward Kmett wrote: > > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland > >

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Edward Kmett
On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins wrote: > > On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland > wrote: > >> My original email stated my underlying concern: we are losing valuable >> members of the community not because of the

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Taru Karttunen
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

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Herbert Valerio Riedel
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

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Edward Kmett
On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen wrote: > 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

RE: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Simon Peyton Jones
| > Are these three technical capabilities *all* that we would need? | > Perhaps | > we also need a way to tie the current language (-XHaskell98, | > -XHaskell2010) to a particular implementation of the Prelude. | > | > | > I don't have a concrete plan here. I'm not even sure one

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Edward Kmett
On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins wrote: > > On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett 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

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Taru Karttunen
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,

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Geoffrey Mainland
On 10/22/2015 02:40 AM, Edward Kmett wrote: > On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins > > wrote: > > > On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland > > wrote: > >

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Geoffrey Mainland
On 10/22/2015 11:02 AM, Matthias Hörmann wrote: > I would say that the need to import Control.Applicative in virtually > every module manually > definitely caused some pain before AMP. In this particular case, there is a trade off between breaking code on the one hand and having to write some

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Edward Kmett
On Thu, Oct 22, 2015 at 11:36 AM, Geoffrey Mainland wrote: > On 10/22/2015 11:02 AM, Matthias Hörmann wrote: > > I would say that the need to import Control.Applicative in virtually > > every module manually > > definitely caused some pain before AMP. > > In this particular

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Mario Blažević
On 15-10-22 09:29 AM, Geoffrey Mainland wrote: ... 1) What is the master plan, and where is it documented, even if this document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP? Relatedly, guidance

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Edward Kmett
On Thu, Oct 22, 2015 at 12:20 PM, Mario Blažević wrote: > On 15-10-22 09:29 AM, Geoffrey Mainland wrote: > >> ... >> >> 1) What is the master plan, and where is it documented, even if this >> document is not up to the standard of a proposal? What is the final >> target, and

Re: Breaking Changes and Long Term Support Haskell

2015-10-22 Thread Geoffrey Mainland
> I outlined one possible path to avoid this kind of issue: spend more > time thinking about ways to maintain compatibility. We had > proposals for > doing this with AMP. > > > And on the other hand we also had a concrete proposal that didn't > require language changes that was