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 s...@scientician.netwrote:
On 2013-10-02 20:13, Reid Barton wrote:
On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett ekm...@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..1000] 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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
