Gergo It's just a question of chasing down the reduce/reduce errors. You can give a flag to Happy that makes it dump a file with all the info about it parsing states, and where the reduce/reduce errors come from, and you can go from there. If you don't know how to interpret that file, just commit your best try to your wip/ branch and maybe some other ghc devs will help you. Maybe me. But without being able to reproduce it, it's hard to help. Simon | -----Original Message----- | From: Dr. ERDI Gergo [mailto:gergo@erdi.hu] | Sent: 25 June 2014 14:20 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: RE: Help needed: parsing pattern synonym contexts | | On Tue, 24 Jun 2014, Simon Peyton Jones wrote: | | > In the latter case, what happened to the shift/reduce and | > reduce/reduce errors reported by Happy? Esp the latter. If you are | > getting more you need to track them down. | | I think I've figured out what might be causing the problem. | | First, a couple figures. With these rules: | | pattern_synonym_decl | : 'pattern' con vars0 patsyn_token pat | | 'pattern' varid conop varid patsyn_token pat | | pattern_synonym_sig | : 'pattern' patsyn_stuff '::' ctype | | patsyn_stuff | : constr_stuff | | I'm getting 112 new reduce/reduce conflicts. | | If I add the context like you recommended: | | pattern_synonym_sig | : 'pattern' patsyn_context patsyn_stuff '::' ctype | | patsyn_context :: { LHsContext RdrName } | : forall | | forall context '=>' | | | then I get 54 new shift/reduce conflicts and no (new) reduce/reduce | conflicts. | | My feeling is the problem is that patterns don't need any special | parentheses around type annotations, which means the following is a | legal pattern synonym definition: | | pattern Single x = [x] :: [Int] | | and I think that the difference (the '=' or '<-') is too 'deep' between | this and something like | | pattern Single a :: [a] | | Unfortunately, I still have no idea how to solve this problem...