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:[email protected]] 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: [email protected] [mailto:[email protected]] 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:[email protected]] > | | 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:[email protected]] > | | >> 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 > | [email protected] > | http://www.haskell.org/mailman/listinfo/cvs-ghc > > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
