#11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | NamedWildCards TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just seeing this now (missed it the first time it went through my inbox). I'm uncertain about this one. The current behavior is in line with the documentation, in that both arguments to, e.g., `const` are ''different'' types. So I think it's behaving according to spec. Should the spec change? Perhaps. If I recall correctly, there was a long and tortuous debate about the scoping of named wildcards, with all sides having good arguments in their favor. The nice thing about the current rule is that it's exceedingly simple and easy to predict. With your proposed rule, then you could write `f @_a (<something long>) @_a` and have the two `_a`s share a scope. So I think I've convinced myself to lean against this idea, but I'm open to argument. A better solution is to allow visible type ''abstraction'': {{{ asTypeOf = \ @a -> const @a @a }}} That way, you can say exactly what you mean. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11385#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler