Skip to content

-fobject-code doesn't apply to expressions typed at the prompt

While looking to see if I could easily fix #1525 (closed) myself, I saw a suspicious modification to the unboxed tuples error; examining more closely:

stefan@stefans:~/qhc/qhc-desugar/Qhc/TypeCheck$ ghci
Loading package base ... linking ... done.
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |    GHC Interactive, version 6.7.20070612, for Haskell 98.
/ /_\\/ __  / /___| |    http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|    Type :? for help.

Prelude> :set -fglasgow-exts 
Prelude> let foo x y = (# x, y #)
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.
Prelude> :set -fobject-code
Prelude> let foo x y = (# x, y #)
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.
Prelude> 

so the suggested workaround doesn't actually work. I can certainly imagine a model of GHC compilation where the NCG doesn't support anonymous modules; in which case the easiest fix would be to tweak the error message. But interactive, optimizing, native compilation *does* sound like a cool and relatively cheap-to-implement feature :)

Trac metadata
Trac field Value
Version 6.7
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system Unknown
Architecture Unknown
Edited by Simon Marlow
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information