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
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
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
[GHC] #7157: 'let' keyword optional in do notation
#7157: 'let' keyword optional in do notation
--+-
Reporter: Oblosys | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1-rc1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Would it be possible to make the 'let' keyword in a do block optional? So
instead of
{{{
do ...
let x = exp1
y = exp2
z - exp3
...
}}}
you could simply write
{{{
do ...
x = exp1
y = exp2
z - exp3
...
}}}
Where each sequence of let-less bindings is put in a separate binding
group. I'm no parsing wizard, but I couldn't come up with any situations
in which this would cause ambiguity. To me, the let-less version is easier
on the eyes, more consistent with - bindings, and also makes it less of a
hassle to move stuff around.
The above probably also holds for list/monad comprehensions, but the
explicit let has never really bothered me there.
I've also posted the idea on Haskell cafe:
[http://www.mail-archive.com/haskell-cafe@haskell.org/msg100541.html]
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7157
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7157: 'let' keyword optional in do notation
#7157: 'let' keyword optional in do notation ---+ Reporter: Oblosys | Owner: Type: feature request | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.6.1-rc1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * difficulty: = Unknown * resolution: = wontfix Comment: Thanks for the suggestion. However, looking at http://www.haskell.org/pipermail/haskell- cafe/2012-August/102744.html this proposal seems to me to make the language more complex (in particular, which bindings share a scope is less transparent), for little or no gain, so I'm closing as wontfix. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7157#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
On 09-08-12 10:35, Tillmann Rendel wrote: Hi, Martijn Schrage wrote: Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. But it would be in line with - bindings in the do notation, so maybe it wouldn't feel so wrong. It would absolutely be the easiest solution to implement, since as far as I can see, it requires only a small change to the parser. However, I still think it will be too confusing to have bindings that look the same as everywhere else but have different binding group rules. Especially since there is no reason for it from a semantic point of view (unlike when you mix in a monadic - binding, after which it makes sense to have a new binding group.) Anyhow, I'll submit it as a GHC feature request and see what happens. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
But it would be in line with - bindings in the do notation, so maybe it wouldn't feel so wrong. I was about to post this exact example. do x - return 1 x - return x return x seems to work just fine (the answer is 1). I'd even be ok with =-in-do being non-recursive like - -- ryan On Thu, Aug 9, 2012 at 1:35 AM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Hi, Martijn Schrage wrote: Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. But it would be in line with - bindings in the do notation, so maybe it wouldn't feel so wrong. Tillmann __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
Hi, Martijn Schrage wrote: Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. But it would be in line with - bindings in the do notation, so maybe it wouldn't feel so wrong. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 'let' keyword optional in do notation?
Hi cafe, For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of do ... let x = exp1 y = exp2 z - exp3 ... you could simply write do ... x = exp1 y = exp2 z - exp3 ... Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
2012/8/8 Martijn Schrage mart...@oblomov.com: Hi cafe, For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of do ... let x = exp1 y = exp2 z - exp3 ... you could simply write do ... x = exp1 y = exp2 z - exp3 ... Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there. Hi, This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
On 08-08-12 17:27, Ertugrul Söylemez wrote: Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. To make it more clear, this is the transformation I propose: do ...-- not a let-less binding x1 = exp1 -- \ .. -- only let-less bindings xn = expn -- / ...-- not a let-less binding becomes do ... let x1 = exp1 .. xn = expn ... So main = do x = y y = 5 a = b b = 6 print (x, y, a, b) would put everything in the same binding group and compile successfully. To get Thu's example, you would write main = do x = y y = 5 let a = b let b = 6 print (x, y, a, b) The last let could even be left out. Cheers, Martijn The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: 'let' keyword optional in do notation?
-- Forwarded message -- From: David Feuer david.fe...@gmail.com Date: Wed, Aug 8, 2012 at 12:22 PM Subject: Re: [Haskell-cafe] 'let' keyword optional in do notation? To: Martijn Schrage mart...@oblomov.com Changing scoping rules based on whether things are right next to each other? No thanks. On Wed, Aug 8, 2012 at 11:44 AM, Martijn Schrage mart...@oblomov.com wrote: On 08-08-12 17:27, Ertugrul Söylemez wrote: Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. To make it more clear, this is the transformation I propose: do ...-- not a let-less binding x1 = exp1 -- \ .. -- only let-less bindings xn = expn -- / ...-- not a let-less binding becomes do ... let x1 = exp1 .. xn = expn ... So main = do x = y y = 5 a = b b = 6 print (x, y, a, b) would put everything in the same binding group and compile successfully. To get Thu's example, you would write main = do x = y y = 5 let a = b let b = 6 print (x, y, a, b) The last let could even be left out. Cheers, Martijn The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
On 08-08-12 19:01, Simon Hengel wrote: On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. However, having scope depend on things being next to each other (or rather, not having anything in between) is not new. Template Haskell declaration splices already cause separate binding groups for top-level declarations. Moreover, the new scope rule only holds for let-less bindings. If you use explicit lets nothing changes. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
Is it really so bad to use an explicit let when you need mutually recursive bindings? On Aug 8, 2012 1:51 PM, Martijn Schrage mart...@oblomov.com wrote: On 08-08-12 19:01, Simon Hengel wrote: On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. However, having scope depend on things being next to each other (or rather, not having anything in between) is not new. Template Haskell declaration splices already cause separate binding groups for top-level declarations. Moreover, the new scope rule only holds for let-less bindings. If you use explicit lets nothing changes. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
On Wed, Jun 13, 2012 at 12:56 AM, Roman Leshchinskiy r...@cse.unsw.edu.auwrote: It doesn't change the semantics of your program but it can make it significantly slower (or faster, as in this case). The various state hack related tickets on trac might give you an idea of what is happening here. I filed a bug: http://hackage.haskell.org/trac/ghc/ticket/6166 (I'd CC myself on an existing bug, but trac's search feature gives me tons of irrelevant hits.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
On 12 Jun 2012, at 12:52, Dmitry Dzhus d...@dzhus.org wrote: 12.06.2012, 01:08, Roman Leshchinskiy r...@cse.unsw.edu.au: perhaps the state hack is getting in the way. I don't quite understand the internals of this yet, but `-fno-state-hack` leads to great performance in both cases! How safe is that? It doesn't change the semantics of your program but it can make it significantly slower (or faster, as in this case). The various state hack related tickets on trac might give you an idea of what is happening here. We really need some proper arity analysis! Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
12.06.2012, 01:08, Roman Leshchinskiy r...@cse.unsw.edu.au: perhaps the state hack is getting in the way. I don't quite understand the internals of this yet, but `-fno-state-hack` leads to great performance in both cases! How safe is that? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
Hello everyone. I wonder why using do notation with `-` can ruin the performance. In essence the problem is that, for some action `f :: m Double`, running the code (in my case, `standard` from mwc-random). f for million times is fast but the code do v - f return v is slower about a hundred times. Consider this simple source where we generate an unboxed vector with million pseudo-random numbers: 8 - import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e' - VU.replicateM count $ standard g return () 8 - Being compiled with -O2, this runs for 0.052 s on my machine. Changing the replicateM line to use do notation brings the runtime down to 11.257 s! See below: 8 - import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e' - VU.replicateM count $ do v - standard g return v return () 8 - I don't quite understand why this happens. I'm using GHC 7.4.1 on Linux x86_64 system. Compiling *both* versions with profiling enabled changes runtime to 5.673 sec, which is exactly half the runtime of slow version without profiling, and this is awkward (double calculations occuring in do block?). Does anybody have an idea if this is a problem with my do, or with mwc-random, or with vector (my notation disallowing efficient unboxing?). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
Well, it's not do notation, since replacing standard g with standard g = return gives the same poor performance. I wonder if it has something to do with error checking. On 11 Jun 2012, at 13:38, Dmitry Dzhus wrote: Hello everyone. I wonder why using do notation with `-` can ruin the performance. In essence the problem is that, for some action `f :: m Double`, running the code (in my case, `standard` from mwc-random). f for million times is fast but the code do v - f return v is slower about a hundred times. Consider this simple source where we generate an unboxed vector with million pseudo-random numbers: 8 - import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e' - VU.replicateM count $ standard g return () 8 - Being compiled with -O2, this runs for 0.052 s on my machine. Changing the replicateM line to use do notation brings the runtime down to 11.257 s! See below: 8 - import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e' - VU.replicateM count $ do v - standard g return v return () 8 - I don't quite understand why this happens. I'm using GHC 7.4.1 on Linux x86_64 system. Compiling *both* versions with profiling enabled changes runtime to 5.673 sec, which is exactly half the runtime of slow version without profiling, and this is awkward (double calculations occuring in do block?). Does anybody have an idea if this is a problem with my do, or with mwc-random, or with vector (my notation disallowing efficient unboxing?). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
On 11 Jun 2012, at 10:38, Dmitry Dzhus wrote: main = do g - create e' - VU.replicateM count $ standard g return () In all likelhood, ghc is spotting that the value e' is not used, and that there are no side-effects, so it does not do anything at runtime. If you expand the action argument to replicateM, such that it uses do-notation instead, perhaps ghc can no longer prove the lack of side-effects, and so actually runs the computation before throwing away its result. When writing toy benchmarks in a lazy language, it is always important to understand to what extent your program _uses_ the data from a generator, or you are bound to get misleading performance measurements. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
11.06.2012, 14:17, Malcolm Wallace malcolm.wall...@me.com: that there are no side-effects There are — PRNG state is updated for RealWorld, that's why monadic replicateM is used. You can add something like print $ (VU.!) e 50 after e is bound and still get 0.057 sec with do-less version. This quite matches the performance claimed by mwc-random package and seems reasonable since modern hardware shouldn't have any problem with generating twenty million random variates in a second with one execution thread. Your note on laziness would be correct in case like -- 8 -- import qualified Data.Vector.Unboxed as VU import Data.Functor import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 1 main = do g - create e - return $ VU.replicate count (212.8506 :: Double) return () -- 8 --- Where unused `e` is truly left unevaluated (you could force it by matching with `!e` for example). Profiling indicates that random number sampling really occurs for both of original versions with `replicateM`, expectedly taking most of time: Mon Jun 11 14:24 2012 Time and Allocation Profiling Report (Final) slow-mwc-vector +RTS -p -RTS total time =5.45 secs (5453 ticks @ 1000 us, 1 processor) total alloc = 3,568,827,856 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc uniform2 System.Random.MWC45.0 53.7 uniformWord32 System.Random.MWC31.3 31.5 standard.loop System.Random.MWC.Distributions 4.11.1 uniform1 System.Random.MWC 3.94.5 nextIndex System.Random.MWC 3.61.4 uniform System.Random.MWC 2.83.3 uniform System.Random.MWC 2.51.4 wordsToDouble System.Random.MWC 2.10.5 I could drop do notation and go with the simpler version if I wanted just a vector of variates. But in reality I want a vector of tuples with random components: -- 8 -- import qualified Data.Vector.Unboxed as VU import Control.Monad import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e - VU.replicateM count $ do v1 - standard g v2 - standard g v3 - standard g return (v1, v2, v3) return () -- 8 --- which runs for the same 11.412 seconds. Since three times more variates are generated and run time stays the same, this implies that perhaps some optimizations of vector package interfere with mwc-random — can this be the case? This becomes quite a bottleneck in my application. On the other hand, mwc-random has `normal` function implemented as follows: -- 8 -- normal m s gen = do x - standard gen return $! m + s * x -- 8 --- which again uses explicit `do`. Both standard and normal are marked with INLINE. Now if I try to write -- 8 -- e - VU.replicateM count $ normal 0 1 g -- 8 --- in my test case, quite expectedly I get horrible performance of 11 seconds, even though I'm not using do myself. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance with do notation, mwc-random and unboxed vector
On 11/06/2012, at 10:38, Dmitry Dzhus wrote: Consider this simple source where we generate an unboxed vector with million pseudo-random numbers: 8 - import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e' - VU.replicateM count $ standard g return () 8 - Being compiled with -O2, this runs for 0.052 s on my machine. Changing the replicateM line to use do notation brings the runtime down to 11.257 s! See below: 8 - import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 100 main = do g - create e' - VU.replicateM count $ do v - standard g return v return () 8 - The former essentially generates this: replicateM n ((letrec f = ... in f) `cast` ...) and the latter this: replicateM n (\(s :: State# RealWorld) - (letrec f = ... in f s) `cast` ...) I'd look further into this but mwc-random just inlines too much stuff. Could you perhaps find a smaller example that doesn't use mwc-random? In any case, it looks like a GHC bug, perhaps the state hack is getting in the way. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi ---+ Reporter: mitar | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.1 Component: GHCi |Version: 7.0.3 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Testcase:| Blockedby: 4459 Blocking:|Related: ---+ Changes (by dterei): * cc: dterei (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell-cafe] Monad Laws and Do Notation
I've got this expression expression = do w - hello y - to you return w I wanna know how can I reduce it using monad laws -- View this message in context: http://haskell.1045720.n5.nabble.com/Monad-Laws-and-Do-Notation-tp4828598p4828598.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Laws and Do Notation
On 22 September 2011 11:46, diazepan spanishbizar...@yahoo.com wrote: I've got this expression expression = do w - hello y - to you return w I wanna know how can I reduce it using monad laws I don't think you can: the best you can do is minimise it with other monadic functions. The general case you can do something like discard from polyparse: http://hackage.haskell.org/packages/archive/polyparse/latest/doc/html/Text-ParserCombinators-Poly-Base.html#v:discard -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 02:38, Sebastian Fischer fisc...@nii.ac.jp wrote: These are important questions. I think there is a trade-off between supporting many cases and having a simple desugaring. We should find a sweet-spot where the desugaring is reasonably simple and covers most idiomatic cases. I have proposed a desugaring (in executable form) at https://gist.github.com/1194308. My desugaring aims for a slightly different design that does not try to detect return and instead treats the use of *, * and liftA2 purely as an optimisation - so any computation using do still generates a Monad constraint, but it may be desugared in a more efficient way than it is currently by using the Applicative combinators. (If you do want to support the type checker only generating requests for an Applicative constraint you could just insist that user code writes pure instead of return, in which case this would be quite easy to implement) There are still some interesting cases in my proposal. For example, if you have my second example: x - computation1 y - computation2 z - computation3 y computation4 x You might reasonably reassociate computation2 and computation3 together and desugar this to: liftA2 computation1 (computation2 = \y - computation3 y) = \(x, _z) - computation4 x But currently I desugar to: liftA2 computation1 computation2 = \(x, y) - computation3 y * computation4 x It wouldn't be too hard (and perhaps a nice exercise) to modify the desugaring to do this reassocation. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 08:35, Max Bolingbroke batterseapo...@hotmail.com wrote: (If you do want to support the type checker only generating requests for an Applicative constraint you could just insist that user code writes pure instead of return, in which case this would be quite easy to implement) I take back this parenthetical remark. Using pure instead of return only solves the most boring 1/2 of the problem :-) Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: do computation1 computation2 computation3 Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jp wrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 13:41, Sebastian Fischer fisc...@nii.ac.jp wrote: Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb - f ...) a b I think I remember someone saying that the one-at-a-time application of * inhibits certain optimisations. a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c I find (a b) confusing. The intended semantics seem to be effect a, then effect b, return result of a. That doesn't seem intuitive to me because it contradicts with the effect ordering of (=) which reverses the effect ordering of (=). We already have (*) and (*) for left-to-right effect ordering and pointed result selection. I understand that () = (*) apart from the Monad constraint, but I would prefer not to have () = (*). The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On Mon, Sep 5, 2011 at 10:19 PM, Thomas Schilling nomin...@googlemail.comwrote: a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb - f ...) a b I think I remember someone saying that the one-at-a-time application of * inhibits certain optimisations. liftA2 is defined via one-at-a-time application and cannot be redefined because it is no method of Applicative. Do you remember more details? I find (a b) confusing. The intended semantics seem to be effect a, then effect b, return result of a. Sorry, I didn't know that doesn't exist. I meant an operator with the meaning of * . Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Smarter do notation
-- Forwarded message -- From: Alberto G. Corona agocor...@gmail.com Date: 2011/9/5 Subject: Re: [Haskell-cafe] Smarter do notation To: Sebastian Fischer fisc...@nii.ac.jp Cc: Max Bolingbroke batterseapo...@hotmail.com, haskell-cafe@haskell.org The problem in the parallel distribution of monadic computations that may have been Applicative seems to be the operator But if Monad is defined as a subclass of applicative: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal then can be defined as () = (*) and parallelization should be pòssible ? Alberto 2011/9/5 Sebastian Fischer fisc...@nii.ac.jp Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
The problem in the parallel distribution of monadic computations that may have been Applicative seems to be the operator But if Monad is defined as a subclass of applicative: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal then can be defined as () = (*) and parallelization should be pòssible ? Alberto 2011/9/5 Sebastian Fischer fisc...@nii.ac.jp Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 15:49, Sebastian Fischer fisc...@nii.ac.jp wrote: On Mon, Sep 5, 2011 at 10:19 PM, Thomas Schilling nomin...@googlemail.com wrote: a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb - f ...) a b I think I remember someone saying that the one-at-a-time application of * inhibits certain optimisations. liftA2 is defined via one-at-a-time application and cannot be redefined because it is no method of Applicative. Do you remember more details? Good point. I can't find the original post, so I don't know what exactly the issue was (or maybe I'm misremembering). -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
It seems like complication for very slight advantage. Firstly, so far only UU Parsing and Trifecta appear to have optimized Applicative instances (does the optimization work for mixed Monad+Applicative parsers or only if the whole parser is Applicative?). Secondly if you want Applicative then you can write in the Applicative style, often as succinct as do-notation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On Sat, Sep 3, 2011 at 19:34, Daniel Peebles pumpkin...@gmail.com wrote: ... Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. ... One way to avoid explicitly mentioning return would be to use monad comprehension syntax, which uses return implicitly, instead of do notation. This also has the advantage of being new in GHC 7.2, rather than officially being part of Haskell 98/2010, and therefore being more amenable to various extensions (e.g. there are already extensions that use MonadPlus/MonadZip/MonadGroup). Applicative would probably still have to be a superclass of Monad, but the translation of this syntax is simpler. Shachaf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
Good idea! I'd forgotten about monad comprehensions. On Sun, Sep 4, 2011 at 3:11 AM, Shachaf Ben-Kiki shac...@gmail.com wrote: On Sat, Sep 3, 2011 at 19:34, Daniel Peebles pumpkin...@gmail.com wrote: ... Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. ... One way to avoid explicitly mentioning return would be to use monad comprehension syntax, which uses return implicitly, instead of do notation. This also has the advantage of being new in GHC 7.2, rather than officially being part of Haskell 98/2010, and therefore being more amenable to various extensions (e.g. there are already extensions that use MonadPlus/MonadZip/MonadGroup). Applicative would probably still have to be a superclass of Monad, but the translation of this syntax is simpler. Shachaf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On Sun, Sep 4, 2011 at 11:34 AM, Daniel Peebles pumpkin...@gmail.com wrote: I was wondering what people thought of a smarter do notation. I'd support it (for both do notation and monad comprehensions) once Applicative is a superclass of Monad. To me it looks light a slight complication for an advantage. Parsers are not the only examples that benefit. Implicitly parallel computations would be another because the arguments of * can be evaluated in parallel, those of = cannot. I think it's quite reasonable to try to desugar into the most general form. Something like do x - something return (bla x) could (and, I think, should) be desugared by using only Functor. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
I don't quite understand how this would work. For example, would it work
for these examples?
do x - blah
let foo = return
foo (f x) -- Using an alias of return/pure
do x - Just blah
Just (f x) -- another form of aliasing
do x - blah
return (g x x) -- could perhaps be turned into:
-- (\x - g x x) $ blah
do x - blah
y - return x
return (f y)-- = f $ blah ?
do x1 - foo1-- effect order must not be reversed
x2 - foo2
return (f x2 x1) -- note reversed order
-- multiple uses of applicative
do x1 - foo1
y - return (f x1)
x2 - foo2
y2 - return (g y x2)
return y2
So I guess it's possible to detect the pattern:
do x1 - foo1; ...; xN - fooN; [res -] return (f {x1..xN})
where {x1..xN} means x1..xN in some order and turn it into:
do [res -] (\x1..xN - f {x1..xN}) $ foo1 * ... * fooN
Open issues would be detection of the correct return-like thing. This is
why using monad comprehensions would help somewhat, but not fully because
it's still possible to put x - return y in the generators part. The
current desugaring of do-notation is very simple because it doesn't even
need to know about the monad laws. They are used implicitly by the
optimiser (e.g., foo = \x - return x is optimised to just foo after
inlining), but the desugarer doesn't need to know about them.
On 4 September 2011 03:34, Daniel Peebles pumpkin...@gmail.com wrote:
Hi all,
I was wondering what people thought of a smarter do notation. Currently,
there's an almost trivial desugaring of do notation into (=), (), and
fail (grr!) which seem to naturally imply Monads (although oddly enough,
return is never used in the desugaring). The simplicity of the desugaring is
nice, but in many cases people write monadic code that could easily have
been Applicative.
For example, if I write in a do block:
x - action1
y - action2
z - action3
return (f x y z)
that doesn't require any of the context-sensitivty that Monads give you,
and could be processed a lot more efficiently by a clever Applicative
instance (a parser, for instance). Furthermore, if return values are
ignored, we could use the ($), (*), or (*) operators which could make the
whole thing even more efficient in some instances.
Of course, the fact that the return method is explicitly mentioned in my
example suggests that unless we do some real voodoo, Applicative would have
to be a superclass of Monad for this to make sense. But with the new default
superclass instances people are talking about in GHC, that doesn't seem too
unlikely in the near future.
On the implementation side, it seems fairly straightforward to determine
whether Applicative is enough for a given do block. Does anyone have any
opinions on whether this would be a worthwhile change? The downsides seem to
be a more complex desugaring pass (although still something most people
could perform in their heads), and some instability with making small
changes to the code in a do block. If you make a small change to use a
variable before the return, you instantly jump from Applicative to Monad and
might break types in your program. I'm not convinced that's necessary a bad
thing, though.
Any thoughts?
Thanks,
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Push the envelope. Watch it bend.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
It's not the same as what you propose, but it's related, so for discussion, I just want to point out idiom brackets (an analog for do-notation for Applicative functors) which have been introduced in some Haskell-related languages. Examples are Idris (http://www.cs.st-andrews.ac.uk/~eb/Idris/donotation.html) and SHE (http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html). Dominique 2011/9/4 Daniel Peebles pumpkin...@gmail.com: Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (=), (), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the ($), (*), or (*) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On Sun, Sep 4, 2011 at 12:24 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote: Hi all, For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). What advantage is there in using Applicative rather than Monad for this? Does it _really_ lead to an efficiency increase? Forget about efficiency. What if I just want nicer syntax for some applicative stuff? For instance, this is applicative: do x - fx ; y - fy ; z - fz ; pure (x*x + y*y + z*z) But my only option for writing it to require just applicative is something like: (\x y z - x*x + y*y + z*z) $ fx * fy * fz Even if I had idiom brackets, it'd just be: (| (\x y z - x*x + y*y + z*z) fx fy fz |) Basically the situation boils down to this: applicatives admit a form of let as sugar: let x = ex y = ey z = ez in ... where the definitions are not recursive, and x is not in scope in ey and so on. This is desugarable to (in lambda calculus): (\x y z - ...) (ex) (ey) (ez) but we are currently forced to write in the latter style, because there's no support for the sugared syntax. So if anyone's looking for motivation, ask yourself if you've ever found let or where useful. And of course, in this case, we can't just beta reduce the desugared expression, because of the types involved. Comprehensions are rather like an expression with a where: [ x*x + y*y + z*z | x - ex, y - ey, z - ez ] -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
Yeah, I use SHE and her idiom brackets for several of my projects, but there are many cases in which they're awkward too. Another consideration about the monad comprehensions is that unbound (i.e., with no -) statements in a monad comprehension are treated as MonadPlus guards, so the applicative * and * wouldn't really have a clean place to go. On Sun, Sep 4, 2011 at 1:32 PM, Dominique Devriese dominique.devri...@cs.kuleuven.be wrote: It's not the same as what you propose, but it's related, so for discussion, I just want to point out idiom brackets (an analog for do-notation for Applicative functors) which have been introduced in some Haskell-related languages. Examples are Idris (http://www.cs.st-andrews.ac.uk/~eb/Idris/donotation.html) and SHE (http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html). Dominique 2011/9/4 Daniel Peebles pumpkin...@gmail.com: Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (=), (), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the ($), (*), or (*) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
These are important questions. I think there is a trade-off between
supporting many cases and having a simple desugaring. We should find a
sweet-spot where the desugaring is reasonably simple and covers most
idiomatic cases.
So I guess it's possible to detect the pattern:
do x1 - foo1; ...; xN - fooN; [res -] return (f {x1..xN})
where {x1..xN} means x1..xN in some order
Your third example shows that it's beneficial to also support duplicated
variables.
and turn it into:
do [res -] (\x1..xN - f {x1..xN}) $ foo1 * ... * fooN
I think this is a reasonably simple rule and it covers most idiomatic cases.
Open issues would be detection of the correct return-like thing.
I'm not sure how much return aliasing is worth supporting. In general it is
undecidable but we could add special cases for specialized returns (like
'Just' instead of 'return') depending on how difficult it is to implement.
The current desugaring of do-notation is very simple because it doesn't
even need to know about the monad laws.
Could you point out which monad law your proposed desugaring requires?
They are used implicitly by the optimiser (e.g., foo = \x - return x
is optimised to just foo after inlining), but the desugarer doesn't need
to know about them.
Does the inliner have RULES for monad laws or why would this work?
Sebastian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Smarter do notation
Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (=), (), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the ($), (*), or (*) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tasty. On 04/09/11 12:34, Daniel Peebles wrote: Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (=), (), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the ($), (*), or (*) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - -- Tony Morris http://tmorris.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOYuR6AAoJEPxHMY3rBz0PRE8IAMK8sQTzxtgRYeWcyP6JmWso Yl3eDUjny2uMSzIkifJix/t7tYuYG092H6SvA5VhgVBPQUd8LnZH/91X3PDGANBu ufjmCJLuN5+bgeNxvyzBHwz5iYM3GOkPhGvpJ3hJzYFIBlDVnVmMNoCDkki46/nq xJ/gsAIwfgpe4+Ll1LWu9DjVaQHb9nWmdBpTvpbXb7W+WEX7MHIsVsP/KysVFZkc XwPESJntb7oTHCcS3q1GEVTYdMFNKHlWOFcrdkGGQlegvwfjdt221oVDNToZi4z1 wJ268MdvXLSVIcU+JHLYxElQj6zrf2D51oQbHWLS/wlHRnpZHU5gtmrMTKvPvf8= =d1uz -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote: Hi all, For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). What advantage is there in using Applicative rather than Monad for this? Does it _really_ lead to an efficiency increase? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
With parsers, for example, it amounts to you have a context-free vs. a context-sensitive language. The functions hidden behind a monadic bind are effectively opaque to any sort of analysis, whereas the static structure of an applicative can be analyzed as much as you want. Ed Kmett does this in his trifecta parsing library (I think there's a couple of other libraries that also do this), but you have to use the applicative interface explicitly where possible to take advantage of the additional optimizations. This would also have benefits for other sorts of EDSLs, for the same reason. An applicative computation might for example be sparked and processed in parallel, whereas it's a lot harder (impossible) to do that if your structure isn't determined beforehand. On Sun, Sep 4, 2011 at 12:24 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote: Hi all, For example, if I write in a do block: x - action1 y - action2 z - action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). What advantage is there in using Applicative rather than Monad for this? Does it _really_ lead to an efficiency increase? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi --+- Reporter: mitar| Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.4.1 Component: GHCi |Version: 7.0.3 Resolution: | Keywords: Testcase: | Blockedby: 4459 Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Comment(by simonmar): Replying to [comment:37 daniel.is.fischer]: The test is in 7.0.3's testsuite, but the patch doesn't seem to be in: Just a testsuite bug, I don't think the testsuite was fully cleaned up in the stable branch prior to the release. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
--+-
Reporter: mitar| Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.4.1
Component: GHCi |Version: 7.0.3
Resolution: | Keywords:
Testcase: | Blockedby: 4459
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by daniel.is.fischer):
* version: 6.12.3 = 7.0.3
Comment:
The test is in 7.0.3's testsuite, but the patch doesn't seem to be in:
{{{
Actual stderr output differs from expected:
--- /dev/null 2011-04-02 10:56:44.408004588 +0200
+++ ./ghci/scripts/T4316.run.stderr.normalised 2011-04-02
17:00:07.0 +0200
@@ -0,0 +1,20 @@
+
+interactive:1:22: Empty 'do' construct
+
+interactive:1:6:
+No instance for (MonadState t0 IO)
+ arising from a use of `get'
+Possible fix: add an instance declaration for (MonadState t0 IO)
+In a stmt of an interactive GHCi command: i - get
+
+interactive:1:8: Empty 'do' construct
+
+interactive:1:7: Not in scope: `i'
+
+interactive:1:1: parse error on input `in'
+
+interactive:1:10: parse error (possibly incorrect indentation)
+
+interactive:1:7: parse error on input `-'
+
+interactive:1:7: parse error on input `-'
*** unexpected failure for T4316(ghci)
}}}
Trying :set +m in ghci results in {{{unknown option: 'm'}}}.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:37
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi --+- Reporter: mitar| Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.2.1 Component: GHCi |Version: 6.12.3 Resolution: | Keywords: Testcase: | Blockedby: 4459 Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by vivian): * blockedby: = 4459 Comment: Now that this ticket is back to mitar's original request. I think that this feature request could be implemented (creating a meta-interpreter) on the back of #4459. By introducing `bind` at the interpreter level we can invoke side-effects on a line-by-line basis within any monad construct. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi (was: Multiline commands in GHCi)
#4316: Interactive do notation in GHCi
--+-
Reporter: mitar| Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.2.1
Component: GHCi |Version: 6.12.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by simonmar):
* owner: vivian =
* status: patch = new
Comment:
Patches pushed, thanks for the contribution!
{{{
Thu Nov 4 22:13:08 PDT 2010 Vivian McPhail
haskell.vivian.mcph...@gmail.com
* multiline commands in GHCi #4316
This patch adds support for multiline commands in GHCi.
The first line of input is lexed. If there is an active
layout context once the lexer reaches the end of file, the
user is prompted for more input.
Multiline input is exited by an empty line and can be escaped
with a user interrupt.
Multiline mode is toggled with `:set +m`
Wed Jan 5 07:45:48 PST 2011 Simon Marlow marlo...@gmail.com
* fix up multi-line GHCi patch (#4316)
Thu Jan 6 01:31:52 PST 2011 Simon Marlow marlo...@gmail.com
* fix markup
}}}
Leaving the ticket open, and changing the summary back to what it was
previously.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:35
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
--+-
Reporter: mitar| Owner: vivian
Type: feature request | Status: new
Priority: normal | Milestone: 7.2.1
Component: GHCi |Version: 6.12.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Comment(by vivian):
I have a working patch that uses simonmar's idea of checking the lexer
state in alternative layout mode.
There are now a couple of questions with respect to the GHCi documentation
and #3984.
* First, any open context (basically 'do' and 'let') will trigger
multiline mode which is terminated by an empty (cf. blank) line. We can
also define something with a 'let':
{{{
Prelude let foo = Hello
Prelude|
Prelude foo
Hello
}}}
which does not have an associated 'in.' In all these cases, an extra empty
line is required. Where in the documentation should we put this feature?
* #3984 uses {{{:{}}} and {{{}:}}} to open and close a 'multiline' mode.
I think this is now obsolete '''except''' if we want to have a 'where'
clause.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:23
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Multiline commands in GHCi (was: Interactive do notation in GHCi)
#4316: Multiline commands in GHCi
--+-
Reporter: mitar| Owner: vivian
Type: feature request | Status: patch
Priority: normal | Milestone: 7.2.1
Component: GHCi |Version: 6.12.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by vivian):
* status: new = patch
Comment:
Patch implements multiline commands in GHCi. ({{{do, case, let}}}).
Patch includes documentation. The testsuite patch modifies a number of
GHCi tests that now require an additional blank line after {{{case}}} and
{{{let}}}.
#3984 was not modified.
It would be nice to see this in 7.0.
The history is not modified as Haskeline would require modification to
replace the previous n lines with one multiline command. Also, it might
be better to allow the user to replay each line at a time, so that an
error on one line can be changed. I suppose this depends on whether
history is used to edit commands or just repeat them.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:24
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
--+-
Reporter: mitar| Owner: vivian
Type: feature request | Status: new
Priority: normal | Milestone: 7.2.1
Component: GHCi |Version: 6.12.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Comment(by simonmar):
Replying to [comment:19 vivian]:
I add {{{Opt_AlternativeLayoutRule}}} as a dynamic flag. I'm checking
to see if the list of ALRContexts is empty and whether an opening curly
brace is expected but this does not appear to be sufficient. What in the
state of the lexer should I be checking?
I don't know. In what way is it not sufficient, can you give an example?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:22
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi --+- Reporter: mitar| Owner: vivian Type: feature request | Status: new Priority: normal | Milestone: 7.2.1 Component: GHCi |Version: 6.12.3 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by vivian): * owner: = vivian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner: vivian
Type: feature request | Status: patch
Priority: normal|Milestone: 7.2.1
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
How does implementing simonmar's suggestion impact upon #3984? It seems
that it renders it obsolete. Should the patch include removing the {{{:{
}:}}} construct?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:16
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): I don't know how well Haskeline will cope with multi-line input. Ideally you want Haskeline to be able to navigate and edit the complete multi-line expression. Also I'm not sure how layout should behave with the prompt, because the first line is already indented: should subsequent lines be indented by the width of the prompt, or should there be a special multi-line continuation prompt? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by igloo): Replying to [comment:17 simonmar]: Also I'm not sure how layout should behave with the prompt, because the first line is already indented: should subsequent lines be indented by the width of the prompt, or should there be a special multi-line continuation prompt? multi-line continuation prompt sounds best to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by vivian): Please disregard the patches currently attached. I'll implement simonmar's suggestion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): Just a thought: couldn't we use the altnerative layout rule to detect when a line ends without closing all of its layout contexts, and enter a multi-line mode which ends with a blank line, or when all the layout contexts have been closed? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner: vivian
Type: feature request | Status: patch
Priority: normal|Milestone: 7.2.1
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
Replying to [comment:12 simonmar]:
Just a thought: couldn't we use the altnerative layout rule to detect
when a line ends without closing all of its layout contexts, and enter a
multi-line mode which ends with a blank line, or when all the layout
contexts have been closed?
I do not know how to 'hook' into the lexer to check whether a layout rule
is open. {{{Lexer.x, lexer}}}, about line 1961, is where layout is
implemented.
A statement let foo = bar is a valid expression at the GHCi command
line, but could also be an open layout context expecting in baz foo to
close the context on the next line.
A trailing {{{do}}} on the command line generates an Empty 'do'
construct error, not an error about layout, which is why I can not see
(yet) how to get the layout context information from the parser.
Perhaps simonmar could provide me with a pointer as to how to implement
his suggestion?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:13
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3613: Better error messages for do-notation
#3613: Better error messages for do-notation +--- Reporter: simonpj| Owner: Type: bug| Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler (Type checker)|Version: 6.10.4 Resolution: fixed | Keywords: Testcase: typecheck/should_fail/T3613| Blockedby: Difficulty: Unknown| Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | +--- Changes (by simonpj): * status: new = closed * testcase: = typecheck/should_fail/T3613 * resolution: = fixed Comment: Ah yes, it does seemt to be fixed. Moreover, we already have a regression test to check it stays fixed (I've added it to the ticket description, but it was already in the testsuite). So yes let's close it. Thanks for pointing this out; very helpful. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3613#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3613: Better error messages for do-notation
#3613: Better error messages for do-notation
+---
Reporter: simonpj |Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.0.1
Component: Compiler (Type checker) | Version: 6.10.4
Keywords: | Testcase:
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-time
+---
Changes (by michalt):
* cc: michal.terep...@… (added)
* failure: = Incorrect warning at compile-time
Comment:
This seems to work fine with HEAD (i.e. even with (=)).
So adding the following to the original examples:
{{{
fun1' = let fooThen m = foo m
in fooThen (bar= \x - undefined)
fun2' = let fooThen m = foo m
in fooThen (do {x - bar; undefined})
}}}
I get:
* for fun1:
{{{
Couldn't match expected type `Maybe a' with actual type `IO ()'
In the first argument of `()', namely `bar'
}}}
* for fun2:
{{{
Couldn't match expected type `Maybe a' with actual type `IO ()'
In a stmt of a 'do' expression: bar
}}}
* for fun1':
{{{
Couldn't match expected type `Maybe a' with actual type `IO ()'
In the first argument of `(=)', namely `bar'
}}}
* and finally for fun2':
{{{
Couldn't match expected type `Maybe a' with actual type `IO ()'
In a stmt of a 'do' expression: x - bar
}}}
Which seems ok to me. So unless I'm missing something the ticket can be
closed as fixed..?
Just for the record:
{{{
ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.1.20101008
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3613#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner: vivian
Type: feature request | Status: patch
Priority: normal|Milestone: 7.2.1
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Changes (by vivian):
* status: new = patch
Comment:
I have a working multiline {{{do}}} patch,
{{{
Control.Monad.State flip evalStateT 0 $ do
Control.Monad.State| i - get
Control.Monad.State| lift $ do
Control.Monad.State| putStrLn Hello World!
Control.Monad.State| print i
Control.Monad.State|
Hello World!
0
Control.Monad.State
}}}
In order to provide a truly interactive session, the interpreter needs to
know how to (i) run a monad, (ii) pass initial arguments to a monad, and
(iii) take the output of running a monad and feed it to the next line.
Do we manipulate source (fragile) or manipulate HValues? But then we need
to run the typechecker at runtime to make sure we make use the correct
instance of overloaded (GHCi level) plumbing functions.
You also can't just evaluate lines up to present. What happens when the
last line is currently an assignment?
{{{
Control.Monad.State flip evalStateT 11 $ do
Control.Monad.State| f - get
}}}
This patch does not attempt to type the partial type and use the monad
type as prompt.
This patch provides multiline 'do's. Perhaps a new ticket for
interactive 'do' could be opened if thee abovementioned points can be
addressed.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by vivian): * owner: = vivian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
Replying to [comment:6 igloo]:
Not exactly the same as is being suggested, but this works in 7.0:
{{{Prelude Control.Monad.State :{}}}
Personally, I could live with typing {{{:{}}} before a multiline GHCi
expression. Especially since (see above) I advocated the syntactic
'batch' versus semantic 'line at a time' reading.
However, I am working on libraries that provide matlab-like functionality
at the !programming-language interpreter! level of GHCi. Multiline do
statements are part of the Haskell specification (which the odd
mathematical _user_ might deign to peruse), whereas this observe
formatting GHCi meta-: command is not standard.
There is a tension here between users and programmers. The beauty of
Haskell includes a succinct and elegant syntax. So much so, that I
believe that we can blur the line when using GHCi between an applied
mathematics environment and a programming environment.
I'd like to see Haskell used by non-programmer mathematicians.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by mitar): Replying to [comment:7 vivian]: I'd like to see Haskell used by non-programmer mathematicians. Then we definitely need line by line execution of commands. ;-) People who are used to imperative/procedural execution of commands will not be satisfied with just being able to enter multiple lines. They will want to see result for each of those lines. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by igloo):
Not exactly the same as is being suggested, but this works in 7.0:
{{{
Prelude Control.Monad.State :{
Prelude Control.Monad.State| flip evalStateT 1 $ do
Prelude Control.Monad.State| i - get
Prelude Control.Monad.State| lift $ putStrLn $ show i
Prelude Control.Monad.State| return $ i + 1
Prelude Control.Monad.State| :}
Loading package mtl-1.1.1.0 ... linking ... done.
1
2
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar | Owner:
Type: feature request | Status: new
Priority: normal| Component: GHCi
Version: 6.12.3|Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
Replying to [comment:3 mitar]:
Replying to [comment:2 vivian]:
Wouldn't it be better if things would be interpreted immediately?
This would require GHCi to somehow know how to run arbitrary monads. This
is a problem as each monad has a datatype-specific run function. Some
monads return {{{Value,State}}} (StateT), others return {{{Either Error
Value}}} (ErrorT), and so on.
{{{
Prelude flip evalStateT 1 $ do
StateT Int IO a |i - get
StateT Int IO a |lift $ putStrLn $ show i
1
}}}
somehow insert
{{{
flip runStateT missing parameter $ do
}}}
before the next line:
{{{
StateT Int IO a |return $ i + 1
StateT Int IO a |
2
Prelude
}}}
The difference is between prompting for more input, which relies only on
the original function call {{{flip evalStateT}}}, a 'syntactic' operation,
and multiple evaluations, a 'semantic' operation.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar | Owner:
Type: feature request | Status: new
Priority: normal| Component: GHCi
Version: 6.12.3|Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by mitar):
Replying to [comment:4 vivian]:
This would require GHCi to somehow know how to run arbitrary monads.
Hm, no, only how to evaluate do syntax. And if command there would have a
side effect (like putStrLn above) it would evaluate there and then.
Some monads return {{{Value,State}}} (StateT), others return {{{Either
Error Value}}} (ErrorT), and so on.
Does it really matter what does monad return? Because this gets through
`evalStateT` to GHCi back and GHCi just prints that.
The difference is between prompting for more input, which relies only
on the original function call {{{flip evalStateT}}}, a 'syntactic'
operation, and multiple evaluations, a 'semantic' operation.
I agree. One is just easier to input do code, and the other is incremental
evaluation. As Haskell allows this (order of evaluation of pure code is
unspecified - so it can be also in order how you enter it and order of
evaluation of do block is also from top to bottom and it does not matter
in which monad you are) I think it should be possible.
But I am a newbie here so I will rest my case here. I just think that it
would be great to have more than syntactic improvement. For syntactic
part: we could then also have possibility to correct already written lines
and similar, before we commit the call. In incremental evaluation there
would not be possible to correct lines above (as they would be already
evaluated) but it would be much more useful for example to test some IO
with added state (what was my initial idea all about).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi (was: Enable GHCi to run commands under StateT monad based on IO)
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar | Owner:
Type: feature request | Status: new
Priority: normal| Component: GHCi
Version: 6.12.3|Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
As far as I know, it is possible to run commands under StateT monad based
on IO.
I am interested in the supporting interactive 'do' notation and have
changed the ticket name accordingly.
Instead of displaying Empty 'do' construct, GHCi could provide a prompt
for further input, with the prompt being the type of the 'do' monad. A
blank lines signals the end of input and the entire interaction is then
re-interpreted. It should be possible to nest multiple 'do's.
{{{
Prelude flip evalStateT 1 $ do
StateT Int IO a |i - get
StateT Int IO a |putStrLn $ show i
StateT Int IO a |return $ i + 1
StateT Int IO a |
1
2
Prelude
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar | Owner:
Type: feature request | Status: new
Priority: normal| Component: GHCi
Version: 6.12.3|Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by mitar):
Replying to [comment:2 vivian]:
I am interested in the supporting interactive 'do' notation and have
changed the ticket name accordingly.
Great.
A blank lines signals the end of input and the entire interaction is
then re-interpreted.
Wouldn't it be better if things would be interpreted immediately?
Like:
{{{
Prelude flip evalStateT 1 $ do
StateT Int IO a |i - get
StateT Int IO a |liftIO $ putStrLn $ show i
1
StateT Int IO a |return $ i + 1
StateT Int IO a |
2
Prelude
}}}
Similar to the IO monad behavior:
{{{
Prelude i - return 1
Prelude putStrLn $ show i
1
Prelude return $ i + 1
2
}}}
And I am not exactly sure empty line would be then necessary as things
would be evaluated by line anyway and once there would be
return/fail/throw evaluation would stop.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: new recursive do notation (ghc 6.12.x) spoils layout
There's also an underlying semantic issue, which is not yet resolved. The GHC implementation of mdo (following Levent and John's paper) performs a dependency analysis on the statements in the mdo to apply mfix to the shortest possible subsegments of statements. For example, mdo a - f b b - g b c - h b d - k d return d is translated to the equivalent of do (a,b) - mfix $ \ (a,b) - do a - f b b - g b return (a,b) c - h b d - mfix $ \ d - d - k d return d return d As the User's Guide notes, the choice of segments can change the semantics with some monads. When rec was added to GHC, the implementation used the same code and thus also did automatic segmentation. The original idea of rec (in arrow notation) was that it would give the programmer direct control over these segments: the loop/mfix combinators would go wherever the programmer put a rec, but I didn't realize Simon had done it the other way until he mentioned it last October. So: * if rec is to continue to do automatic segmentation, it might as well be a modifier on the do keyword (though this would break backward compatibility of arrow notation), * but I want to argue against automatic segmentation, because I don't think the compiler should be making subtle changes to the program's semantics on its own. It would simplify the compiler a bit too. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
new recursive do notation (ghc 6.12.x) spoils layout
Whilst I have nothing against the change in syntax for recursive do aka
http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html
Instead of writing
mdo
a - getChar
b - f c
c - g b
putChar c
return b
you would write
do
a - getChar
rec { b - f c
; c - g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want my nice neat layout back. I have just spent an inordinate
amount of time updating code when if the parser recognised do rec as a
recursive group it would have been a drop in replacement and taken me
one tenth of the time.
Why can't we have this?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new recursive do notation (ghc 6.12.x) spoils layout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/10 13:18 , John Lask wrote: it does spoil the nice layout - it would be nice to just be able to write (which does not parse) do rec a - getChar b - f c c - g b putChar c return b I don't particularly care that the only recursive statements are #2,#3 - I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised do rec as a recursive group it would have been a drop in replacement and taken me one tenth of the time. I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the r of rec. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkweuP0ACgkQIn7hlCsL25XifQCgzvfvf9utQxkb2gdmVRPyhea2 iIUAnRT8XUhTKds0wrVkFaccyzAKTA9v =YjX6 -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new recursive do notation (ghc 6.12.x) spoils layout
I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the r of rec. for the record ... t2 = do rec a - getChar b - f c c - g b putChar c return b f = return . (const 'a') g = return eg.lhs:23:6: The last statement in a 'do' construct must be an expression Failed, modules loaded: none. so I suppose it is not so far from recognising the construct and yet too far! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
Whilst I have nothing against the change in syntax for recursive do aka
http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html
Instead of writing
mdo
a - getChar
b - f c
c - g b
putChar c
return b
you would write
do
a - getChar
rec { b - f c
; c - g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want my nice neat layout back. I have just spent an inordinate
amount of time updating code when if the parser recognised do rec as a
recursive group it would have been a drop in replacement and taken me
one tenth of the time.
Why can't we have this?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
On 22 June 2010 03:18, John Lask jvl...@hotmail.com wrote: I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised do rec as a recursive group it would have been a drop in replacement and taken me one tenth of the time. Why can't we have this? At a guess: because no-one has implemented such functionality yet. Are you volunteering? :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
On Jun 21, 2010, at 10:18 AM, John Lask wrote: do rec a - getChar b - f c c - g b putChar c return b I don't particularly care that the only recursive statements are #2,#3 - I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised do rec as a recursive group it would have been a drop in replacement and taken me one tenth of the time. Why can't we have this? Why can't you just use let notation do deal with the recursion? I thought lets in do blocks were just a little bit of syntactic sugar for regular let expressions, which do allow mutual recursion. I could be totally wrong though. I'm thinking of something like: do a - getChar let b = c = return . f let c = b = return . g c = putChar b___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
On Jun 20, 2010, at 6:24 PM, Alexander Solla wrote: do a - getChar let b = c = return . f let c = b = return . g c = putChar b Correction: by your construction, f and g are already in the Kliesli category, so you don't need the return compositions. I still don't know if the construction is admissible though.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
On Sunday 20 June 2010 9:24:54 pm Alexander Solla wrote: Why can't you just use let notation do deal with the recursion? I thought lets in do blocks were just a little bit of syntactic sugar for regular let expressions, which do allow mutual recursion. I could be totally wrong though. I'm thinking of something like: do a - getChar let b = c = return . f let c = b = return . g c = putChar b This is not what recursive do does. For instance: do rec l - (:l) $ getChar return l will read one character, and return an infinite list with that character as the elements. By contrast: let l = (:) $ getChar * l in l will, for one, never complete, and two, call getChar an infinite number of times. In general, it is based on the fixed point: mfix :: (MonadFix m) = (a - m a) - m a where the function given may not be separable into a pure function and return at all, which is what would be necessary to implement using let, via the identity: mfix (return . f) = return (fix f) The implementation of mfix is specific to the 'm' in question, not something you can write for all monads. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
