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