Re: Desugaring do-notation to Applicative

That is admittedly a pretty convincing example that we may want to provide either a LANGUAGE pragma or a different syntax to opt in. As a data point in this space, the version of the code I have in scheme calls the version of 'do' that permits applicative desugaring 'ado'. A port of it to Haskell with minor infelicities as a quasi-quoter can be found here: http://hackage.haskell.org/package/applicative-quoters-0.1.0.7/docs/Control-... However, that version uses an awkward hack to permit pattern matches to fail. -Edward On Wed, Oct 2, 2013 at 12:24 PM, Reid Barton wrote:

On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall wrote:

...

What about MonadComprehensions, by the way? The way I see it, it's an even better fit for Applicative because the return is implicit.

Yes, or ordinary list comprehensions for that matter.

But there is a danger in desugaring to Applicative: it may introduce too much sharing. Currently a program like "main = print $ length [ (x, y) | x <- [1..3], y <- [1..10000000] ]" (or the equivalent in do-notation) runs in constant space with either -O0 or -O -fno-full-laziness. If you desugar it to a form like "main = print $ length $ (,) <$> [1..3] <*> [1..10000000]", then no optimization flags will save you from a space leak.

It might be better to require explicit opt-in to the Applicative desugaring on a per-do-notation/comprehension basis. Of course, finding good syntax is always such a bother...

I'm definitely +1 on the overall idea though, I have a bunch of FRP code (where I have to use Applicative) that looks just like Dan Doel's second snippet and it's pretty horrid.

Regards, Reid Barton

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users