[GHC] #10995: Existentials in newtypes

GHC ghc-devs at haskell.org
Wed Oct 21 15:40:04 UTC 2015


#10995: Existentials in newtypes
-------------------------------------+-------------------------------------
        Reporter:  crockeea          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  7.10.2
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10715            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 Replying to [comment:2 simonpj]:
 > There is clearly a bug here.  But it's a bug hiding a design question.

 I agree with that statement, but disagree in the particulars. And I think
 that Note is wrong.

 Consider this:

 {{{
 foo :: (Proxy a -> ()) -> ()
 foo = undefined

 bar :: (forall a. Proxy a -> ()) -> ()
 bar = undefined

 quux :: (forall (a :: k). Proxy a -> ()) -> ()
 quux = undefined
 }}}

 With `-fprint-explicit-kinds -fprint-explicit-foralls`:

 {{{
 *Scratch> :t foo
 foo :: forall (k :: BOX) (a :: k). (Proxy k a -> ()) -> ()
 *Scratch> :t bar
 bar :: forall (k :: BOX). (forall (a :: k). Proxy k a -> ()) -> ()
 *Scratch> :t quux
 quux :: (forall (k :: BOX) (a :: k). Proxy k a -> ()) -> ()
 }}}

 With no explicit quantification, `foo`'s kind and type variables are
 quantified at the top-level. With `a` explicitly quantified in `bar`, `a`
 is not top-level, but `a`'s kind `k` is top-level. In `quux`, because `k`
 is explicit mentioned first in the scope of an inner quantification, it is
 quantified there, too.

 I find this design a little strange, but in the absence of explicit kind
 quantification, I don't see a better option. Any of these possibilities
 make sense and a programmer might want any of them.

 (Note, we will have explicit kind quantification in GHC 8.0.)

 Let's get back to datatypes. There is a third possibility Simon omits, and
 it's actually the one that GHC uses. When we see

 {{{
 data T = MkT (forall a f. f a -> Int)
 }}}

 GHC will infer

 {{{
 data T3 = forall k. MkT (forall a f. f a -> Int)
 }}}

 which indeed has an existential kind. The good news is that it's easy to
 work around this problem: just say

 {{{
 data T = MkT (forall (a :: k) f. f a -> Int)
 }}}

 and you'll get `T2`, which has no existential kinds. Note that your first
 declaration, without polykinds, also has no existential variables. It has
 higher-rank variables, but not existential ones.

 As for the "could not deduce" error, I think it might be accurate, but I'm
 not sure. For example, consider

 {{{
 type family F :: Constraint

 x1 :: (forall b. F => Proxy b -> Int) -> ()
 x1 = undefined

 x2 :: (forall b. Proxy b -> Int) -> ()
 x2 = undefined
 }}}

 `x2` compiles fine. `x1` does not, with a "could not deduce" error much
 like the one above. Note that `F` is just some unknown constraint, much
 like `Ctx2`. My guess is that GHC is more timid about unifying under the
 scope of an equality constraint in `x1`.

 In `x2`, where the constraint is obviously not an equality, everything is
 fine.

 So, error messages could perhaps be improved (can't they always?) but I
 don't think GHC is wrong here.

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


More information about the ghc-tickets mailing list