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

Geoffrey Mainland mainland at apeiron.net
Wed Oct 21 00:39:57 UTC 2015

I am also a -1, and I share Bryan's concerns.

What worries me most is that we have started to see very valuable
members of our community publicly state that they are reducing their
community involvement. While technical disagreement has something to do
with their decisions, I suspect that it is the /process/ by which these
decisions have been made that is pushing them away. Whatever our
individual stances on AMP/FTP/MRP, I hope we can all agree that any
process that has this effect needs a hard look.

I consider myself a member of the Haskell community, but like Henrik and
Graham, I have not actively followed the libraries list. I was take by
surprise by AMP. When FTP appeared, I didn't speak up because I felt the
outcome was inevitable. I should have spoken up nonetheless; I am
speaking up now.

In effect, only those who actively follow the libraries list have had a
voice in these decisions. Maybe that is what the community wants. I hope
not. How then can people like me (and Henrik and Graham) have a say
without committing to actively following the libraries list?

We have a method to solve this: elected representatives. Right now the
Core Libraries Committee elects its own members; perhaps it is time for
that to change.

Let me throw out a few straw man proposals.

Proposal 1: Move to community election of the members of the Core
Libraries Committee. Yes, I know this would have its own issues.

Proposal 2: After a suitable period of discussion on the libraries list,
the Core Libraries Committee will summarize the arguments for and
against a proposal and post it, along with a (justified) preliminary
decision, to a low-traffic, announce-only email list. After another
suitable period of discussion, they will issue a final decision. What is
a suitable period of time? Perhaps that depends on the properties of the
proposal, such as whether it breaks backwards compatibility.

Proposal 3: A decision regarding any proposal that significantly affects
backwards compatibility is within the purview of the Haskell Prime
Committee, not the Core Libraries Committee.

Now I am not saying I feel strongly that all (or any) of these proposals
should be enacted (in fleshed out form), but I do think they are all
worth discussing.


On 10/05/2015 10:59 AM, Bryan O'Sullivan wrote:
> 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.

More information about the Haskell-Cafe mailing list