Re: 2014 Applicative => Monad proposal
(+1) I would like to see this proposal go forward. Though I've previously expressed a preference for Monad/Applicative changes being ratified as part of a language revision - I've changed my mind in the last few days. Thanks to both David in this thread and Simon Peyton-Jones in the "Making Decisions" thread for constructive proposals, that hopefully will both see fruition.
On 2013-05-23 23:34, Stephen Tetley wrote:
Though I've previously expressed a preference for Monad/Applicative changes being ratified as part of a language revision - I've changed my mind in the last few days.
I don't think you even need to change your preference here: the key idea of this proposal is that it is possible to be applied almost entirely without changing the standard. Once the Haskell landscape has complying code, the step from recommending to enforcing the AMP is a very small one. David
+1 for AMP.
I hope it makes it this time.
On 23 May 2013 23:44, David Luposchainsky
On 2013-05-23 23:34, Stephen Tetley wrote:
Though I've previously expressed a preference for Monad/Applicative changes being ratified as part of a language revision - I've changed my mind in the last few days.
I don't think you even need to change your preference here: the key idea of this proposal is that it is possible to be applied almost entirely without changing the standard. Once the Haskell landscape has complying code, the step from recommending to enforcing the AMP is a very small one.
One interesting question about the Haskell Report is if we should generalize the following translation: do {e;stmts}=e >> do {stmts} to: do {e;stmts}=e *> do {stmts} Bas
+1
On Thu, May 23, 2013 at 6:01 PM, Bas van Dijk
One interesting question about the Haskell Report is if we should generalize the following translation:
do {e;stmts}=e >> do {stmts}
to:
do {e;stmts}=e *> do {stmts}
There are other situations where one can desugar to just applicatives that I wouldn't mind seeing. But they of course haven't been implemented anywhere. For instance, the comprehension: [ e1 | x <- e2, y <- e3, ... ] can be translated to: (\x y ... -> e1) <$> e2 <*> ... so long as x, y ... aren't free in e2, e3 .... I don't think any of this should be considered until the details have been worked out and implemented, of course.
participants (4)
-
Bas van Dijk -
Dan Doel -
David Luposchainsky -
Stephen Tetley