Special treatment of family and role in the parser

Richard Eisenberg eir at cis.upenn.edu
Wed Jan 20 19:25:24 UTC 2016


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 <jan.stolarek at p.lodz.pl> 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.



More information about the ghc-devs mailing list