Opened 8 months ago

Last modified 8 months ago

#16203 new bug

Unhelpful names for wildcard type variables

Reported by: simonpj Owned by: goldfire
Priority: normal Milestone:
Component: Compiler Version: 8.6.3
Keywords: PartialTypeSignatures Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Consider

{-# LANGUAGE PartialTypeSignatures #-}

f :: _ -> _
f x = x

With GHC 8.6 we got

T16152.hs:10:6: warning: [-Wpartial-type-signatures]
    • Found type wildcard ‘_’ standing for ‘w’
      Where: ‘w’ is a rigid type variable bound by
               the inferred type of f :: w -> w
               at T16152.hs:11:1-7
    • In the type signature: f :: _ -> _
   |
10 | f :: _ -> _
   |      ^

T16152.hs:10:11: warning: [-Wpartial-type-signatures]
    • Found type wildcard ‘_’ standing for ‘w’
      Where: ‘w’ is a rigid type variable bound by
               the inferred type of f :: w -> w
               at T16152.hs:11:1-7
    • In the type signature: f :: _ -> _
   |
10 | f :: _ -> _
   |           ^

But with HEAD we get

T16152.hs:10:6: warning: [-Wpartial-type-signatures]
    • Found type wildcard ‘_’ standing for ‘_’
      Where: ‘_’ is a rigid type variable bound by
               the inferred type of f :: _ -> _
               at T16152.hs:11:1-7
    • In the type ‘_ -> _’
      In the type signature: f :: _ -> _
   |
10 | f :: _ -> _
   |      ^

T16152.hs:10:11: warning: [-Wpartial-type-signatures]
    • Found type wildcard ‘_’ standing for ‘_’
      Where: ‘_’ is a rigid type variable bound by
               the inferred type of f :: _ -> _
               at T16152.hs:11:1-7
    • In the type ‘_ -> _’
      In the type signature: f :: _ -> _
   |
10 | f :: _ -> _
   |           ^

Saying "Found type wildcard ‘_’ standing for ‘_’" is unhelpful. The "w" form is much better.

The change is caused by

commit 17bd163566153babbf51adaff8397f948ae363ca
Author: mynguyen <mnguyen1@brynmawr.edu>
Date:   Tue Dec 18 11:52:26 2018 -0500

    Visible kind application

which has this patch

-newWildTyVar _name
+newWildTyVar
   = do { kind <- newMetaKindVar
        ; uniq <- newUnique
        ; details <- newMetaDetails TauTv
-       ; let name = mkSysTvName uniq (fsLit "w")
+       ; let name = mkSysTvName uniq (fsLit "_")
              tyvar = (mkTcTyVar name kind details)
        ; traceTc "newWildTyVar" (ppr tyvar)
        ; return tyvar }

What was the reason for this change? Can we change "_" back to "w" please?

Change History (7)

comment:1 Changed 8 months ago by simonpj

Owner: set to goldfire

comment:2 Changed 8 months ago by simonpj

Keywords: PartialTypeSignatures added

comment:3 Changed 8 months ago by goldfire

This is a consequence of #16082. I do not see an easy solution that isn't ugly.

comment:4 Changed 8 months ago by simonpj

I propose simply reversing the one line change in the Description. I do not know why that change was made. Why is it ugly to reverse it?

comment:5 Changed 8 months ago by goldfire

Suppose we have

type family F a b where
  F _ _ = Bool

If we reverse the change, I believe we get that GHC reports that the equation is F w1 w2 = Bool. Perhaps that's better than what we have, but someone has to pay the price.

comment:6 Changed 8 months ago by RyanGlScott

Due to #16082, we're going to pretty-print certain things less than optimally regardless of whether we choose w or _—it's just a question of which pill we find easier to swallow.

I don't have a strong opinion on the matter, but it is worth noting that the choice of _ actually causes some things to be printed out in a manner that's flat-out incorrect. For example, here is the stderr from the Either test:

TYPE SIGNATURES
  barry :: forall _. _ -> (Either [Char] _, Either [Char] _)
Dependent modules: []
Dependent packages: [base-4.12.0.0, ghc-prim-0.5.3,
                     integer-gmp-1.0.2.0]

Notice the use of forall _ there, which isn't valid GHC code.

comment:7 Changed 8 months ago by goldfire

Perhaps in light of comment:6, we should revert that one-line change. But the bug just morphs into a different suboptimal pretty-printing...

Note: See TracTickets for help on using tickets.