CC Ulya Trofimovich (skvadrik), who removed the remaining reduce/reduce conflicts from the parser last year, and can maybe also help out here. Ulya: see email from Jan below. On Wed, Jan 20, 2016 at 8:25 PM, Richard Eisenberg wrote:

From your email, you understand everything I do about this. :)

I think the challenge really is just understanding and eliminating these conflicts. See the commentary at the top of Parser.y to see how to get an analysis of the conflicts.

While you're in the area, you may want to look at #11267. It's not quite related, but it's also about parsing types.

Richard

On Jan 20, 2016, at 1:42 PM, Jan Stolarek wrote:

...

Richard, I still don't fully understand special treatment of 'role' and 'family' in the parser I asked about recently on Skype. Say I have:

foo :: role -> role foo role = role

This results in parse error of type signature, regardless of enabling or disabling -XRoleAnnotations. Using `role` as a variable name (not type variable) is fine though. This is a consequence of explicitly listing 'role' lexeme in the varid production in the parser, but not in tyvarid production. But if I add 'role' to tyvarid production (or, even better, push it to special_id production used both by varid and tyvarid) everything works perfectly, I can use `role` both as variable and type variable name. Role annotations also work. The only downside is a small increase in number of shift/reduce conflicts. If I treat 'family' in the same way (ie. add it to tyvarid production) the increase in shift/reduce conflicts really becomes significant: from 37 to 129. Is this the only reason we don't do it? As you can guess this question is related to open kinds work: I need to add 'kind' lexeme to special_id to make sure it is accepted as a variable and type variable name.

Janek

--- Politechnika Łódzka Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs