Yeah, I use SHE and her idiom brackets for several of my projects, but there are many cases in which they're awkward too.

Another consideration about the "monad" comprehensions is that unbound (i.e., with no <-) statements in a monad comprehension are treated as MonadPlus guards, so the applicative <* and *> wouldn't really have a clean place to go.

On Sun, Sep 4, 2011 at 1:32 PM, Dominique Devriese <dominique.devriese@cs.kuleuven.be> wrote:
It's not the same as what you propose, but it's related, so for
discussion, I just want to point out idiom brackets (an analog for
do-notation for Applicative functors) which have been introduced in
some Haskell-related languages. Examples are Idris
(http://www.cs.st-andrews.ac.uk/~eb/Idris/donotation.html) and SHE
(http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html).

Dominique

2011/9/4 Daniel Peebles <pumpkingod@gmail.com>:
> 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?
> Thanks,
> Dan
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>