# [R6RS] draft Unicode SRFI

Marc Feeley feeley
Fri Jul 1 10:24:32 EDT 2005

On 1-Jul-05, at 9:41 AM, Matthew Flatt wrote:

> I agree with this, but it doesn't solve the problem when a "text" file
> is already open in binary mode,

I don't understand what you mean here.  Do you mean that the compiler/
interpreter has opened the source file in binary mode?  Why would it
do that?  If it is opened in text mode, using the "universal" end-of-
line encoding ({CR+LF, CR, LF} map to #\newline) would solve the
problem, no?  You probably want this behavior anyway for here
strings, and to correctly keep track of source code location.

> or when someone treats a Windows text
> file as a Unix text file and redundantly translates it to a Windows
> text file (so that \r\r\n that decodes as \r\n). The question is
> whether to try to avoid those problems.

I agree that it is worth avoiding those problems, but the I/O system
should do this.

Marc