[ ghc-Bugs-1050406 ] compiler panic with existential types and ... ?

[SourceForge.net]

Bugs item #1050406, was opened at 2004-10-20 00:03
Message generated for change (Comment added) made by simonpj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1050406&group_id=8032

Category: Compiler
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Pimlott (pimlott)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler panic with existential types and ... ?

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Simon Peyton Jones (simonpj)
Date: 2004-10-20 11:12

Message:
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 By: Andrew Pimlott (pimlott)
Date: 2004-10-20 05:24

Message:
Logged In: YES 
user_id=498741

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1050406&group_id=8032