The soundness of this desugaring depends on the Applicatives and Monads following some of the laws. I think that's OK, personally, but this assumption should be made loudly somewhere, and the feature should be opt-in. As far as I know, GHC currently makes no assumptions about lawful class instances, and it might cause very strange failures if this suddenly were to change without opting in. Richard On Oct 1, 2013, at 9:49 AM, Simon Peyton-Jones wrote:

What happens when there are some monad things that precede the applicative bit:

do { x <- e1 ; y <- e2[x] ; z <- e3[x] ; h[y] ... }

does this convert to

do { x <- e1 ; (y,z) <- (,) <$> e1 <*> e2 ; h[y] ...

I assume so, but it would be good to say.

Also worth noting that join can be used to eliminate the tuple in arbitrary contexts, not only ones that end in return. Eg in the above example we can desugar to

e1 >>= \x -> join (\y z -> do { h[y]; ... }) e2 e3

I think. Again worth documenting if so.

I don't know whether the tuple-version or join-version would be more optimisation friendly.

Simon

| -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 01 October 2013 13:40 | To: glasgow-haskell-users | Subject: Desugaring do-notation to Applicative | | Following a couple of discussions at ICFP I've put together a proposal | for desugaring do-notation to Applicative: | | http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo | | I plan to implement this following the addition of Applicative as a | superclass of Monad, which is due to take place shortly after the 7.8 | branch is cut. | | Please discuss here, and I'll update the wiki page as necessary. | | Cheers, | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hello, I talked to Simon PJ about this at ICFP, and the use case that I'm interested in is the one where we infer an `Applicative` constraint instead of `Monad` for things of the form: do { x1 <- e1; x2 <- e2; ...; pure (f x1 x2 ...) } as long as the `xs` do not appear in the `es`. I am interested in this because I find it quite natural when writing `Applicative` computations. I am less keen on the more complex rules where part of the `do` notation is translated using the `Applicative` operations and part using `Monad` ones, mostly because explaining the translation is somewhat complex. Perhaps it is worth noting that if we just implemented the simple rule, we could still gain the benefits of using `Applicative` (e.g., efficiency) in a part of a monadic `do` by simply nesting the `do` blocks. For example: do x1 <- e1 -- The following part is `Applicative` (x2,x3) <- do x2 <- e2 x1 x3 <- e3 pure (x2,x3) f x1 x2 x3 Either way, I think that it'd be nice to have some version of this feature, thanks for implementing it! -Iavor On Tue, Oct 1, 2013 at 1:56 PM, Dag Odenhall wrote:

At least Control.Category has RULES that exploit the category laws for optimization. Whether this counts as *GHC* making assumptions, I don't know. :-)

On Tue, Oct 1, 2013 at 10:39 PM, Richard Eisenberg wrote:

...

The soundness of this desugaring depends on the Applicatives and Monads following some of the laws. I think that's OK, personally, but this assumption should be made loudly somewhere, and the feature should be opt-in. As far as I know, GHC currently makes no assumptions about lawful class instances, and it might cause very strange failures if this suddenly were to change without opting in.

Richard

On Oct 1, 2013, at 9:49 AM, Simon Peyton-Jones wrote:

...

What happens when there are some monad things that precede the applicative bit:

do { x <- e1 ; y <- e2[x] ; z <- e3[x] ; h[y] ... }

does this convert to

do { x <- e1 ; (y,z) <- (,) <$> e1 <*> e2 ; h[y] ...

I assume so, but it would be good to say.

Also worth noting that join can be used to eliminate the tuple in arbitrary contexts, not only ones that end in return. Eg in the above example we can desugar to

e1 >>= \x -> join (\y z -> do { h[y]; ... }) e2 e3

I think. Again worth documenting if so.

I don't know whether the tuple-version or join-version would be more optimisation friendly.

Simon

| -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 01 October 2013 13:40 | To: glasgow-haskell-users | Subject: Desugaring do-notation to Applicative | | Following a couple of discussions at ICFP I've put together a proposal | for desugaring do-notation to Applicative: | | http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo | | I plan to implement this following the addition of Applicative as a | superclass of Monad, which is due to take place shortly after the 7.8 | branch is cut. | | Please discuss here, and I'll update the wiki page as necessary. | | Cheers, | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

That isn't the only point. Applicative is also more general than Monad, in that more things are Applicatives than they are Monads, so this would enable to use a limited form of do-notation in more code. Also, Applicative interfaces are more amenable to some static optimizations, since the effects of an entire applicative expression can be known statically. - Jake On Wed, Oct 2, 2013 at 5:12 AM, wrote:

I thought the whole point of Applicative (at least, reading Connor’s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point **not** to resort to binds or do-notation.****

** **

That being said, I’m all for something that will promote the use of the name “pure” over “return”.****

** **

+1 for the Opt-In****

** **

Ph.****

** **

** **

** **

*From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Iavor Diatchki

****

** **

do x1 <- e1****

** **

-- The following part is `Applicative`****

(x2,x3) <- do x2 <- e2 x1****

x3 <- e3****

pure (x2,x3)****

** **

f x1 x2 x3****

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Perhaps an alternative for this could be extending McBride's idiom brackets: https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/idiom.html with a form of top-level let, something like: (| let x = expr1 y = expr2 z = expr3 in x*y + y*z + z*x |) = pure (\x y z -> x*y + y*z + z*x) <*> expr1 <*> expr2 <*> expr3 This seems like it would nicely commute with the desugaring of "let x = e1 in e2" into "(\x -> e2) e1": (| let x = expr1 y = expr2 z = expr3 in x*y + y*z + z*x |) = (| (\x y z -> x*y + y*z + z*x) expr1 expr2 expr3 |) = pure (\x y z -> x*y + y*z + z*x) <*> expr1 <*> expr2 <*> expr3 Regards, Dominique 2013/10/2 Dan Doel :

Unfortunately, in some cases, function application is just worse. For instance, when the result is a complex arithmetic expression:

do x <- expr1; y <- expr2; z <- expr3; return $ x*y + y*z + z*x

In cases like this, you have pretty much no choice but to name intermediate variables, because the alternative is incomprehensible. But applicative notation:

(\x y z -> x*y + y*z + z*x) <$> expr1 <*> expr2 <*> expr3

moves the variable bindings away from the expressions they're bound to, and we require extra parentheses to delimit things, and possibly more.

Desugaring the above do into applicative is comparable to use of plain let in scheme (monad do is let*, mdo was letrec). And sometimes, let is nice, even if it has an equivalent lambda form.

And as Jake mentioned, syntax isn't the only reason for Applicative. Otherwise it'd just be some alternate names for functions involving Monad.

On Wed, Oct 2, 2013 at 5:12 AM, wrote:

...

I thought the whole point of Applicative (at least, reading Connor’s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation.

That being said, I’m all for something that will promote the use of the name “pure” over “return”.

+1 for the Opt-In

Ph.

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Iavor Diatchki

do x1 <- e1

-- The following part is `Applicative`

(x2,x3) <- do x2 <- e2 x1

x3 <- e3

pure (x2,x3)

f x1 x2 x3

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall wrote:

What about MonadComprehensions, by the way? The way I see it, it's an even better fit for Applicative because the return is implicit.

Yes, or ordinary list comprehensions for that matter. But there is a danger in desugaring to Applicative: it may introduce too much sharing. Currently a program like "main = print $ length [ (x, y) | x <- [1..3], y <- [1..10000000] ]" (or the equivalent in do-notation) runs in constant space with either -O0 or -O -fno-full-laziness. If you desugar it to a form like "main = print $ length $ (,) <$> [1..3] <*> [1..10000000]", then no optimization flags will save you from a space leak. It might be better to require explicit opt-in to the Applicative desugaring on a per-do-notation/comprehension basis. Of course, finding good syntax is always such a bother... I'm definitely +1 on the overall idea though, I have a bunch of FRP code (where I have to use Applicative) that looks just like Dan Doel's second snippet and it's pretty horrid. Regards, Reid Barton

On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett wrote:

That is admittedly a pretty convincing example that we may want to provide either a LANGUAGE pragma or a different syntax to opt in.

I suppose the Applicative desugaring can reliably be disabled by adding a syntactic dependency on previous variables, like [ (x, y) | x <- [1..3], y <- const [1..10000000] x ] so as far as I'm concerned it's sufficient if the Applicative desugaring is opt-in on a per-module basis, without a separate syntax for Applicative vs Monad do-notation/comprehensions. Those who opt in can be expected to understand and deal with this sharing issue if it affects them. (They pretty much have to understand it already, if they are compiling with optimizations.) Regards, Reid Barton

I think there are 2 use cases: * explicit ado is best, it communicates the intent of the writer and can give better error messages * we want users to write code in a do style and the implementer to make it applicative if possible So we probably need to accommodate 2 use cases with 2 extensions, one that enables `ado` and have another extension that will automatically work with `do`. Another advantage of this approach is that `ado` should be simpler to get started. On Wed, Oct 2, 2013 at 1:27 PM, Bardur Arantsson wrote:

...

On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett wrote:

...

That is admittedly a pretty convincing example that we may want to

On 2013-10-02 20:13, Reid Barton wrote: provide

...

...

either a LANGUAGE pragma or a different syntax to opt in.

I suppose the Applicative desugaring can reliably be disabled by adding a syntactic dependency on previous variables, like

[ (x, y) | x <- [1..3], y <- const [1..10000000] x ]

so as far as I'm concerned it's sufficient if the Applicative desugaring is opt-in on a per-module basis, without a separate syntax for Applicative vs Monad do-notation/comprehensions.

That seems like an easily-overlooked and IMO too-subtle way to saying "hey, GHC, don't do the applicative desugaring in this particular place".

...

Those who opt in can be expected to understand and deal with this sharing issue if it affects them. (They pretty much have to understand it already, if they are compiling with optimizations.)

I don't think it's a about understanding -- not all READERS of the code could necessarily be expected to have the same expertise (or level of carefulness) as the writer of the code. This could lead to subtle bugs arising during maintenance. Therefore it would seem a good idea to me to be explicit about the distiction with "ado" vs. "do" (or similar) -- not sure about how the distincation should be made in the comprehensions, but I'm sure *something* explicit can be worked out. I mean, is a single extra letter really a burden?

Regards,

Bardur

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users