On Sat, 2009-06-06 at 15:23 +0200, Ludovic Courtès wrote: > Hi Mike, > > Mike Gran <spk...@yahoo.com> writes: > > > It would make things easier to follow, but, pure 7-bit ASCII would hurt > > backwards compatibility. The libunistring conversion funcs do raise > > errors when 8-bit chars are converted into ASCII. ISO-8859-1 could be > > better so that 8-bit chars wouldn't cause errors by default. > > Right, Latin-1 would be saner. >
Setting a port's default encoding to Latin-1 doesn't work out so well in practice. For example, ports are used as the backend of procedures like with-input-from-file and with-output-to-string. Those procedures don't currently take any encoding information and presume some sort of default encoding. Once could easily imagine a case where the locale is set to en_US.UTF-8 and then with-input-from-file is called. If non-Latin-1 characters appear in the file, the port will throw a conversion error. I think that would violate the principle of lease surprise. I prefer having a port inherit its default encoding from the last call to setlocale. This isn't a violation of R6RS Port I/O, since it states that the "native" transcoding may be both implementation dependent and locale-dependent. Less preferable, IMHO, is to modify all the with-input-from-* and with-output-to-* procedures to take optional explicit encodings. Thanks, Mike
