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.holzensp...@utwente.nl mailto:p.k.f.holzensp...@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-boun...@haskell.org mailto:glasgow-haskell-users-boun...@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@haskell.org mailto: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
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 marlo...@gmail.com mailto:marlo...@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@haskell.__org mailto:Glasgow-haskell-users@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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Desugaring do-notation to Applicative
Wonderful! On Fri, Oct 11, 2013 at 11:57 AM, Simon Marlow marlo...@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 marlo...@gmail.com mailto:marlo...@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/ApplicativeDohttp://ghc.haskell.org/trac/__ghc/wiki/ApplicativeDo http://ghc.haskell.org/trac/**ghc/wiki/ApplicativeDohttp://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@haskell.**__org mailto:Glasgow-haskell-users@**haskell.orgGlasgow-haskell-users@haskell.org http://www.haskell.org/__**mailman/listinfo/glasgow-__**haskell-usershttp://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://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
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 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
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-boun...@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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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.holzensp...@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-boun...@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@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
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.holzensp...@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-boun...@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@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
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 marlo...@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/ApplicativeDohttp://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@haskell.**org Glasgow-haskell-users@haskell.org http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://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
Re: Desugaring do-notation to Applicative
On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall dag.odenh...@gmail.comwrote: 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..1000] ] (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..1000], 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
RE: Desugaring do-notation to Applicative
While I really like applicative notation, sometimes naming intermediate results can make code a lot more readable. So I think supporting applicative do-notation would be beneficial. Neil On 02/10/13 07:00, p.k.f.holzenspies wrote: -- Message: 1 Date: Wed, 2 Oct 2013 09:12:26 + From: p.k.f.holzensp...@utwente.nl To: iavor.diatc...@gmail.com, dag.odenh...@gmail.com Cc: marlo...@gmail.com, glasgow-haskell-users@haskell.org, simo...@microsoft.com Subject: RE: Desugaring do-notation to Applicative Message-ID: e7f535b24a47d747a07d46c0aa82d43d0ab17...@exmbx21.ad.utwente.nl Content-Type: text/plain; charset=utf-8 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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-Applicative-QQ-ADo.html 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 rwbar...@gmail.com wrote: On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall dag.odenh...@gmail.comwrote: 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..1000] ] (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..1000], 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Desugaring do-notation to Applicative
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. 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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.d...@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.holzensp...@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-boun...@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@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 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
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
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@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@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
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
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-
| boun...@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@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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 e...@cis.upenn.eduwrote:
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-
| boun...@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@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
___
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
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.odenh...@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 e...@cis.upenn.eduwrote:
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-
| boun...@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@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
___
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
