Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#6046 closed bug (invalid)

inconsistent type error messages between ghc and ghci

Reported by: carter Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.5
Keywords: Cc:
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Incorrect result at runtime Test Case: see problem description
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

When building syb 0.3.6 with todays head / 7.5 I get different type error messages for the module Data/Generics/Twins.hs respectively from ghc when doing cabal install syb vs when i load that module into ghci

ghc:

src/Data/Generics/Twins.hs:202:14:

Illegal polymorphic or qualified type: GenericT Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `gzipWithT':

gzipWithT
GenericQ (GenericT) -> GenericQ (GenericT)

src/Data/Generics/Twins.hs:213:14:

Illegal polymorphic or qualified type: GenericM m Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `gzipWithM':

gzipWithM
Monad m => GenericQ (GenericM m) -> GenericQ (GenericM m)

src/Data/Generics/Twins.hs:223:14:

Illegal polymorphic or qualified type: GenericQ r Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `gzipWithQ':

gzipWithQ
GenericQ (GenericQ r) -> GenericQ (GenericQ [r])

src/Data/Generics/Twins.hs:265:9:

Illegal polymorphic or qualified type: GenericM Maybe Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `gzip':

gzip
GenericQ (GenericM Maybe) -> GenericQ (GenericM Maybe)

--- interestingly, rank2types is infact enabled in that module.

whereas when the module is loaded into ghci, I get a very different error message

Loading package base ... linking ... done. [1 of 2] Compiling Data.Generics.Aliases ( Data/Generics/Aliases.hs, interpreted ) [2 of 2] Compiling Data.Generics.Twins ( Data/Generics/Twins.hs, interpreted )

Data/Generics/Twins.hs:118:12: Not in scope: type variable `b'

Data/Generics/Twins.hs:118:17: Not in scope: type variable `a'

Data/Generics/Twins.hs:118:39: Not in scope: type variable `b'

Data/Generics/Twins.hs:118:42: Not in scope: type variable `a'


irrespective of fixing the type error (i hope to sort that out this evening), the type error message should be the same between ghc and ghci in this instance right?

Change History (4)

comment:1 Changed 3 years ago by carter

interestingly, when I add ScopedTypeVariables to the language pragma, ghci's type error agrees with the ghc type error.

comment:2 Changed 3 years ago by carter

this isn't relevant to this bug, but the type error associated with the bug goes away if the Language pragma for Data.Generics.Twins is changed from Rank2Types to RankNTypes

comment:3 Changed 3 years ago by dreixel

  • Resolution set to invalid
  • Status changed from new to closed

The syb.cabal file (see http://hackage.haskell.org/packages/archive/syb/0.3.6/syb.cabal) mentions the extension ScopedTypeVariables, but if you load the file on GHCi you won't get this. This explains the difference in behaviour between cabal install and just loading the file on GHCi.

The RankNTypes error itself is already reported as #6032. I think the best thing to do is to change syb; I'll release an updated version today.

comment:4 Changed 3 years ago by carter

that clarifies things. thanks!

Note: See TracTickets for help on using tickets.