RE: StrictData and the parser

2015-06-05 Thread Simon Peyton Jones
- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Edward Z. Yang | Sent: 05 June 2015 01:08 | To: Johan Tibell | Cc: ghc-devs@haskell.org | Subject: Re: StrictData and the parser | | Excerpts from Johan Tibell's message of 2015-06-04 16:52:30 -0700: | I guess we should parse

Re: StrictData and the parser

2015-06-04 Thread Johan Tibell
On Thu, Jun 4, 2015 at 10:30 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700: Looks to me like it's confused about whether a ~ is part of an equality constraint or is a laziness annotation. The former would be illegal at that

Re: StrictData and the parser

2015-06-04 Thread Edward Z. Yang
Excerpts from Johan Tibell's message of 2015-06-04 16:52:30 -0700: I guess we should parse it as T a (~b), just as we have unary minus bind tighter with the following token. Not in all contexts. It is true that if you have 'data SLPair a b = SLP a ~ b' you want to parse 'SLP a (~b)' But if

RE: StrictData and the parser

2015-06-04 Thread Simon Peyton Jones
...@haskell.org] On Behalf Of Adam | Sandberg Eriksson | Sent: 04 June 2015 20:52 | To: ghc-devs@haskell.org; johan.tib...@gmail.com | Subject: StrictData and the parser | | Hello *, | | I'm working on the -XStrict language extension[1] for this years Google | summer of code. I've started with the smaller

StrictData and the parser

2015-06-04 Thread Adam Sandberg Eriksson
Hello *, I'm working on the -XStrict language extension[1] for this years Google summer of code. I've started with the smaller -XStrictData (as documented at the wiki) and have the internals mostly figured out. However after adding relevant rules for '~' in the parser[2] I get an explosion of

Re: StrictData and the parser

2015-06-04 Thread Edward Z. Yang
Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700: Looks to me like it's confused about whether a ~ is part of an equality constraint or is a laziness annotation. The former would be illegal at that point, though, I'd think? Somewhere it believes a constraint might be

Re: StrictData and the parser

2015-06-04 Thread Edward Z. Yang
Hello Adam, At a guess, ~ is ambiguous with the type equality syntax a ~ b. You'll probably have to add a new production for types (similar to atype) which are at the top level of a data constructor definition. I recently wrote some documentation on how to interpret Happy info files. There

Re: StrictData and the parser

2015-06-04 Thread Brandon Allbery
On Thu, Jun 4, 2015 at 3:52 PM, Adam Sandberg Eriksson a...@sandbergericsson.se wrote: However after adding relevant rules for '~' in the parser[2] I get an explosion of shift/reduce conflicts as well as 4 extra reduce/reduce conflicts, see [3] for the happy info (the states with 36