>> OK I've uploaded the code to wip/T9023
It's pushed to wip/T9023 on the GHC git repo.
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