[Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Erik Hesselink]

We use base-compat, and it works for addition of functions and
instances. It doesn't work for type class changes like this one.

On 5 October 2015 at 15:46, Greg Weber <greg at gregweber.info> wrote:
> Does anyone here use base-compat? It has worked quite well in my very
> limited usage. I think that if the libraries committee officially maintained
> it then most of the complaints about the difficulties of maintaining
> backwards-compatible code and having to use conditional compilation would go
> away. So we have a solution for a large subset of the complaints here, why
> is nobody using it?
>
> On Mon, Oct 5, 2015 at 6:27 AM, Sven Panne <svenpanne at gmail.com> wrote:
>>
>> 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
>>>
>>> [...] It’s really interesting to have this discussion, which pulls in all
>>> sorts of well-made points about orthogonality, teaching, the evolution of
>>> the language and so on, but it simply goes to show that the process of
>>> evolving Haskell is profoundly broken. [...]
>>
>>
>> I wouldn't necessarily call the process "broken", but it's a bit annoying:
>> Because of the constant flux of minor changes in the language and the
>> libraries, I've reached the stage where I'm totally unable to tell if my
>> code will work for the whole GHC 7.x series. The only way I see is doing
>> heavy testing on Travis CI and littering the code with #ifdefs after
>> compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
>> conjunction with -Wall. Bonus points for keeping the #ifdefs centralized. No
>> clue how to do that...) This is less than satisfactory IMHO, and I would
>> really prefer some other mode for introducing such changes: Perhaps these
>> should be bundled and released e.g. every 2 years as Haskell2016,
>> Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
>> kicking out return, etc.) comes in slightly larger, but more sensible
>> chunks.
>>
>> Don't get me wrong: Most of the proposed changes in itself are OK and
>> should be done, it's only the way they are introduced should be improved...
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>