Re: `mike-port-encodings' branch (bug #29643)

[Mike Gran]

> From: Ludovic Courtès <address@hidden>
> Hello Mike,

> Thanks for working on this!

> Here’s a review of the ‘mike-port-encodings’ branch.


> Hmm, “simplification”?  :-)

> Is this commit really needed?  What’s the operational effect?

That commit has no net effect; however, the code
uses the 'i' variable in a for loop as an iterator and then
uses its value after the loop.  Using a for loop iterator
variable after the loop is complete is bad style, IMHO.

> OK.  Would it be possible to write a test case, 
> perhaps with a string port?

Sure.

>>  +Returns, as a string, the character encoding that 
>> @var{port} uses to interpret
>>  +its input and output.  The value @code{#f} is equivalent to 
>> @code{"ISO-8859-1"}.

> Instead of having the #f special case, I’ve been 
> thinking that it would be nicer and easier to have ‘port-encoding’ always 
> return a string (similar for ‘set-port-encoding!’), which would be 
> "ISO-8859-1" instead of #f.  Perhaps it’s a bit late, 
> though.

> What do you think?

I have no problem with that.  But, there is some small optimization that
comes from using NULL and SCM_BOOL_F as shorthand for ISO-8859-1,
because is eliminates a strcmp operation before each block of port text
is read or written.

[...]

> I dislike this whole notion of “binary-compatibility”.  What is meant
> here is that for binary I/O, 
> you’d better choose ISO-8859-1 as theport’s encoding because non-ASCII byte 
> values will go through as is,right?  (I suppose that’s true of any 
> 8-bit encoding.)

In the documentation, (rnrs io ports) could be recommended for binary
ports.  No problem.

But do you agree with the idea that Guile should force 8-bit encoding when
a legacy binary port is opened?  Or should it still inherit 
%default-port-encoding?
Which if those does not violate the 'principle of least surprise'?

-Mike