#8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: => goldfire Comment: Q1: Yes, that's possible. I didn't do it mostly because my stomach lurched when thinking about parsing role annotation concrete syntax for data family instances -- I was going to wait until someone shouted. I considered having data instances go through role inference without allowing for role annotations, but that meant it would be impossible to create a properly abstract data family instance. Q2: That's possible but currently unimplemented (see earlier posts to this bug report). So, if we could just figure out a decent concrete syntax, I could make it all work. The hardest part will be updating the parser and `HsSyn` stuff. The role inference/checking should be almost no work at all. As a strawman syntax, what about {{{ type role instance T [nominal] }}} for the case above. Note the word `instance` to specify that we're talking about the roles on an instance, not on the family `T`. Then, role names would appear wherever type variables appear in the corresponding instance declaration. Underscores would be supported in these positions, as well (like normal role annotations). The corresponding data (or newtype) instance would have to be in the same module, as usual. The appearance of the word `type` (as opposed to `data`) in the role annotation syntax is regrettable, but it conforms to the universal use of the word `type` in all role annotations. Though it makes me want to cry, I suppose we should allow ''associated'' role instance annotations, in class instance definitions alongside associated data/newtype instances. Does anyone out there actually want to use this feature? Eager users would help motivate all this! :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8177#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler