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
