2

Here is minimal complete example:

import Control.Monad
import System.IO

loop :: IO ()
loop =
    do line <- getLine
       putStrLn line
       eof  <- isEOF
       unless eof loop

main = loop

This program is supposed to read a line, print it out, stop if there is 'end of file' character in stdin. It doesn't leave the loop at all.

If I put eof <- isEOF before putStrLn line the program behaves very strange (try it!). I cannot get it at all: how putStrLn can possibly affect input stream and why doesn't the program terminate when I put 'end of file' character into stream (with Ctrl+D)?

Description of program's behavior when eof <- isEOF goes before putStrLn line:

After entering of a line, program does not print the entered line, but expects more input. As it gets more input, it starts to print previously entered lines. This is log of a test:

foo
boo
output: foo
bar
output: boo
baz
output: bar
< here I press Ctrl-D >
output: baz

Source:

import Control.Monad
import System.IO

loop :: IO ()
loop =
    do line <- getLine
       eof  <- isEOF
       putStrLn $ "output: " ++ line
       unless eof loop

main =
    do hSetBuffering stdin LineBuffering
       loop
Mark Karpov
  • 7,499
  • 2
  • 27
  • 62
  • I wonder if this is somehow related to stream buffering? What happens if you `hSetBuffering LineBuffer stdin`? – MathematicalOrchid Oct 22 '14 at 13:01
  • Do you use Windows? The EOF character is `Ctrl+Z` in Windows. Yay. – Zeta Oct 22 '14 at 13:02
  • @Zeta, I don't use Windows for anything but games. I'm on Arch Linux. – Mark Karpov Oct 22 '14 at 13:03
  • @MathematicalOrchid, it's `hSetBuffering stdin LineBuffering` actually :-) Yes, now eof has effect! – Mark Karpov Oct 22 '14 at 13:10
  • @MathematicalOrchid, However, when I put `isEOF` *before* `putStrLn` output is delayed. – Mark Karpov Oct 22 '14 at 13:12
  • Are you talking about the behavior in ghci? The program works as expected when I compile and run it. (By the way, there is no such thing as "end of file character".) – Reid Barton Oct 22 '14 at 14:07
  • @ReidBarton, I maybe wrong, of course. But what about [this Wikipedia article](http://en.wikipedia.org/wiki/End-of-file). It seems like 'eof-character' exists for some people.. – Mark Karpov Oct 22 '14 at 14:11
  • @ReidBarton, The program does not work as expected after compilation (not under ghci). If I add `hSetBuffering stdin LineBuffering` before loop, it will work fine. If I put `isEOF` before `putStrLn` output will be delayed. I need to check eof before processing, so it is quite strange and unpleasant. – Mark Karpov Oct 22 '14 at 14:17
  • Please be more specific than "does not work as expected". We don't know what behavior you're seeing. – Reid Barton Oct 22 '14 at 14:23

1 Answers1

4

From http://lambda.haskell.org/platform/doc/current/ghc-doc/libraries/haskell2010-1.1.1.0/System-IO.html#g:11:

NOTE: hIsEOF may block, because it has to attempt to read from the stream to determine whether there is any more data to be read.

The putStrLn doesn't affect the isEOF, but the isEOF prevents the program from getting to the putStrLn before more characters are available, or you have actually pressed ^D.

So you should never use hIsEOF/isEOF until the point in the program where you are ready to read more characters if there are any.

Ørjan Johansen
  • 18,119
  • 3
  • 43
  • 53
  • Great, knowing this information I was finally able to completely fix my program. Thanks a lot. – Mark Karpov Oct 22 '14 at 15:10
  • I've stumbled upon this answer, but I don't understand the explanation. What does "characters are available" mean exactly? As well as "until the point in the program where you are ready to read more characters if there are any" - where is it reading from? – Chris Stryczynski Mar 19 '18 at 19:32
  • @ChrisStryczynski In this question, characters are read from GHCi or a terminal with line buffering. Characters are available when the user has typed them and pressed enter. Alternatively, EOF is signalled by pressing ^D at the beginning of a line. A program cannot know in advance which of these the user will do, and so `isEOF` may have to wait. Unless `isEOF` is carefully placed this gives confusing looking timing issues when the output is also going to GHCi / the terminal. – Ørjan Johansen Mar 20 '18 at 02:42