LAST CALL to comment on the Applicative/Monad Proposal

[Philippa Cowderoy]

I'm not committee, so I don't need to be part of any consensus. Myself I 
wouldn't bundle something I want up with something that's needed just to 
get it to pass anyway, for what it's worth. I'd rather keep my own ideas 
modular enough they don't bog anything down! So if I try to push my pet 
feature further it'll be its own proposal and I for one can't tie it to 
anything.

But I certainly understand where you're coming from on this. I'm sorry 
if I've made things harder for you here, and I have to admit I had 
preferred that MFP and MNR wait their turn. I'm hoping that one way or 
another, Herbert's proposal means we reach some kind of conclusion in 
the long run - at the least, we will have two mutually-exclusive 
proposals on the table and an obligation to pick one, refine quickly or 
go home.

I'd like to thank you for your work - myself I'm infamously unable to 
get things done (to the point of unemployability), and I've stayed off 
the committee precisely because I can appreciate the effort involved.

On 16/01/2019 20:00, Mario Blažević wrote:
> A month passed since the last call, and I'm sorry to say that the 
> Applicative/Monad proposal has been rejected. Herbert has vetoed it on 
> the grounds that it doesn't come packaged with MonadFail and 
> MonadOfNoReturn proposals.
>
> This is very unfortunate because (I thought) there was finally a 
> glimmer of hope for Haskell 2020. The new process used to complete the 
> RelaxedPolyRec proposal seemed promising, as it worked around the 
> commitee's letargy problem. As it turns out, that wasn't the only 
> problem.
>
> In all fairness, Herbert did state [1] he intends to write up the 
> combination of AMP, MFP, and MNRP the way he likes it. I do hope that 
> happens, but when and if he submits the combined proposal, I would not 
> be surprised if, for example, Philippa should veto it on the grounds 
> that it doesn't include the ApplicativeDo proposal that she's been 
> vocal about. This committee is a far cry from the one that gave us 
> Haskell '98.
>
> A Haskell 2020 report with no AMP would be pointless, in my opinion, 
> so I'm going to suspend my work on the report until this issue is 
> resolved. I still think the best course of action may be to disband 
> the current disfunctional committee and form a new one, as I proposed 
> [2] before establishing the new process.
>
> [1] https://github.com/haskell/rfcs/pull/1#issuecomment-448126690
> [2] 
> https://mail.haskell.org/pipermail/haskell-prime/2018-October/004370.html
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime