Help needed: parsing pattern synonym contexts

[Simon Peyton Jones]

How can I reproduce?  Is this on your wip/pattern-synonyms branch?

Simon

| -----Original Message-----
| From: Dr. ERDI Gergo [mailto:gergo at 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