Opened 6 years ago

Closed 16 months ago

Last modified 16 months ago

#4863 closed bug (fixed)

TH crashes if you reify the Name of a dfun

Reported by: guest Owned by: simonpj
Priority: low Milestone:
Component: Template Haskell Version: 7.0.1
Keywords: Cc: goldfire, jstolarek
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> $(fmap show (classInstances ''Eq [ConT ''Int] >>= reify . head) >>= lift)

    Exception when trying to run compile-time code:
      <interactive>: panic! (the 'impossible' happened)
  (GHC version 7.0.1 for x86_64-unknown-linux):
	reifyType PredTy
    <pred>base:GHC.Classes.Eq{tc 23} ghc-prim:GHC.Types.Int{(w) tc 3J}

Please report this as a GHC bug:

      Code: (>>=)
                   classInstances 'Eq [Language.Haskell.TH.Syntax.ConT 'Int]
                   (.) reify head)
    In the expression:
      $(fmap show (classInstances 'Eq [ConT 'Int] >>= reify . head)
    In an equation for `it':
          = $(fmap show (classInstances 'Eq [ConT 'Int] >>= reify . head)

The same thing happens when compiling with ghc rather than using GHCi. Also, it looks like the pretty printer is displaying ''Eq and ''Int incorrectly.

Change History (7)

comment:1 Changed 6 years ago by igloo

Milestone: 7.0.3

comment:2 Changed 6 years ago by simonmar

Owner: set to simonpj

comment:3 Changed 6 years ago by simonpj

Milestone: 7.0.3_|_
Priority: normallow
Summary: ghc panic when reifying the result of classInstancesTH crashes if you reify the Name of a dfun

Looking at this I realise that TH.classInstances has completely the wrong type. It should be

classInstances :: Name -> [Type] -> Q [ClassInstance]

Before we were returning [Name] where the Name was the name of the dictionary function of the instance.

I've fixed this. It's a API change, but classInstances is very new anyway. Patch to HEAD:

Thu Jan 13 11:14:21 GMT 2011
  * Make Template Haskell classInstances function return [ClassInstance]
  This is a recently-introduce function, which was returning
  a [Name], being the names of the dfuns.  But what you really
  want (obviously!) is the ClassInstances, and we have a TH type
  for that.
  This is an API change, so don't merge into GHC 7.0.  But it's
  a new part of TH which is still settling down.
  Fixes Trac #4863.

    M ./compiler/typecheck/TcSplice.lhs -3 +2

Patch to template-haskell library:

Thu Jan 13 11:54:37 GMT 2011
  * Change type of TH.classInstances (and qClassInstances)
  This patch accompanies the HEAD commit
    Thu Jan 13 11:14:21 GMT 2011
    * Make Template Haskell classInstances function return [ClassInstance]
  It accomplishes the data type change

    M ./Language/Haskell/TH.hs -1 +1
    M ./Language/Haskell/TH/Syntax.hs -2 +2

There's still a residual problem, in that a ClassInstance still contains the Name of the dfun, and you can't reify that; or at least doing so gives the above crash. Why? Because TH.Type doesn't have a representation for a type like

df :: forall a. Eq a => Eq [a]

I'm not sure of the best way to fix that. For example, reifying a dfun could yield a ClassInstance rather than a VarI; but that would need a new constructor in TH.Info. So I'm just going to leave it for now until it becomes imporant to someone. Meanwhile I'll re-title and make low priority.

comment:4 Changed 16 months ago by jstolarek

Cc: goldfire jstolarek added

Is this problem still present in the current implementation of TH? classInstances (now: reifyInstances) returns a proper list of instance declarations. I don't see any Names inside InstanceD constructor so I'm not sure if there's anything more to reify after calling reifyInstance?

comment:5 Changed 16 months ago by goldfire

Resolution: fixed
Status: newclosed

I agree. This ticket has been fixed over the course of time.

comment:6 Changed 16 months ago by simonpj

Could someone add a regression test? Thanks!

comment:7 Changed 16 months ago by goldfire

There's no need for one. This ticket had to do with Names appearing in the TH AST where they no longer appear. Despite the ticket title, the underlying problem was a design goof, not an implementation one.

Note: See TracTickets for help on using tickets.