Help needed: parsing pattern synonym contexts

[Dr. ÉRDI Gergő]

>> OK I've uploaded the code to wip/T9023

It's pushed to wip/T9023 on the GHC git repo.
On Jul 3, 2014 2:32 AM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140703/4bba0327/attachment.html>