Re: LAST CALL to comment on the Applicative/Monad Proposal

[Mario Blažević]

On 2019-01-16 3:10 p.m., Oliver Charles wrote:
Is there information anywhere on the process for acceptance/rejection 
criteria. It sounds like hvr can outright reject any proposal - are 
there others with that power? What is generally required for acceptance? 
Not meant critically, just interested


	Every active member of the commitee has that power. We could 
contemplate a different approach, like voting, if all members of the 
commitee were active. When you have only a couple of responses to a 
proposal, consensus among those who respond is the only possible way to go.





On Wed, 16 Jan 2019, 8:01 pm 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




--
Mario Blazevic
mblaze...@stilo.com
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Oliver Charles]

Is there information anywhere on the process for acceptance/rejection
criteria. It sounds like hvr can outright reject any proposal - are there
others with that power? What is generally required for acceptance? Not
meant critically, just interested

On Wed, 16 Jan 2019, 8:01 pm Mario Blažević  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

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Mario Blažević]

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