#15637: Ambiguous type variables in GeneralisedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: i-am-tom | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | GeneralisedNewtypeDeriving, | GeneralizedNewtypeDeriving 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 RyanGlScott): Replying to [comment:1 simonpj]:
I suppose we could generate {{{ Test.f = coerce @String @String (Test.f @()) }}} that is, explicitly instantiating `f`.
That would make this particular example work, yes. Note that this strategy would not support GND'ing //every// class under the sun that uses `AllowAmbiguousTypes`, such as the example from #14266, which uses an ambiguous type variable in a class context. But your idea would still be an improvement over the status quo, so I'm inclined to adopt it.
(Then maybe we could omit the second type arg to `coerce`; I'm not sure.)
No, I don't think adding these extra type applications would change the fact that you need the second type argument to `coerce`. The reason for that is explained in `Note [GND and QuantifiedConstraints]` [http://git.haskell.org/ghc.git/blob/02edb8f2f973a8df26cfb6dfab0ef99a832f711f... here]; the short of it is the we need the second type argument to `coerce` to support GND'ing classes like: {{{#!hs class C a where c :: Int -> forall b. b -> a }}} That fact doesn't change even in the presence of this ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15637#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler