FW: Monad comprehensions
Simon Peyton-Jones
simonpj at microsoft.com
Wed Dec 28 13:56:50 CET 2011
George: sorry, I simply failed to push, by mistake.
Ian: could you apply this patch, including to 7.4.1 branch? It simply removes the recently-introduced Control.Monad.Group
Thanks
Simon
-----Original Message-----
From: George Giorgidze [mailto:giorgidze at gmail.com]
Sent: 24 December 2011 00:03
To: Simon Peyton-Jones
Cc: GHC
Subject: Re: Monad comprehensions
Hi Simon,
Thanks for applying the changes (removing the default grouping clause from SQL-like comprehensions) to GHC and to its documentation and test suite. I noticed that the changes made into GHC-7.4.
However, the changes to the base package (removing the Control.Monad.Group module which is no longer used by monad comprehensions) has not been applied.
https://github.com/giorgidze/packages-base/commit/bfa079b64cf00d38baccfc534710c5e90220d30c
Is there a reason for that?
Cheers, George
On 2011-Nov-17, at 17:02 , Simon Peyton-Jones wrote:
> Right I've committed this. Thanks
>
> Simon
>
> | -----Original Message-----
> | From: cvs-ghc-bounces at haskell.org [mailto:cvs-ghc-bounces at haskell.org] On Behalf Of
> | Simon Peyton-Jones
> | Sent: 17 November 2011 08:48
> | To: George Giorgidze
> | Cc: GHC
> | Subject: RE: Monad comprehensions and rebindable syntax
> |
> | Thank you! Looks right. I'm validating now.
> |
> | Simon
> |
> | | -----Original Message-----
> | | From: George Giorgidze [mailto:giorgidze at gmail.com]
> | | Sent: 02 November 2011 23:38
> | | To: Simon Peyton-Jones
> | | Subject: Re: Monad comprehensions and rebindable syntax
> | |
> | | Hi Simon,
> | |
> | | Today I finally found some time to get started with the implementation of the
> | | proposals I posted on the GHC mailing list a few weeks ago.
> | |
> | | There was a consensus with no objections on removing the default grouping clause
> | from
> | | the SQL-like comprehension notation. Today I just did that, see the patches that
> | are
> | | linked below.
> | |
> | | (The rest of the grouping clauses are unaffected. A consensus has not been reached
> | | on syntax changes for the grouping clauses.)
> | |
> | | In addition to the changes in the code implementing the SQL-like comprehension
> | | notation, I have changed relevant comments, updated relevant GHC documentation
> | | sections, removed the MonadGroup class from the base package and updated the
> | | testsuite.
> | |
> | | * Changes in GHC
> | | For reviewing:
> | | https://github.com/giorgidze/ghc/commit/0cbe437bc3fa47133255a256a27283d75dc401
> | | 4c
> | | For downloading:
> | | https://github.com/giorgidze/ghc/commit/0cbe437bc3fa47133255a256a27283d75dc401
> | | 4c.patch
> | | For pulling: git pull git://github.com/giorgidze/ghc.git
> | |
> | | * Changes in base
> | | For reviewing: https://github.com/giorgidze/packages-
> | | base/commit/bfa079b64cf00d38baccfc534710c5e90220d30c
> | | For downloading: https://github.com/giorgidze/packages-
> | | base/commit/bfa079b64cf00d38baccfc534710c5e90220d30c.patch
> | | For pulling: git pull git://github.com/giorgidze/packages-
> | base.git
> | |
> | | * Changes in testsuite
> | | For reviewing:
> | | https://github.com/giorgidze/testsuite/commit/d1fc1b3f3295e1e93d43ebaa5fc48c55
> | | 6d554208
> | | For downloading:
> | | https://github.com/giorgidze/testsuite/commit/d1fc1b3f3295e1e93d43ebaa5fc48c55
> | | 6d554208.patch
> | | For pulling: git pull git://github.com/giorgidze/testsuite.git
> | |
> | | I will move on to implementing (and evaluating the implementation on my use cases)
> | | the rebindable syntax for SQL-like monad comprehensions as outlined in your email.
> | | Having said that, exact timing of that depends on my availability. Next week I am
> | | travelling to Nottingham for my PhD viva. I will try to implement the rebindable
> | | syntax after that.
> | |
> | | I am also planning to have a close look at the issues raised on my proposal for
> | list
> | | literal overloading and if consensus emerges I will try to implement it (also after
> | | my PhD viva).
> | |
> | | Cheers, George
> | |
> | | On 2011-Oct-22, at 23:01 , George Giorgidze wrote:
> | |
> | | > Hi Simon,
> | | >
> | | > Thanks for the detailed instructions.
> | | >
> | | > I will try to implement the suggested changes next week and come back to you with
> | | questions or with a patch.
> | | >
> | | > Cheers, George
> | | >
> | | > P.S. I will also remove the default grouping clause and the MonadGroup class as
> | | suggested in my other email.
> | | >
> | | >
> | | > On 2011-Oct-18, at 23:05 , Simon Peyton-Jones wrote:
> | | >
> | | >> George,
> | | >>
> | | >> Thanks for the example. In every case the reason is the same:
> | | >>
> | | >> * In TcMatches look for 'mkForAllTy'; these uses all insist that the
> | | various operators (mzip, fmap, using) have a type that is more polymorphic than the
> | | Set versions are.
> | | >>
> | | >> * The specifics differ slightly
> | | >> o For 'using', the polymorphic function is immediately instantiated at a
> | single
> | | type (TcMatches line 447, 622).
> | | >> o For `mzip` and 'return' in PatStmt, and 'fmap' in TransStmt, the
> | polymorphic
> | | function is applied to many different types, in DsListComp, line 772, 781, 867
> | resp.
> | | >>
> | | >> * If we wanted this to work for restricted monads, the *type checker*
> | would
> | | need to perform these type applications; more precisely, we'd need to call
> | tcSyntaxOp
> | | on 'mzip', 'return' etc for each argument-tuple type. So
> | | >> o we'd need a *list* of mzip, return, fmap operators
> | | >> o the type checker would have to anticipate exactly the tuples of bound
> | | variables for which the desugarer would need an instance of 'mzip' etc
> | | >> o we might get errors saying that (say) a triple wasn't an instance of
> | MyClass,
> | | even though the programmer didn't write any triples.
> | | >> Note that (highly inconsistently) the 'return_op' in a TransStmt, line 898,
> | | already is called at a particular tuple type, anticipating the desugarer in exactly
> | | this way, and potentially getting those "triple not an instance of MyClass" errors.
> | | >>
> | | >> My sense is that with rebindable syntax we should bite the bullet and implement
> | | this change. (Once implemented, it'll also work for non-rebindablle syntax; no need
> | | to test the flag.)
> | | >>
> | | >> Would you like to try it? The changes are, I think
> | | >> * Eliminate the trS_fmap field of TransStmt and make the trS_bndrs field
> | | into a list of triples [(idR, idR, SyntaxExpr isR)], where the SyntaxExpr is the
> | fmap
> | | that selects that particular binder from the full tuple.
> | | >>
> | | >> * For ParStmt (HsExpr line 879, perhaps we could do this:
> | | >> ParStmt (ParTree idL idR)
> | | >> (SyntaxExpr idR) -- >>=
> | | >>
> | | >> data ParTree idL idR = ParLeaf [LStmt idL] [idR]
> | | >> (SyntaxExpr idR)
> | | -- return
> | | >> | ParNode (ParTree idL idR)
> | (ParTree
> | | idL idR)
> | | >> (SyntaxExpr idR)
> | -
> | | - mzip
> | | >>
> | | >> The ParTree records the structure of the zip; we keep a (suitably instantiated)
> | | mzip at all the internal nodes, and a (suitably instantiated) return at the leaves.
> | | >>
> | | >> * In TcMatches, don't insist that the 'using' thing is polymorphic, if
> | | rebindable syntax is on.
> | | >>
> | | >> Then all you have to do is make all those SyntaxExprs in TcMatches, and document
> | | (in HsExpr) the types they are expected to have, to express the contract between
> | | TcMatches and DsListComp. So some work is transferred from DsListComp to
> | TcMatches.
> | | >>
> | | >> OK? I think you're well placed to do this. Yell if you need any help.
> | | >>
> | | >> Simon
> | | >>
> | | >> From: George Giorgidze [mailto:giorgidze at gmail.com]
> | | >> Sent: 26 September 2011 10:05
> | | >> To: Simon Peyton-Jones
> | | >> Subject: Re: Monad comprehensions
> | | >>
> | | >> Hi Simon,
> | | >>
> | | >> Thanks for taking your time and looking at how MonadComprehensions interact with
> | | RebindableSyntax.
> | | >>
> | | >> On Sep 23, 2011, at 8:56 AM, Simon Peyton-Jones wrote:
> | | >>
> | | >>> George
> | | >>>
> | | >>> Could you send me a small example that you would like to work, but which
> | doesn't
> | | because of the too-polymorphic type of fmap and group? If you could make it self-
> | | contained that would be good.
> | | >>
> | | >> I have attached a heavily commented, self-cintained module with concrete
> | examples
> | | summarising what works and what does not work in GHC-7.2.
> | | >>
> | | >> Monad comprehensions with generators and filters do work for restricted monads .
> | | However, parallel and SQL-like comprehensions in GHC-7.2 do not work with
> | restricted
> | | monads.
> | | >>
> | | >> Cheers, George
> | | >>
> | | >>
> | | >>
> | | >>
> | | >>>
> | | >>> Thanks
> | | >>>
> | | >>> Simon
> | | >>
> | | >
> | |
> |
> |
> | _______________________________________________
> | Cvs-ghc mailing list
> | Cvs-ghc at haskell.org
> | http://www.haskell.org/mailman/listinfo/cvs-ghc
>
>
More information about the Cvs-ghc
mailing list