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 <spam@scientician.net> wrote:
On 2013-10-02 20:13, Reid Barton wrote:
> On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett <ekmett@gmail.com> wrote:
>
>> That is admittedly a pretty convincing example that we may want to 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