>> 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" <[email protected]> wrote:
> How can I reproduce? Is this on your wip/pattern-synonyms branch? > > Simon > > | -----Original Message----- > | From: Dr. ERDI Gergo [mailto:[email protected]] > | 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 >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
