[Haskell-cafe] Smarter do notation

[Daniel Peebles]

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 at 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 at 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110904/3f01395e/attachment.htm>