On 10/06/2015 02:49 AM, wren romano wrote:

On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer wrote:

...

...

Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all at once in e.g. `base-5.0`, breaking almost *every* single package out there at once.

I doubt the number of complaints-per-change would be fewer, but I'm strongly in favor of moving away from what feels like a treadmill that doesn't value the time of developers and that doesn't account for the more-than-sum-of-parts cost of the "constant flux".

Broadly speaking, I'm a "fix it now rather than later" sort of person in Haskell because I've seen how long things can linger before finally getting fixed (even when everyone agrees on what the fix should be and agrees that it should be done). However, as I mentioned in the originating thread, I think that —at this point— when it comes to AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to work out a comprehensive solution (as soon as possible), and then enact all the changes at once when switching to Haskell201X/base-5.0/whatevs.

In general: Yes, when everybody more or less agrees what the Right Thing then this is probably the way to go. (But it still carries the risk of e.g. C++ "template exports" which seemed a good idea a the time, but was unimplementable.) In this specific case: Isn't the proposal under discussion here more or less the end game for the change to Applicative/Monad? (I mean, I don't think anyone's seriously suggesting *removing* "return" completely any time soon.) If so, then I think the only thing punting this specific proposal to the new Haskell' committe will achieve is to postpone the stream of complaints :). Plus, we still haven't seen that the new committe will actually achieve anything of note. There seem to be be good signs, but we've been here before...

I understand the motivations for wanting things to be field-tested before making it into the report, but I don't think having a series of rapid incremental changes is the correct approach here. Because we're dealing with the Prelude and the core classes, the amount of breakage (and CPP used to paper over it) here is much higher than our usual treadmill of changes; so we should take that into account when planning how to roll the changes out.

This seems to be ignoring the huge amount of planning that actually *did* go into this proposal (and the BPP, etc.). No amount of planning can get around the fact that some people simply *don't want any change*. Regards,