Is there a way to make GHC provide the type class constraints of typed holes?

Question

Current behavior

Prelude> show _

<interactive>:7:6:
    Found hole ‘_’ with type: a0
    Where: ‘a0’ is an ambiguous type variable
    Relevant bindings include it :: String (bound at <interactive>:7:1)
    In the first argument of ‘show’, namely ‘_’
    In the expression: show _
    In an equation for ‘it’: it = show _

Desired behavior

It would be nice if GHC would also tell me that the typed hole has the Show type class constraint.

Misc

GHC Version 7.8.1

AFAIK, this isn't currently possible, but it would certainly be useful. Might be worth opening a feature request on the GHC bug tracker for this. — kosmikus
I agree that this would be useful. I reported it as a feature request on the GHC trac: ghc.haskell.org/trac/ghc/ticket/9479 — Dominique Devriese
For now you could use pre-type-holes trick: show (undefined :: () -> ()); GHC will tell more in the type-check error. — phadej
Is this a feature request, or an actual question? That is, do you know for sure that there is no way to make GHC as you desire, or is there the possibility that you can get what you want with the current compiler, but you're not sure how? — stakx - no longer contributing
@stakx It is a bit of both. Originally when I wrote this question I was confused why GHC didn't provide the type class constraints, and was thinking I was using typed holes wrong. Then some told me that currently this is not possible to do, but could be added to GHC. So then I was hoping that it would be added soon. Many seem to would like to use it. phadej's trick seems to work in the mean time, but is not as elegant or easy-to-use as a typed hole based solution would be. — Wizek

crockeea crockeea · Accepted Answer · 2016-07-08T13:15:45

This is now fixed in GHC 8.0 thanks to @DominiqueDevriese's GHC ticket.

Due to extended type defaulting, this isn't immediately obvious in GHCi. With your example,

> show _

  <interactive>:7:6: error:
    • Found hole: _h :: ()
      Or perhaps ‘_h’ is mis-spelled, or not in scope
    • In the first argument of ‘show’, namely ‘_h’
      In the expression: show _h
      In an equation for ‘it’: it = show _h
    • Relevant bindings include
        it :: String (bound at <interactive>:7:1)

the type of the hole is defaulted to (). This is apparently the desired behavior, though there's an argument to be made that extended defaulting shouldn't apply to holes (as a common use for them is to get the compiler to tell you the inferred type).

Nevertheless, if you compile with GHC or disable extended default rules in GHCi (via :set -XNoExtendedDefaultRules), we see the result of the improvements:

<interactive>:3:1: error:
    • Ambiguous type variable ‘a0’ arising from a use of ‘show’
      prevents the constraint ‘(Show a0)’ from being solved.
      Probable fix: use a type annotation to specify what ‘a0’ should be.
      These potential instances exist:
        instance Show Ordering -- Defined in ‘GHC.Show’
        instance Show Integer -- Defined in ‘GHC.Show’
        instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’
        ...plus 22 others
        ...plus 11 instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the expression: show _
      In an equation for ‘it’: it = show _

<interactive>:3:6: error:
    • Found hole: _ :: a0
      Where: ‘a0’ is an ambiguous type variable
    • In the first argument of ‘show’, namely ‘_’
      In the expression: show _
      In an equation for ‘it’: it = show _
    • Relevant bindings include
        it :: String (bound at <interactive>:3:1)

Is there a way to make GHC provide the type class constraints of typed holes?

Current behavior

Desired behavior

Misc

3 Answers