2.11. FAQ and Things To Watch Out For

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

-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.

This should work, as long as your GHCi was built with
the -threaded switch, which is the default.
Consult whoever supplied your GHCi installation.

After using getContents, I can't use
stdin again until I do
:load or :reload.

This is the defined behaviour of
getContents: it puts the stdin Handle in
a state known as semi-closed, wherein
any further I/O operations on it are forbidden. Because I/O
state is retained between computations, the semi-closed
state persists until the next :load or
:reload command.

You can make stdin reset itself
after every evaluation by giving GHCi the command
:set +r. This works because
stdin is just a top-level expression that
can be reverted to its unevaluated state in the same way as
any other top-level expression (CAF).

In GHC, the stdout handle is line-buffered by default.
However, in GHCi we turn off the buffering on stdout,
because this is normally what you want in an interpreter:
output appears as it is generated.

If you want line-buffered behaviour, as in GHC, you can
start your program thus: