LAST CALL to comment on the Applicative/Monad Proposal

Mario Blažević blamario at ciktel.net
Tue Dec 18 03:17:03 UTC 2018


While you're reviewing AMP, please take a bit of time to also comment on 
the related new MonadPlus excise proposal at 
https://github.com/haskell/rfcs/pull/23

The proposal is very short so it should be an easy decision. Thank you.


On 2018-12-15 6:46 p.m., Mario Blažević wrote:
> The very first RFC created (https://github.com/haskell/rfcs/pull/1), 
> the Applicative/Monad Proposal, has now reached the Last Call stage. 
> In order to ground the discussion, I have taken some time to update 
> the Prelude and the text of the Haskell Report with its effects before 
> the call. The rendered report is available at 
> https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf 
> for your review.
>
>
> TL;DR:
>
> The proposed changes to the report add the latest design of the 
> Applicative and Alternative classes, but otherwise are intentionally 
> minimal. Any further modifications, like the MonadFail proposal or 
> moving return out of the Monad class, should be relegated to new RFCs.
>
>
> In some more detail, the changes are:
>
> 1. Applicative has been added as a subclass of Functor and superclass 
> of Monad, its methods and laws as currently defined in the base 
> library. The class and all its methods (pure, (<*>), (<*), (*>), and 
> liftA2) are exported from Prelude, but no other Applicative-related 
> functions (like liftA3) are.
>
> 2. The Functor class definition has been moved from module 
> Control.Monad to Control.Applicative in order to avoid circular 
> imports. Note that neither module is a part of the language 
> specification.
>
> 3. The Monad class has been left unmodified, apart from making 
> Applicative its superclass and adding  return a == pure a  as a law.
>
> 4. Alternative has been added to the Control.Applicative module, but 
> not to Prelude. This is the same treatment already meted to MonadPlus. 
> I'm unsure why MonadPlus even exists in the report, as it has no 
> relevance to the language specification, and I would gladly remove 
> both classes.
>
>
> Please take some time within the following three weeks (including some 
> extra allowance for the upcoming holiday breaks) to vote for or 
> against the proposal, or to leave a comment with suggestions for its 
> improvement.
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime




More information about the Haskell-prime mailing list