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.hsghc-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
Trac metadata
Trac field
Value
Version
6.6
Type
Bug
TypeOfFailure
OtherFailure
Priority
normal
Resolution
Unresolved
Component
GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Unknown
Architecture
Unknown
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
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.
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?
Could someone expand a bit on why there are infinite family of return conventions for unboxed tuples? And possibly how could this restriction be lifted?
The problem is at the boundary between compiled code and interpreted code. We have a few special-purpose stack frames that do the impedence matching between the two worlds, one for each return convention. The problem with unboxed tuples is that there aren't a fixed number of return conventions, so we can't cover all the cases with a few stack frames.
I haven't thought about this for a long time, but perhaps there's a way to make a generic stack frame that takes some kind of descriptor to describe the convention.
Auto-generate a bunch of return frames for different length tuples. Doesn't work because unboxed tuples can store unboxed data, so we get an exponential code size blowup.
Write a little interpreter (directly in Cmm) that looks at metadata in stack frame and does the appropriate operations. This one should work.
I've added a potential solution with a description of how it works in !4262 (closed)
It's the "make a generic stack frame that takes some kind of descriptor to describe the convention" suggested by @simonmar, with the addition of ordering the tuple elements on the stack to make it easy to convert. The descriptor fits in a single word (tuple_info).
I'll probably use the description in the MR as the basis for more documentation. Let me know if anything is unclear. I'd be happy to expand the docs or make changes to improve the approach.