Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. fc50695e8d6a5cc0cebc3a8fcd0833ec1ff316a2

[Mike Gran <spk121@yahoo.com>]

On Sat, 2009-06-06 at 15:23 +0200, Ludovic Courtès wrote:
> Hi Mike,
> 
> Mike Gran <spk121@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