Re: Desugaring do-notation to Applicative

I think there are 2 use cases: * explicit ado is best, it communicates the intent of the writer and can give better error messages * we want users to write code in a do style and the implementer to make it applicative if possible So we probably need to accommodate 2 use cases with 2 extensions, one that enables `ado` and have another extension that will automatically work with `do`. Another advantage of this approach is that `ado` should be simpler to get started. On Wed, Oct 2, 2013 at 1:27 PM, Bardur Arantsson wrote:

...

On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett wrote:

...

That is admittedly a pretty convincing example that we may want to

On 2013-10-02 20:13, Reid Barton wrote: provide

...

...

either a LANGUAGE pragma or a different syntax to opt in.

I suppose the Applicative desugaring can reliably be disabled by adding a syntactic dependency on previous variables, like

[ (x, y) | x <- [1..3], y <- const [1..10000000] x ]

so as far as I'm concerned it's sufficient if the Applicative desugaring is opt-in on a per-module basis, without a separate syntax for Applicative vs Monad do-notation/comprehensions.

That seems like an easily-overlooked and IMO too-subtle way to saying "hey, GHC, don't do the applicative desugaring in this particular place".

...

Those who opt in can be expected to understand and deal with this sharing issue if it affects them. (They pretty much have to understand it already, if they are compiling with optimizations.)

I don't think it's a about understanding -- not all READERS of the code could necessarily be expected to have the same expertise (or level of carefulness) as the writer of the code. This could lead to subtle bugs arising during maintenance. Therefore it would seem a good idea to me to be explicit about the distiction with "ado" vs. "do" (or similar) -- not sure about how the distincation should be made in the comprehensions, but I'm sure *something* explicit can be worked out. I mean, is a single extra letter really a burden?

Regards,

Bardur

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