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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
