Re: Desugaring do-notation to Applicative

2 Oct 2013

      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

Re: Desugaring do-notation to Applicative

Iavor Diatchki