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

[Bryan O'Sullivan]

I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.

This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed – and to general approval, no less – on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.

I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.

Thanks,
Bryan.

> On Oct 5, 2015, at 7:32 AM, Gershom B <gershomb at gmail.com> wrote:
> 
>> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote:
>> Hello all. I write this to be a little provocative, but …
>> 
>> 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.
>> 
>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
>> that would have a profound impact on systems that are commercially and potentially safety  
>> critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility  
>> of the Haskell community to its users and, indirectly, to its future.
> 
> Hi Simon. I do in fact think this is provocative :-P
> 
> I want to object here to your characterization of what has been going on as “simply throwing in changes”. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.
> 
> I also want to object to the idea that these changes would have “a profound impact on systems”. As it stands, and I think this is an important criteria in any change, when “phase 2” goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.
> 
> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?
> 
> —Gershom
> 
> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime