I just finished tracking down the source of the following error from GHCi:
ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session.
Some clue to the source of the problem would be quite helpful. (I expect just about anything to at least be sometime useful -- even if it's the low-level input to bytecode generator.)
It turns out the source of the problem is a definition in an imported .hi file. Would it be possible for GHCi to prune the inlined definitions containing unboxed tuples and use the non-inlined ones? (Are the non-inline definitions are in the object file? "nm" suggests they are.)
GHC shouldn't be using any unfoldings in bytecode mode, because optimisation should be off (this is one reason that optimisation is forced off for GHCi). So I'm a bit confused as to why this might be happening: of course, there are *lots* of unfoldings in .hi that use unboxed tuples, and mostly they don't cause any problem for GHCi.
The best fix, of course, would be to make the bytecode generator handle unboxed tuples.
Unfortunately we can't do this, due to the way that the bytecode evaluator works. We can handle specific instances of unboxed tuples, but handling them in general isn't possible because the return convention depends on the number and types of the components of the unboxed tuple, which would require us to generate some non-trivial machine code in the bytecode generator. Cheers, Simon