David Roundy
...when in text mode on DOS-descended systems, the character sequence "\r\n" is converted to "\n" by the operating system.
So basically, Windows supports both the "\n" convention and the "\r\n" convention by making a distinction between "text" and "binary" read modes. No other major operating system requires this distinction -- they are all *nixen -- so it seems reasonable to just punt on it. It would be too bad, though, if this resulted in a lot of Windows specific code getting written -- there are a lot of Windows users and eventually they'll unionize or something. People will throw together System.Win32.TextMode or something like that and then projects will be littered with platform specific code, though they needn't be. If we just put up a `textMode` filter, then everyone will have to throw that in front of their reads/writes to guard against corruption on Windows. We'll have verbose, silly looking code. If, on the other hand, we just give in to Windows, then some things are good and some are bad. First of all, if hGetLine has Windows behaviour on Windows and Unix behaviour on Unix, then any data files shipped with Cabal packages will likely need to be newline transformed. That is annoying. On the other hand, the semantics of 'getting a line' will be maintained across platforms, and the Windows users will be pacified (for a time). We all know what appeasement got the British... -- _jsn