Bytecode generator can't handle unboxed tuples

[igloo]

We need to implement unboxed tuple support in ghci.

For example, with:

f :: a -> b -> (# a, b #)
f x y = (# x, y #)

we get:

$ ghci -v0 -fglasgow-exts w.hs
ghc-6.6: panic! (the 'impossible' happened)
  (GHC version 6.6 for x86_64-unknown-linux):
        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.

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[simonmar]

IIRC, it's not really feasible to do this in general. I'll investigate before 6.8 anyway.

[simonmar]

This isn't going to happen, mainly because there are an infinite family of return conventions for unboxed tuples. We could cover more cases without too much difficulty, but the general case is really hard. Given that you can now do -fobject-code, it doesn't really seem worth it.

[michalt]

I've just tried to load a file with the above example and ghci just printed a nice error message:

[1 of 1] Compiling Test             ( Test.hs, interpreted )
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
>

So if it is difficult to implement and one can use -fobject-code then maybe we should just close the ticket?

[simonmar]

Replying to michalt:

So if it is difficult to implement and one can use -fobject-code then maybe we should just close the ticket?

That's what the _|_ milestone is for: bugs that either we can't fix, or aren't important enough to fix.

In this case, wouldn't it be better if GHC just automatically switched on -fobject-code?

[igloo]

Let's either automatically enable -fobject-code, or add a suggestion to turn it on to the error message, and then close this ticket as wontfix.

[igloo]

Oh, the error already suggests -fobject-code.

I'm not a fan of magic like turning -fobject-code on automatically, so let's just mark this wontfix.