Help needed: parsing pattern synonym contexts
Hi, I'm working on adding type signatures to pattern synonyms. The syntax I'm after would look something like, e.g.: pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] My problem is with parsing the two contexts. I wrote the parser in the following way, which I felt natural (actions omitted for brevity) pattern_synonym_sig :: { LSig RdrName } : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context type patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType RdrName)) } : constr_stuff patsyn_context :: { LHsContext RdrName } : {- empty -} | forall context '=>' However, this doesn't work, no matter if those contexts are present or not. If I remove both contexts from the rules, i.e. if I replace pattern_synonym_sig with : 'pattern' patsyn_stuff '::' type then parsing succeeds when there are no contexts on either side. I've also tried : 'pattern' patsyn_stuff '::' ctype with the intention of recovering the required context from the ctype (and I could do similar tricks to get the provided context from the patsyn_stuff by using a modified version of constr_stuff); however, even that doesn't work as I expected it, i.e. with this latter version, this: pattern Single a :: (Eq a) => [a] fails with a parse error on "::". Can someone help me out here please? Thanks, Gergo
What do you mean by "doesn't work"? Crashes? Fails to build with some error? Builds but doesn't parse what you expect? In the latter case, what happened to the shift/reduce and reduce/reduce errors reported by Happy? Esp the latter. If you are getting more you need to track them down. For exmape if I see pattern P ... and I've gotten to the P. Have I seen an empty forall, and this is the beginning of context, or have I seen an empty patsyn_context, and this is the beginning of constr_stuff. I think this'll be a reduce/reduce error. I think it may be helped by patsyn_contxt :: forall | forall context '=>' c.f the defn of 'constr'. IN haste Simoin | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 24 June 2014 13:12 | To: GHC Devs | Subject: Help needed: parsing pattern synonym contexts | | Hi, | | I'm working on adding type signatures to pattern synonyms. The syntax | I'm after would look something like, e.g.: | | pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] | | My problem is with parsing the two contexts. I wrote the parser in the | following way, which I felt natural (actions omitted for brevity) | | pattern_synonym_sig :: { LSig RdrName } | : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context | type | | patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType | RdrName)) } | : constr_stuff | | patsyn_context :: { LHsContext RdrName } | : {- empty -} | | forall context '=>' | | However, this doesn't work, no matter if those contexts are present or | not. If I remove both contexts from the rules, i.e. if I replace | pattern_synonym_sig with | | : 'pattern' patsyn_stuff '::' type | | then parsing succeeds when there are no contexts on either side. I've | also tried | | : 'pattern' patsyn_stuff '::' ctype | | with the intention of recovering the required context from the ctype | (and I could do similar tricks to get the provided context from the | patsyn_stuff by using a modified version of constr_stuff); however, even | that doesn't work as I expected it, i.e. with this latter version, this: | | pattern Single a :: (Eq a) => [a] | | fails with a parse error on "::". | | Can someone help me out here please? | | Thanks, | Gergo | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
On Tue, 24 Jun 2014, Simon Peyton Jones wrote:
What do you mean by "doesn't work"? Crashes? Fails to build with some error? Builds but doesn't parse what you expect?
Yeah, sorry, when I wrote
fails with a parse error on "::".
what I meant was that the parser builds & runs, but fails with a parse error on the double-colon. I'll get back to you on the other points when I've had time to try them.
On Tue, 24 Jun 2014, Simon Peyton Jones wrote:
In the latter case, what happened to the shift/reduce and reduce/reduce errors reported by Happy? Esp the latter. If you are getting more you need to track them down.
I think I've figured out what might be causing the problem. First, a couple figures. With these rules: pattern_synonym_decl : 'pattern' con vars0 patsyn_token pat | 'pattern' varid conop varid patsyn_token pat pattern_synonym_sig : 'pattern' patsyn_stuff '::' ctype patsyn_stuff : constr_stuff I'm getting 112 new reduce/reduce conflicts. If I add the context like you recommended: pattern_synonym_sig : 'pattern' patsyn_context patsyn_stuff '::' ctype patsyn_context :: { LHsContext RdrName } : forall | forall context '=>' then I get 54 new shift/reduce conflicts and no (new) reduce/reduce conflicts. My feeling is the problem is that patterns don't need any special parentheses around type annotations, which means the following is a legal pattern synonym definition: pattern Single x = [x] :: [Int] and I think that the difference (the '=' or '<-') is too 'deep' between this and something like pattern Single a :: [a] Unfortunately, I still have no idea how to solve this problem...
Gergo It's just a question of chasing down the reduce/reduce errors. You can give a flag to Happy that makes it dump a file with all the info about it parsing states, and where the reduce/reduce errors come from, and you can go from there. If you don't know how to interpret that file, just commit your best try to your wip/ branch and maybe some other ghc devs will help you. Maybe me. But without being able to reproduce it, it's hard to help. Simon | -----Original Message----- | From: Dr. ERDI Gergo [mailto:gergo@erdi.hu] | Sent: 25 June 2014 14:20 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: RE: Help needed: parsing pattern synonym contexts | | On Tue, 24 Jun 2014, Simon Peyton Jones wrote: | | > In the latter case, what happened to the shift/reduce and | > reduce/reduce errors reported by Happy? Esp the latter. If you are | > getting more you need to track them down. | | I think I've figured out what might be causing the problem. | | First, a couple figures. With these rules: | | pattern_synonym_decl | : 'pattern' con vars0 patsyn_token pat | | 'pattern' varid conop varid patsyn_token pat | | pattern_synonym_sig | : 'pattern' patsyn_stuff '::' ctype | | patsyn_stuff | : constr_stuff | | I'm getting 112 new reduce/reduce conflicts. | | If I add the context like you recommended: | | pattern_synonym_sig | : 'pattern' patsyn_context patsyn_stuff '::' ctype | | patsyn_context :: { LHsContext RdrName } | : forall | | forall context '=>' | | | then I get 54 new shift/reduce conflicts and no (new) reduce/reduce | conflicts. | | My feeling is the problem is that patterns don't need any special | parentheses around type annotations, which means the following is a | legal pattern synonym definition: | | pattern Single x = [x] :: [Int] | | and I think that the difference (the '=' or '<-') is too 'deep' between | this and something like | | pattern Single a :: [a] | | Unfortunately, I still have no idea how to solve this problem...
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. Cheers, Simon On 30/06/2014 14:04, Simon Peyton Jones wrote:
Gergo
It's just a question of chasing down the reduce/reduce errors. You can give a flag to Happy that makes it dump a file with all the info about it parsing states, and where the reduce/reduce errors come from, and you can go from there.
If you don't know how to interpret that file, just commit your best try to your wip/ branch and maybe some other ghc devs will help you. Maybe me. But without being able to reproduce it, it's hard to help.
Simon
| -----Original Message----- | From: Dr. ERDI Gergo [mailto:gergo@erdi.hu] | Sent: 25 June 2014 14:20 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: RE: Help needed: parsing pattern synonym contexts | | On Tue, 24 Jun 2014, Simon Peyton Jones wrote: | | > In the latter case, what happened to the shift/reduce and | > reduce/reduce errors reported by Happy? Esp the latter. If you are | > getting more you need to track them down. | | I think I've figured out what might be causing the problem. | | First, a couple figures. With these rules: | | pattern_synonym_decl | : 'pattern' con vars0 patsyn_token pat | | 'pattern' varid conop varid patsyn_token pat | | pattern_synonym_sig | : 'pattern' patsyn_stuff '::' ctype | | patsyn_stuff | : constr_stuff | | I'm getting 112 new reduce/reduce conflicts. | | If I add the context like you recommended: | | pattern_synonym_sig | : 'pattern' patsyn_context patsyn_stuff '::' ctype | | patsyn_context :: { LHsContext RdrName } | : forall | | forall context '=>' | | | then I get 54 new shift/reduce conflicts and no (new) reduce/reduce | conflicts. | | My feeling is the problem is that patterns don't need any special | parentheses around type annotations, which means the following is a | legal pattern synonym definition: | | pattern Single x = [x] :: [Int] | | and I think that the difference (the '=' or '<-') is too 'deep' between | this and something like | | pattern Single a :: [a] | | Unfortunately, I still have no idea how to solve this problem... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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
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
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"
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
participants (4)
-
Dr. ERDI Gergo -
Dr. ÉRDI Gergő
-
Simon Marlow -
Simon Peyton Jones