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
> >
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
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
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
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
| > 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
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
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,
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:
>
>
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
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
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
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
> 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
14 matches
Mail list logo