#10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by thomasw): Replying to [comment:2 simonpj]:
We should never generalise over wildcards!
I'm confused, we do generalise over wildcards when possible, right? When I say "the wildcard is generalised over", I mean that when the wildcard is not instantiated to a monotype, we replace it with a fresh type variable and universally quantify it. This is what we have being doing the whole time, e.g.: {{{#!hs foo :: _ -> _ foo x = x -- Inferred: w_ -> w_ }}} What I expected in the example in the description above (and what indeed happens) is that the wildcard is generalised over and that we get `a -> w_` as type for `f`.
Thomas, are you ok to look into this one? Yell if you need help.
I see two ways to solve it: 1. Don't print skolem information when there is none (easy). 2. Generate an `Implication` with the right skolem information (harder). Which solution do you prefer? If you prefer 2, I'd appreciate some pointers as to where/when these `Implication` constraints should be generated. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10072#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler