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.
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).
This should work, as long as your GHCi was built with
	  the -threaded switch, which is the default.
	  Consult whoever supplied your GHCi installation.
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:
               main = do { hSetBuffering stdout LineBuffering; ... }