Simon Marlow | 1 Oct 14:39 2013
Picon

Desugaring do-notation to Applicative

Following a couple of discussions at ICFP I've put together a proposal 
for desugaring do-notation to Applicative:

   http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo

I plan to implement this following the addition of Applicative as a 
superclass of Monad, which is due to take place shortly after the 7.8 
branch is cut.

Please discuss here, and I'll update the wiki page as necessary.

Cheers,
Simon
Simon Peyton-Jones | 1 Oct 15:49 2013
Picon

RE: Desugaring do-notation to Applicative

What happens when there are some monad things that precede the applicative bit:

do { x <- e1
   ; y <- e2[x]
   ; z <- e3[x]
   ; h[y]
   ... }

does this convert to

do { x <- e1
   ; (y,z) <- (,) <$> e1 <*> e2
   ; h[y]
   ...

I assume so, but it would be good to say.

Also worth noting that join can be used to eliminate the tuple in arbitrary contexts, not only ones that end
in return.  Eg in the above example we can desugar to 

	e1 >>= \x ->
	join (\y z -> do { h[y]; ... })
           e2 e3

I think.  Again worth documenting if so.

I don't know whether the tuple-version or join-version would be more optimisation friendly.

Simon

(Continue reading)

Richard Eisenberg | 1 Oct 22:39 2013

Re: Desugaring do-notation to Applicative

The soundness of this desugaring depends on the Applicatives and Monads following some of the laws. I think
that's OK, personally, but this assumption should be made loudly somewhere, and the feature should be
opt-in. As far as I know, GHC currently makes no assumptions about lawful class instances, and it might
cause very strange failures if this suddenly were to change without opting in.

Richard

On Oct 1, 2013, at 9:49 AM, Simon Peyton-Jones wrote:

> What happens when there are some monad things that precede the applicative bit:
> 
> do { x <- e1
>   ; y <- e2[x]
>   ; z <- e3[x]
>   ; h[y]
>   ... }
> 
> does this convert to
> 
> do { x <- e1
>   ; (y,z) <- (,) <$> e1 <*> e2
>   ; h[y]
>   ...
> 
> I assume so, but it would be good to say.
> 
> 
> Also worth noting that join can be used to eliminate the tuple in arbitrary contexts, not only ones that end
in return.  Eg in the above example we can desugar to 
> 
(Continue reading)

Dag Odenhall | 1 Oct 22:56 2013
Picon

Re: Desugaring do-notation to Applicative

At least Control.Category has RULES that exploit the category laws for optimization. Whether this counts as GHC making assumptions, I don't know. :-)



On Tue, Oct 1, 2013 at 10:39 PM, Richard Eisenberg <eir <at> cis.upenn.edu> wrote:
The soundness of this desugaring depends on the Applicatives and Monads following some of the laws. I think that's OK, personally, but this assumption should be made loudly somewhere, and the feature should be opt-in. As far as I know, GHC currently makes no assumptions about lawful class instances, and it might cause very strange failures if this suddenly were to change without opting in.

Richard

On Oct 1, 2013, at 9:49 AM, Simon Peyton-Jones wrote:

> What happens when there are some monad things that precede the applicative bit:
>
> do { x <- e1
>   ; y <- e2[x]
>   ; z <- e3[x]
>   ; h[y]
>   ... }
>
> does this convert to
>
> do { x <- e1
>   ; (y,z) <- (,) <$> e1 <*> e2
>   ; h[y]
>   ...
>
> I assume so, but it would be good to say.
>
>
> Also worth noting that join can be used to eliminate the tuple in arbitrary contexts, not only ones that end in return.  Eg in the above example we can desugar to
>
>       e1 >>= \x ->
>       join (\y z -> do { h[y]; ... })
>           e2 e3
>
> I think.  Again worth documenting if so.
>
> I don't know whether the tuple-version or join-version would be more optimisation friendly.
>
> Simon
>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | bounces <at> haskell.org] On Behalf Of Simon Marlow
> | Sent: 01 October 2013 13:40
> | To: glasgow-haskell-users
> | Subject: Desugaring do-notation to Applicative
> |
> | Following a couple of discussions at ICFP I've put together a proposal
> | for desugaring do-notation to Applicative:
> |
> |    http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
> |
> | I plan to implement this following the addition of Applicative as a
> | superclass of Monad, which is due to take place shortly after the 7.8
> | branch is cut.
> |
> | Please discuss here, and I'll update the wiki page as necessary.
> |
> | Cheers,
> | Simon
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users <at> haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Iavor Diatchki | 2 Oct 07:31 2013
Picon

Re: Desugaring do-notation to Applicative

Hello,

I talked to Simon PJ about this at ICFP, and the use case that I'm interested in is the one where we infer an `Applicative` constraint instead of `Monad` for things of the form:

do { x1 <- e1; x2 <- e2; ...; pure (f x1 x2 ...) }

as long as the `xs` do not appear in the `es`.   I am interested in this because I find it quite natural when writing `Applicative` computations.

I am less keen on the more complex rules where part of the `do` notation is translated using the `Applicative` operations and part using `Monad` ones, mostly because explaining the translation is somewhat complex.  Perhaps it is worth noting that if we just implemented the simple rule, we could still gain the benefits of using `Applicative` (e.g., efficiency) in a part of a monadic `do` by simply nesting the `do` blocks.  For example:

do x1 <- e1

   -- The following part is `Applicative`
   (x2,x3) <- do x2 <- e2 x1
                 x3 <- e3
                 pure (x2,x3)

   f x1 x2 x3

Either way, I think that it'd be nice to have some version of this feature, thanks for implementing it!

-Iavor



On Tue, Oct 1, 2013 at 1:56 PM, Dag Odenhall <dag.odenhall <at> gmail.com> wrote:

At least Control.Category has RULES that exploit the category laws for optimization. Whether this counts as GHC making assumptions, I don't know. :-)



On Tue, Oct 1, 2013 at 10:39 PM, Richard Eisenberg <eir <at> cis.upenn.edu> wrote:
The soundness of this desugaring depends on the Applicatives and Monads following some of the laws. I think that's OK, personally, but this assumption should be made loudly somewhere, and the feature should be opt-in. As far as I know, GHC currently makes no assumptions about lawful class instances, and it might cause very strange failures if this suddenly were to change without opting in.

Richard

On Oct 1, 2013, at 9:49 AM, Simon Peyton-Jones wrote:

> What happens when there are some monad things that precede the applicative bit:
>
> do { x <- e1
>   ; y <- e2[x]
>   ; z <- e3[x]
>   ; h[y]
>   ... }
>
> does this convert to
>
> do { x <- e1
>   ; (y,z) <- (,) <$> e1 <*> e2
>   ; h[y]
>   ...
>
> I assume so, but it would be good to say.
>
>
> Also worth noting that join can be used to eliminate the tuple in arbitrary contexts, not only ones that end in return.  Eg in the above example we can desugar to
>
>       e1 >>= \x ->
>       join (\y z -> do { h[y]; ... })
>           e2 e3
>
> I think.  Again worth documenting if so.
>
> I don't know whether the tuple-version or join-version would be more optimisation friendly.
>
> Simon
>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | bounces <at> haskell.org] On Behalf Of Simon Marlow
> | Sent: 01 October 2013 13:40
> | To: glasgow-haskell-users
> | Subject: Desugaring do-notation to Applicative
> |
> | Following a couple of discussions at ICFP I've put together a proposal
> | for desugaring do-notation to Applicative:
> |
> |    http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
> |
> | I plan to implement this following the addition of Applicative as a
> | superclass of Monad, which is due to take place shortly after the 7.8
> | branch is cut.
> |
> | Please discuss here, and I'll update the wiki page as necessary.
> |
> | Cheers,
> | Simon
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users <at> haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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


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


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
p.k.f.holzenspies | 2 Oct 11:12 2013
Picon
Picon

RE: Desugaring do-notation to Applicative

I thought the whole point of Applicative (at least, reading Connor’s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation.

 

That being said, I’m all for something that will promote the use of the name “pure” over “return”.

 

+1 for the Opt-In

 

Ph.

 

 

 

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces <at> haskell.org] On Behalf Of Iavor Diatchki

 

do x1 <- e1

 

   -- The following part is `Applicative`

   (x2,x3) <- do x2 <- e2 x1

                 x3 <- e3

                 pure (x2,x3)

 

   f x1 x2 x3

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Jake McArthur | 2 Oct 13:48 2013
Picon

Re: Desugaring do-notation to Applicative

That isn't the only point. Applicative is also more general than Monad, in that more things are Applicatives than they are Monads, so this would enable to use a limited form of do-notation in more code. Also, Applicative interfaces are more amenable to some static optimizations, since the effects of an entire applicative expression can be known statically.

- Jake


On Wed, Oct 2, 2013 at 5:12 AM, <p.k.f.holzenspies <at> utwente.nl> wrote:

I thought the whole point of Applicative (at least, reading Connor’s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation.

 

That being said, I’m all for something that will promote the use of the name “pure” over “return”.

 

+1 for the Opt-In

 

Ph.

 

 

 

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces <at> haskell.org] On Behalf Of Iavor Diatchki

 

do x1 <- e1

 

   -- The following part is `Applicative`

   (x2,x3) <- do x2 <- e2 x1

                 x3 <- e3

                 pure (x2,x3)

 

   f x1 x2 x3


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


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Dan Doel | 2 Oct 17:09 2013
Picon

Re: Desugaring do-notation to Applicative

Unfortunately, in some cases, function application is just worse. For instance, when the result is a complex arithmetic expression:

    do x <- expr1; y <- expr2; z <- expr3; return $ x*y + y*z + z*x

In cases like this, you have pretty much no choice but to name intermediate variables, because the alternative is incomprehensible. But applicative notation:

    (\x y z -> x*y + y*z + z*x) <$> expr1 <*> expr2 <*> expr3

moves the variable bindings away from the expressions they're bound to, and we require extra parentheses to delimit things, and possibly more.

Desugaring the above do into applicative is comparable to use of plain let in scheme (monad do is let*, mdo was letrec). And sometimes, let is nice, even if it has an equivalent lambda form.

And as Jake mentioned, syntax isn't the only reason for Applicative. Otherwise it'd just be some alternate names for functions involving Monad.



On Wed, Oct 2, 2013 at 5:12 AM, <p.k.f.holzenspies <at> utwente.nl> wrote:

I thought the whole point of Applicative (at least, reading Connor’s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation.

 

That being said, I’m all for something that will promote the use of the name “pure” over “return”.

 

+1 for the Opt-In

 

Ph.

 

 

 

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces <at> haskell.org] On Behalf Of Iavor Diatchki

 

do x1 <- e1

 

   -- The following part is `Applicative`

   (x2,x3) <- do x2 <- e2 x1

                 x3 <- e3

                 pure (x2,x3)

 

   f x1 x2 x3


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


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Dominique Devriese | 2 Oct 20:34 2013
Picon

Re: Desugaring do-notation to Applicative

Perhaps an alternative for this could be extending McBride's idiom brackets:
  https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/idiom.html
with a form of top-level let, something like:

(| let x = expr1
        y = expr2
        z = expr3
   in x*y + y*z + z*x |)
=
pure (\x y z -> x*y + y*z + z*x) <*> expr1 <*> expr2 <*> expr3

This seems like it would nicely commute with the desugaring of "let x
= e1 in e2" into "(\x -> e2) e1":

(| let x = expr1
        y = expr2
        z = expr3
   in x*y + y*z + z*x |)
=
(| (\x y z -> x*y + y*z + z*x) expr1 expr2 expr3 |)
=
pure (\x y z -> x*y + y*z + z*x) <*> expr1 <*> expr2 <*> expr3

Regards,
Dominique

2013/10/2 Dan Doel <dan.doel <at> gmail.com>:
> Unfortunately, in some cases, function application is just worse. For
> instance, when the result is a complex arithmetic expression:
>
>     do x <- expr1; y <- expr2; z <- expr3; return $ x*y + y*z + z*x
>
> In cases like this, you have pretty much no choice but to name intermediate
> variables, because the alternative is incomprehensible. But applicative
> notation:
>
>     (\x y z -> x*y + y*z + z*x) <$> expr1 <*> expr2 <*> expr3
>
> moves the variable bindings away from the expressions they're bound to, and
> we require extra parentheses to delimit things, and possibly more.
>
> Desugaring the above do into applicative is comparable to use of plain let
> in scheme (monad do is let*, mdo was letrec). And sometimes, let is nice,
> even if it has an equivalent lambda form.
>
> And as Jake mentioned, syntax isn't the only reason for Applicative.
> Otherwise it'd just be some alternate names for functions involving Monad.
>
>
>
> On Wed, Oct 2, 2013 at 5:12 AM, <p.k.f.holzenspies <at> utwente.nl> wrote:
>>
>> I thought the whole point of Applicative (at least, reading Connor’s
>> paper) was to restore some function-application-style to the whole
>> effects-thing, i.e. it was the very point *not* to resort to binds or
>> do-notation.
>>
>>
>>
>> That being said, I’m all for something that will promote the use of the
>> name “pure” over “return”.
>>
>>
>>
>> +1 for the Opt-In
>>
>>
>>
>> Ph.
>>
>>
>>
>>
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:glasgow-haskell-users-bounces <at> haskell.org] On Behalf Of Iavor
>> Diatchki
>>
>>
>>
>> do x1 <- e1
>>
>>
>>
>>    -- The following part is `Applicative`
>>
>>    (x2,x3) <- do x2 <- e2 x1
>>
>>                  x3 <- e3
>>
>>                  pure (x2,x3)
>>
>>
>>
>>    f x1 x2 x3
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
Simon Marlow | 11 Oct 11:55 2013
Picon

Re: Desugaring do-notation to Applicative

Thanks for all the comments.  I've updated the wiki page, in particular 
to make it clear that Applictive do-notation would be an opt-in extension.

Cheers,
Simon

On 02/10/13 16:09, Dan Doel wrote:
> Unfortunately, in some cases, function application is just worse. For
> instance, when the result is a complex arithmetic expression:
>
>      do x <- expr1; y <- expr2; z <- expr3; return $ x*y + y*z + z*x
>
> In cases like this, you have pretty much no choice but to name
> intermediate variables, because the alternative is incomprehensible. But
> applicative notation:
>
>      (\x y z -> x*y + y*z + z*x) <$> expr1 <*> expr2 <*> expr3
>
> moves the variable bindings away from the expressions they're bound to,
> and we require extra parentheses to delimit things, and possibly more.
>
> Desugaring the above do into applicative is comparable to use of plain
> let in scheme (monad do is let*, mdo was letrec). And sometimes, let is
> nice, even if it has an equivalent lambda form.
>
> And as Jake mentioned, syntax isn't the only reason for Applicative.
> Otherwise it'd just be some alternate names for functions involving Monad.
>
>
>
> On Wed, Oct 2, 2013 at 5:12 AM, <p.k.f.holzenspies <at> utwente.nl
> <mailto:p.k.f.holzenspies <at> utwente.nl>> wrote:
>
>     I thought the whole point of Applicative (at least, reading Connor’s
>     paper) was to restore some function-application-style to the whole
>     effects-thing, i.e. it was the very point **not** to resort to binds
>     or do-notation.____
>
>     __ __
>
>     That being said, I’m all for something that will promote the use of
>     the name “pure” over “return”.____
>
>     __ __
>
>     +1 for the Opt-In____
>
>     __ __
>
>     Ph.____
>
>     __ __
>
>     __ __
>
>     __ __
>
>     *From:*Glasgow-haskell-users
>     [mailto:glasgow-haskell-users-bounces <at> haskell.org
>     <mailto:glasgow-haskell-users-bounces <at> haskell.org>] *On Behalf Of
>     *Iavor Diatchki
>
>     ____
>
>     __ __
>
>     do x1 <- e1____
>
>     __ __
>
>         -- The following part is `Applicative`____
>
>         (x2,x3) <- do x2 <- e2 x1____
>
>                       x3 <- e3____
>
>                       pure (x2,x3)____
>
>     __ __
>
>         f x1 x2 x3____
>
>
>     _______________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users <at> haskell.org
>     <mailto:Glasgow-haskell-users <at> haskell.org>
>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
Dag Odenhall | 2 Oct 18:01 2013
Picon

Re: Desugaring do-notation to Applicative

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



On Tue, Oct 1, 2013 at 2:39 PM, Simon Marlow <marlowsd <at> gmail.com> wrote:
Following a couple of discussions at ICFP I've put together a proposal for desugaring do-notation to Applicative:

  http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo

I plan to implement this following the addition of Applicative as a superclass of Monad, which is due to take place shortly after the 7.8 branch is cut.

Please discuss here, and I'll update the wiki page as necessary.

Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reid Barton | 2 Oct 18:24 2013
Picon

Re: Desugaring do-notation to Applicative

On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall <dag.odenhall <at> gmail.com> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Edward Kmett | 2 Oct 19:50 2013
Picon

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:


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 <rwbarton <at> gmail.com> wrote:
On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall <dag.odenhall <at> gmail.com> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reid Barton | 2 Oct 20:13 2013
Picon

Re: Desugaring do-notation to Applicative

On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett <ekmett <at> 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. 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.)

