残念ながらその通りである。それはまだ実装されていない。問題のあるモジュールは手でコンパイルしてからGHCiにロードしてほしい。

技術的な理由から、バイトコードコンパイラが特定の最適化過程とうまく相互作用しないので、解釈実行器を使うときは最適化が無効にしてある。これは大きな問題ではない。高速に実行されるべきコードは、コンパイルしておくことで、最適化つきで解釈実行するよりもずっと速く実行できる。

その通り。しかし、非ボックス化タプルを使うモジュールをコンパイルして、それをGHCiにロードするということは常にできる。(ちなみに、上記の、-OがGHCiで使えないというのは、バイトコードコンパイラが非ボックス化タプルを扱えないからである)

GHCiが-threadedスイッチを有効(デフォルト)にしてコンパイルされている限り、問題はないはずである。インストールしたGHCの供給元に相談してほしい。

それはgetContentsの定義通りの振る舞いである。getContentsはハンドルをセミクローズという状態にするが、その状態ではいかなるIO操作も禁止される。計算と計算の間でIOの状態は保持されるので、次に:loadか:reloadコマンドが実行されるまでセミクローズ状態が続く。

:set +rというコマンドでstdinが毎回元の状態に復元されるようにすることができる。これがうまく行くのは、stdinが単なるトップレベルの式で、他のトップレベルの式(CAF)と同様の方法で未評価の状態に戻すことができるからである。

12.2. WindowsでGHCiを実行するを参照。

GHCでは、デフォルトでstdoutハンドルは行バッファされている。しかし、GHCiでは、stdoutに関するバッファリングを無効にしてある。これが通常インタプリタに期待される振る舞いだからである。出力は生成されるとすぐに出現する。

GHCと同様の行バッファの振る舞いが欲しい場合は、プログラムを次のように始めれば良い。

               main = do { hSetBuffering stdout LineBuffering; ... }