This is related to a relatively old issue, that the bytecode interpreter cannot handle UnboxedTuples: #1257 . Rather than fix that issue, which sounds quite challenging, how about adding some automagic to GHCi which builds object code for modules that use UnboxedTuples? This is a bit trickier than just compiling those modules to object code, because object code cannot be linked against byte code (see #10965). A potential solution to this is to also build all of the dependencies of modules that use UnboxedTuples using object code. This idea has some precedent, though as an external script - see #13101 and https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e . I think it would be best to put the solution to this directly in GHCi. What do you think? If y'all think it is a good idea, then I can volunteer to try to make it happen. As described in that ticket, this would be particularly helpful for loading GHC into GHCi, because GHC's code uses UnboxedTuples. Currently, `-fobject-code` must be used, which means that the speedup from using GHCi isn't quite as much as it could be. It is possible to get around this by first loading it with object code and then doing another load without object code, but that's rather inconvenient. Since this may be a surprising behavior change (the user may not have specified -odir and -hidir), it could possibly be enabled via a flag. <details><summary>Trac metadata</summary> | Trac field | Value | | ---------------------- | -------------- | | Version | 8.4.3 | | Type | FeatureRequest | | TypeOfFailure | OtherFailure | | Priority | normal | | Resolution | Unresolved | | Component | Compiler | | Test case | | | Differential revisions | | | BlockedBy | | | Related | | | Blocking | | | CC | | | Operating system | | | Architecture | | </details> <!-- {"blocked_by":[],"summary":"Have GHCi automatically use -fobject-code for modules that use UnboxedTuples","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is related to a relatively old issue, that the bytecode interpreter cannot handle UnboxedTuples: https://ghc.haskell.org/trac/ghc/ticket/1257 . Rather than fix that issue, which sounds quite challenging, how about adding some automagic to GHCi which builds object code for modules that use UnboxedTuples?\r\n\r\nThis is a bit trickier than just compiling those modules to object code, because object code cannot be linked against byte code (see https://ghc.haskell.org/trac/ghc/ticket/10965). A potential solution to this is to also build all of the dependencies of modules that use UnboxedTuples using object code.\r\n\r\nThis idea has some precedent, though as an external script - see https://ghc.haskell.org/trac/ghc/ticket/13101 and https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e . I think it would be best to put the solution to this directly in GHCi. What do you think? If y'all think it is a good idea, then I can volunteer to try to make it happen.\r\n\r\nAs described in that ticket, this would be particularly helpful for loading GHC into GHCi, because GHC's code uses UnboxedTuples. Currently, `-fobject-code` must be used, which means that the speedup from using GHCi isn't quite as much as it could be. It is possible to get around this by first loading it with object code and then doing another load without object code, but that's rather inconvenient.\r\n\r\nSince this may be a surprising behavior change (the user may not have specified -odir and -hidir), it could possibly be enabled via a flag.","type_of_failure":"OtherFailure","blocking":[]} -->