Yeah, I use SHE and her idiom brackets for several of my projects, but there are many cases in which they're awkward too.<div><br></div><div>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.<br>
<br><div class="gmail_quote">On Sun, Sep 4, 2011 at 1:32 PM, Dominique Devriese <span dir="ltr"><<a href="mailto:dominique.devriese@cs.kuleuven.be">dominique.devriese@cs.kuleuven.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It's not the same as what you propose, but it's related, so for<br>
discussion, I just want to point out idiom brackets (an analog for<br>
do-notation for Applicative functors) which have been introduced in<br>
some Haskell-related languages. Examples are Idris<br>
(<a href="http://www.cs.st-andrews.ac.uk/~eb/Idris/donotation.html" target="_blank">http://www.cs.st-andrews.ac.uk/~eb/Idris/donotation.html</a>) and SHE<br>
(<a href="http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html" target="_blank">http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html</a>).<br>
<br>
Dominique<br>
<br>
2011/9/4 Daniel Peebles <<a href="mailto:pumpkingod@gmail.com">pumpkingod@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Hi all,<br>
> I was wondering what people thought of a smarter do notation. Currently,<br>
> there's an almost trivial desugaring of do notation into (>>=), (>>), and<br>
> fail (grr!) which seem to naturally imply Monads (although oddly enough,<br>
> return is never used in the desugaring). The simplicity of the desugaring is<br>
> nice, but in many cases people write monadic code that could easily have<br>
> been Applicative.<br>
> For example, if I write in a do block:<br>
> x <- action1<br>
> y <- action2<br>
> z <- action3<br>
> return (f x y z)<br>
> that doesn't require any of the context-sensitivty that Monads give you, and<br>
> could be processed a lot more efficiently by a clever Applicative instance<br>
> (a parser, for instance). Furthermore, if return values are ignored, we<br>
> could use the (<$), (<*), or (*>) operators which could make the whole thing<br>
> even more efficient in some instances.<br>
> Of course, the fact that the return method is explicitly mentioned in my<br>
> example suggests that unless we do some real voodoo, Applicative would have<br>
> to be a superclass of Monad for this to make sense. But with the new default<br>
> superclass instances people are talking about in GHC, that doesn't seem too<br>
> unlikely in the near future.<br>
> On the implementation side, it seems fairly straightforward to determine<br>
> whether Applicative is enough for a given do block. Does anyone have any<br>
> opinions on whether this would be a worthwhile change? The downsides seem to<br>
> be a more complex desugaring pass (although still something most people<br>
> could perform in their heads), and some instability with making small<br>
> changes to the code in a do block. If you make a small change to use a<br>
> variable before the return, you instantly jump from Applicative to Monad and<br>
> might break types in your program. I'm not convinced that's necessary a bad<br>
> thing, though.<br>
> Any thoughts?<br>
> Thanks,<br>
> Dan<br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>