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

Gershom B gershomb at gmail.com
Mon Oct 5 14:32:21 UTC 2015


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.


More information about the Haskell-Cafe mailing list