[Haskell-cafe] Smarter do notation

Daniel Peebles pumpkingod at gmail.com
Sun Sep 4 04:34:35 CEST 2011

Hi all,

I was wondering what people thought of a smarter do notation. Currently,
there's an almost trivial desugaring of do notation into (>>=), (>>), and
fail (grr!) which seem to naturally imply Monads (although oddly enough,
return is never used in the desugaring). The simplicity of the desugaring is
nice, but in many cases people write monadic code that could easily have
been Applicative.

For example, if I write in a do block:

x <- action1
y <- action2
z <- action3
return (f x y z)

that doesn't require any of the context-sensitivty that Monads give you, and
could be processed a lot more efficiently by a clever Applicative instance
(a parser, for instance). Furthermore, if return values are ignored, we
could use the (<$), (<*), or (*>) operators which could make the whole thing
even more efficient in some instances.

Of course, the fact that the return method is explicitly mentioned in my
example suggests that unless we do some real voodoo, Applicative would have
to be a superclass of Monad for this to make sense. But with the new default
superclass instances people are talking about in GHC, that doesn't seem too
unlikely in the near future.

On the implementation side, it seems fairly straightforward to determine
whether Applicative is enough for a given do block. Does anyone have any
opinions on whether this would be a worthwhile change? The downsides seem to
be a more complex desugaring pass (although still something most people
could perform in their heads), and some instability with making small
changes to the code in a do block. If you make a small change to use a
variable before the return, you instantly jump from Applicative to Monad and
might break types in your program. I'm not convinced that's necessary a bad
thing, though.

Any thoughts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110903/fbd42d0d/attachment.htm>

More information about the Haskell-Cafe mailing list