[GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind

GHC ghc-devs at haskell.org
Tue Jun 5 11:16:57 UTC 2018


#15079: GHC HEAD regression: cannot instantiate higher-rank kind
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.6.1
       Component:  Compiler (Type    |              Version:  8.5
  checker)                           |
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Richard and I discussed this yesterday. We noted that:

 1. The interaction between higher-rank kinds and binder visibility has
 many parallels with other unexpected properties of higher-rank kinds. In
 particular, because there are (currently) no type-level lambdas, higher-
 rank kinds' `foralls` are more rigid than their type-level counterparts.
 As one example, in #13399 it was noted that higher-rank kinds' `foralls`
 don't "float" like the ones in higher-rank types. In this sense, it's
 perhaps somewhat understandable that higher-rank kinds' visibility might
 also be more rigid.
 2. If we wanted to have a more permissive treatment of invisible binders
 in higher-rank kinds, then we'd need to come up with a better story.
 Richard considered various ideas like having a subtyping relation between
 visibilities, but in the end, he concluded that anything we could think of
 was likely far too complicated for such little payoff.

 Thus, the conclusion we reached was that we should keep the current
 behavior, and make note of this behavior in the users' guide.

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


More information about the ghc-tickets mailing list