Parser.y: an ugly attempt to disambiguate 'role' in type names.
AbandonedPublic

Authored by skvadrik on Jan 22 2016, 4:00 PM.

Details

Reviewers
austin
bgamari
Summary

This is a really bad patch that answers @mpickering's question

"if it is not actually ambiguous then what is the problem with changing the parser?"

See D1815 for details.

Test Plan

tested with make test

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Branch
fix-parser-cconflicts
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 8343
Build 10388: arc lint + arc unit
skvadrik updated this revision to Diff 6375.Jan 22 2016, 4:00 PM
skvadrik retitled this revision from to Parser.y: an ugly attempt to disambiguate 'role' in type names..
skvadrik updated this object.
skvadrik edited the test plan for this revision. (Show Details)
skvadrik updated this object.Jan 22 2016, 4:02 PM
skvadrik edited edge metadata.

Do you have an example of what kind of ambiguities arise when the 'role' keyword is just added to the tyvarid production? How many shift reduce conflicts does it create?

To answer my own question, it seems the problems come just with type synonyms?

skvadrik added a comment.EditedJan 22 2016, 4:25 PM

Do you have an example of what kind of ambiguities arise when the 'role' keyword is just added to the tyvarid production?

I can show an example of ambiguous derivations that offend LALR grammar (just sentential forms, not sentences), with the lookahead ( after role:

topdecl
    -> ty_decl
    -> 'type' type '=' ctypedoc
    -> 'type' btype '=' ctypedoc
    -> 'type' tyapps '=' ctypedoc
    -> 'type' tyapps tyapp '=' ctypedoc
    -> 'type' tyapp tyapp '=' ctypedoc
    -> 'type' atype tyapp '=' ctypedoc
    -> 'type' tyvar tyapp '=' ctypedoc
    -> 'type' tyvarid tyapp '=' ctypedoc
    -> 'type' 'role' tyapp '=' ctypedoc

vs

topdecl
    -> role_annot
    -> 'type' 'role' oqtycon maybe_roles

How many shift reduce conflicts does it create?

3 shift/reduce conflicts

To answer my own question, it seems the problems come just with type synonyms?

I think that's correct. Even more, my guess is that type synonyms must start with uppercase letter and the grammar allows lowercase just for the sake of good error reporting. I think that type role =<something> is not valid Haskell.

I thought the same but there is a comment below the rule which reminded me you can have infix type synonyms.

Is 3 shift reduce conflicts so bad if they get resolved the right way? Especially as they have been diagnosed, I don't think it would be too bad.

Is 3 shift reduce conflicts so bad if they get resolved the right way? Especially as they have been diagnosed, I don't think it would be too bad.

3 shift/reduce conflicts that are well-documented and resolved correctly might be ok. But 3 more (on top of existing 36) conflicts that are caused by a tiny improvement (hardly anyone really needs role in type names at all) - I'm all for the clarity of grammar.

Moreover, role keyword is just the beginning. Here comes the family keyword which causes ~100 shift/reduce conflicts (when naively added to tyvarid). The problem is general, it's getting worse and in my opinion it has to be solved fundamentally.

The problem is general, it's getting worse and in my opinion it has to be solved fundamentally.

By which you mean?

Btw, thanks for this investigation it is very useful.

By which you mean?

Make a new dedicated lexeme type like __keyword or @keyword or ExtensionName:keyword (or anything that does not collide with identifiers and popular syntax constructs) and gradually port all extension keywords to this kind of lexeme. Like type role becomes __role, data kind becomes __kind (or __datakind, whatever). This way syntax would be easy to parse and easy to add new extensions with new keywords (just pick any word and prefix it with __).

Btw, thanks for this investigation it is very useful.

Thank you!

Ulya, this is very insightful. Thanks!

I only want to point out that __keyword is a perfectly acceptable varid and @keyword might collide with visible type applications.

This was just an example, maybe someone else can suggest a better prefix.

bgamari requested changes to this revision.Jan 26 2016, 4:55 AM
bgamari edited edge metadata.

@skvadrik, if I'm not mistaken (which is a distinct possibility) this Diff was merely to demonstrate a point and was not intended to be merged. If this is the case and it has served its purpose would you mind marking it as abandoned?

This revision now requires changes to proceed.Jan 26 2016, 4:55 AM
skvadrik abandoned this revision.Jan 26 2016, 7:52 AM

Yes of course, until we come up with something.