Unfortunately not. We haven't implemented it yet. Please compile any offending modules by hand before loading them into GHCi.
-Odoesn'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.
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
This should work, as long as your GHCi was built with
-threaded switch, which is the default.
Consult whoever supplied your GHCi installation.
getContents, I can't use
stdinagain until I do
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
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.