#8889 closed bug (fixed)

GHCI reports nasty type signatures

Reported by: MikeIzbicki Owned by:
Priority: normal Milestone: 7.8.1
Component: GHCi Version: 7.8.1-rc2
Keywords: Cc: hvr
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Other Test Case: indexed_types/should_compile/T8889
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Load a file that contains:

{-# LANGUAGE TypeFamilies
           , ConstraintKinds
           , MultiParamTypeClasses
           , UndecidableInstances
           , FlexibleInstances 
  #-}

import GHC.Prim
import Prelude hiding (Functor(..))

class Functor f where
    type C_fmap_a f a :: Constraint
    type C_fmap_a f a = ()
    type C_fmap_b f b :: Constraint
    type C_fmap_b f b = ()
    fmap :: (C_fmap_a f a, C_fmap_b f b) => (a -> b) -> f a -> f b

    fmap1 :: (ValidFunctor f a, ValidFunctor f b) => (a -> b) -> f a -> f b
    fmap2 :: (ValidFunctor' f a, ValidFunctor' f b) => (a -> b) -> f a -> f b

type ValidFunctor f a = 
    ( Functor f
    , C_fmap_a f a
    , C_fmap_b f a
    )
    
class ValidFunctor f a => ValidFunctor' f a
instance ValidFunctor f a => ValidFunctor' f a
                                            

Then check the following types in ghci

ghci> :t fmap
fmap
  :: (t, t1, Functor f, C_fmap_b f b ~ t1, C_fmap_a f a ~ t) =>
     (a -> b) -> f a -> f b

ghci> :t fmap1
fmap1
  :: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1,
      C_fmap_a f b ~ t2, C_fmap_a f a ~ t) =>
     (a -> b) -> f a -> f b

ghci> :t fmap2
fmap2
  :: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1,
      C_fmap_a f b ~ t2, C_fmap_a f a ~ t) =>
     (a -> b) -> f a -> f b

These types are much nastier looking than they need to be. There are two problems:

1) Bogus types t,t1,t2,t3 are introduced when they don't need to be. This is confuses the type signatures quite a bit.

2) The type alias ValidFunctor is being desugared in the type signature for fmap1. This makes type aliases for constraints rather pointless.

Also, I tried to solve problem two by adding an extra class, and hoping the class would be displayed instead, but this still doesn't work. I assume this is actually intended behavior though.

Change History (4)

comment:1 Changed 16 months ago by Simon Peyton Jones <simonpj@…>

In 7a7af1ffc48f605cf365faf8fcef31ef4f13822b/ghc:

Unflatten the constraints of an inferred types (Trac #8889)

There was even a comment to warn about this possiblity,
and it finally showed up in practice!  This patch fixes
it quite nicely, with commens to explain.

comment:2 Changed 16 months ago by Simon Peyton Jones <simonpj@…>

comment:3 Changed 16 months ago by simonpj

  • Status changed from new to merge
  • Test Case set to indexed_types/should_compile/T8889

Excellent point, thank you. Fixed, with a regression test.

Could be merged if there is time, but not a big deal.

Simon

comment:4 Changed 16 months ago by thoughtpolice

  • Milestone set to 7.8.1
  • Resolution set to fixed
  • Status changed from merge to closed
  • Version changed from 7.8.1-rc1 to 7.8.1-rc2

Merged.

Note: See TracTickets for help on using tickets.