3.9. FAQ and Things To Watch Out For

System.exit causes GHCi to exit!

Yes, it does.

System.getArgs returns GHCi's command line arguments!

Yes, it does.

The interpreter can't load modules with FFI declarations!

Unfortunately not. We haven't implemented it yet. Please compile any offending modules by hand before loading them into GHCi.

Hugs has a :add command for adding modules without throwing away any that are already loaded. Why doesn't this work in GHCi?

We haven't implemented it yet. Sorry about that.

-O doesn't work with GHCi!

For technical reasons, the bytecode compiler doesn't interact well with one of the optimisation passes, so we have disabled optimisation when using the interpreter. This isn't a great loss: you'll get a much bigger win by compiling the bits of your code that need to go fast, rather than interpreting them with optimisation turned on.

Unboxed tuples don't work with GHCi

That's right. You can always compile a module that uses unboxed tuples and load it into GHCi, however. (Incidentally the previous point, namely that -O is incompatible with GHCi, is because the bytecode compiler can't deal with unboxed tuples).

Concurrent threads don't carry on running when GHCi is waiting for input.

No, they don't. This is because the Haskell binding to the GNU readline library doesn't support reading from the terminal in a non-blocking way, which is required to work properly with GHC's concurrency model.