Opened 10 years ago

Closed 10 years ago

Last modified 45 years ago

#267 closed bug (Wont Fix)

compiler panic with existential types and ... ?

Reported by: pimlott Owned by: nobody
Priority: normal Milestone:
Component: Compiler Version: None
Keywords: Cc:
Operating System: Architecture:
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

This code is is based upon a post by Oleg at
http://www.haskell.org/pipermail/haskell-cafe/2004-October/007160.html.

{-# OPTIONS -fglasgow-exts #-}
import Control.Monad.Trans

data Bar m = forall t. (MonadTrans t, Monad (t m)) =>
               Bar (t m () -> m ()) (t m Int)

data Foo = Foo (forall m. Monad m => Bar m)

runProg (Foo (Bar run op)) = run $ prog op

prog op = do
          lift $ putStrLn "Running prog"
          return ()
                                   
data ABC = A 
instance Show ABC where
  show A = "A"

main = putStrLn $ show A

It seems to be nearly minimal, though I have no idea
why.  When I compile with ghc 6.2.1 from Debian
unstable, I get

% ghc try.hs
ghc-6.2.1: panic! (the `impossible' happened, GHC
version 6.2.1):
        cgPanic
    zddMonad {- v aGa -}
    static binds for:
    local binds for:
    Main.prog {- v rz -}
    show {- v rJG -}
    SRT labelghc-6.2.1: panic! (the `impossible'
happened, GHC version 6.2.1):
        initC: srt

Change History (3)

comment:1 Changed 10 years ago by pimlott

  • Summary changed from compiler panic with show (?) to compiler panic with existential types and ... ?
Logged In: YES 
user_id=498741

Just changing the summary since the existential types are
likely closer to the root cause.

comment:2 Changed 10 years ago by simonpj

  • Status changed from assigned to closed
Logged In: YES 
user_id=50165

Good report.

This is definitely a bug in 6.2.1 and I guess 6.2.2 as well.
(If you use -dcore-lint, it falls over much earlier; the type
checker is generating the wrong translation.

The problem lies in the implicit instantiation of the polymorphic
function when you pattern match on Foo.  As it happens, I've
removed this ability altogether in GHC 6.4, because I couldn't
figure out all the interactions with GADTs.  (So 6.4 rejects
the program with a resonable error message.)  

You can get the
effect you want by doing the pattern match in two steps:

runProg (Foo b) = case b of
		    Bar run op -> run (prog op)

This work ok, both in 6.2 and in 6.4.  

Yes, it "should" be possible to nest the pattern match, but 
other things seem more important and there's an easy 
workaround; hence won't-fix.

comment:3 Changed 10 years ago by pimlott

Logged In: YES 
user_id=498741

thank you!
Note: See TracTickets for help on using tickets.