Regards,
Reid Barton
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bardur Arantsson | 2 Oct 22:27 2013
Picon

Re: Desugaring do-notation to Applicative

On 2013-10-02 20:13, Reid Barton wrote:
> On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett <ekmett <at> 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
Greg Weber | 5 Oct 21:13 2013

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 <spam <at> scientician.net> wrote:
On 2013-10-02 20:13, Reid Barton wrote:
> On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett <ekmett <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Marlow | 11 Oct 11:57 2013
Picon

Re: Desugaring do-notation to Applicative

On 02/10/13 17:01, 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.

It would happen automatically, because a Monad comprehension is 
represented using the same abstract syntax as a do-expression internally.

Cheers,
Simon

>
>
> On Tue, Oct 1, 2013 at 2:39 PM, Simon Marlow <marlowsd <at> gmail.com
> <mailto:marlowsd <at> gmail.com>> wrote:
>
>     Following a couple of discussions at ICFP I've put together a
>     proposal for desugaring do-notation to Applicative:
>
>     http://ghc.haskell.org/trac/__ghc/wiki/ApplicativeDo
>     <http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo>
>
>     I plan to implement this following the addition of Applicative as a
>     superclass of Monad, which is due to take place shortly after the
>     7.8 branch is cut.
>
>     Please discuss here, and I'll update the wiki page as necessary.
>
>     Cheers,
>     Simon
>     _________________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users <at> haskell.__org
>     <mailto:Glasgow-haskell-users <at> haskell.org>
>     http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
>     <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>
>
Dag Odenhall | 11 Oct 14:44 2013
Picon

Re: Desugaring do-notation to Applicative

Wonderful!



On Fri, Oct 11, 2013 at 11:57 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
On 02/10/13 17:01, 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.

It would happen automatically, because a Monad comprehension is represented using the same abstract syntax as a do-expression internally.

Cheers,
Simon





On Tue, Oct 1, 2013 at 2:39 PM, Simon Marlow <marlowsd <at> gmail.com
<mailto:marlowsd <at> gmail.com>> wrote:

    Following a couple of discussions at ICFP I've put together a
    proposal for desugaring do-notation to Applicative:

    http://ghc.haskell.org/trac/__ghc/wiki/ApplicativeDo

    <http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo>

    I plan to implement this following the addition of Applicative as a
    superclass of Monad, which is due to take place shortly after the
    7.8 branch is cut.

    Please discuss here, and I'll update the wiki page as necessary.

    Cheers,
    Simon
    _________________________________________________
    Glasgow-haskell-users mailing list
    Glasgow-haskell-users <at> haskell.__org
    <mailto:Glasgow-haskell-users <at> haskell.org>
    http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
    <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>




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

Gmane