GHCi and Unboxed tuples

[Simon Marlow]

> 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