nobsun です.

> > hIsEOF がバッファに対して hGetChar と同様の振る舞いになっていないのは
> > 何か理由があるんだろうか...
> 
> むしろ、GHC の hGetChar が特別な振る舞いをすることになったようです。
> 
> fptools/libraries/base/GHC/IO.hs CVS revision 1.13 log より抜粋
> 
> When doing hGetChar on a block-buffered handle, don't wait for the
> buffer to be completely full before returning a character.  This
> behaviour seems more useful, and matches what hGetLine and
> hGetContents do.

なるほど,ふむふむ.
 
> Without this, to do an unbuffered read you have to set the buffering
> on the Handle to NoBuffering, which adversely affects the performance
> of writes.  With this change, there is now no difference between line
> buffering and block buffering for read operations.

hIsEOF には言及していないですねぇ.

> Possibly fillReadBuffer can now be simplified, since the is_line
> parameter is always True.  

base/GHC/Handle.hs と base/GHC/IO.hs で fillReadBuffer を定義している
ところと,呼び出しているところを変更して GHC-6.4 を再構築してみました.

しばらくこれで使ってみようっと...

> However, this is a delicate part of the IO
> library, and I don't want to remove the possiblity of forcing a
> complete buffer-fill in the future.

たとえば,どんなところが微妙なんでしょうねぇ.

--nobsun
 

--
ML: haskell-jp / quickml.com
使い方: http://QuickML.com/