On 10/06/2015 02:49 AM, wren romano wrote: > On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <acfolt...@gmail.com> 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, _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
