On Fri, Oct 28, 2011 at 11:01, Ertugrul Soeylemez <es@ertes.de> wrote:

Brandon Allbery <allbery.b@gmail.com> wrote:
> The code is doing exactly what it says. getTwoChars reads two
> characters --- *not* a line. So the next character waiting to be read
> is the newline, which is returned by the next getTwoChars.
>
> This may depend to some extent on the platform, as Unix defaults to a
> line-oriented input interface (at the OS level) but Windows to
> character-oriented input.

I can't confirm that. This is true for compiled programs, but when
running

liftA2 (,) getChar getChar

on the GHCi command line, it seems to use NoBuffering.

The dependency is a little more complex than simply the tty line buffering mode; that simply obscures the problem a bit, it doesn't actually modify it. Specifically: in character mode each read terminates without the need to read a newline, whereas in line mode the newline is needed to pass characters from the OS to the program; but in either mode the newline is still read as a separate character. So in line mode it can *appear* to be treating each of those as a separate line, when in reality it isn't (and you find that out when you get the '\n').

(I don't recall offhand if the GHC runtime conflates the file buffering mode with the tty line mode on Unix. This is not the file handle buffering mode; it's the termios "icanon" setting. But ghci does seem to run with icanon cleared, at least interactively as distinct from ":main".)

--
brandon s allbery allbery.b@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms