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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
