[GHC] #11449: Treat '_' consistently in type declarations

GHC ghc-devs at haskell.org
Fri Jan 22 15:07:18 UTC 2016


#11449: Treat '_' consistently in type declarations
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
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):

 Never mind, I don't think things like

 {{{#!hs
 instance C [_] where
   type T [_] = Int
 }}}

 should be allowed after all (see
 [https://ghc.haskell.org/trac/ghc/ticket/11450#comment:18 my comment] in
 #11450 for rationale).

 That being said, I don't know if we should rule out putting wildcards in
 class instances altogether. Typeclasses without associated type families
 or methods wouldn't have the issue of requiring the types to be the same,
 so you could conceivably have something like this:

 {{{#!hs
 class C a where

 instance C _ where
 }}}

 Although I don't know how useful this is.

 And I really don't know how to feel about things like `data T _ = T` or
 `class C a _`, since we'd be allowing wildcards in place of `TyVar`s,
 which is uncharted territory. Neither are Haskell98 for sure, so I agree
 that if we allow such a thing, you should need a language extension to
 turn it on.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11449#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list