How can I reproduce? Is this on your wip/pattern-synonyms branch? Simon | -----Original Message----- | From: Dr. ERDI Gergo [mailto:gergo@erdi.hu] | Sent: 02 July 2014 12:45 | To: Simon Marlow | Cc: Simon Peyton Jones; GHC Devs | Subject: Re: Help needed: parsing pattern synonym contexts | | Hi, | | On Tue, 1 Jul 2014, Simon Marlow wrote: | | > The s/r conflicts can also be a problem, depending on what you're | trying to | > parse. It's generally a good idea to get rid of them if you can, but | at the | > least you should understand why they exist (use happy --info) and | document | > them in Parser.y.pp. | | OK I've uploaded the code to wip/T9023 and the happy --info report to | http://unsafePerform.IO/files/Parser.y.happy-info.gz | | Loads of shift/reduce conflicts come from state 214. Looking at them, I | would have thought that the solution would be to parse pattern synonym | definitions like we parse data constructors as types: by parsing it as a | single pattern and then splitting it. A quick shortcut to this should be | to just disable the parsing rule for infix pattern synonyms; so I tried | that. | | As expected, this cuts down on the number of shift/reduce conflicts in | that state considerably. The rest then seems to be coming from state 570: | | patsyn_context -> forall . (rule 157) | patsyn_context -> forall . context '=>' (rule 158) | | Unfortunately, I don't have a quick workaround for that one yet. | | Thanks, | Gergo