[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
More information about the R6RS
mailing list