guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: Re: `mike-port-encodings' branch (bug #29643)
Date: Wed, 16 Jun 2010 23:13:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Mike,

Mike Gran <address@hidden> writes:

>> 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.

Hmm right.  Looking again at this part, it looks like the new variable
names are indeed more descriptive than before, and that ‘i’ is not
reused throughout may help, so OK.

Please change the commit log from “cleanup” to something that briefly
describes the actual change, though.

>>>  +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.

Hmm, right.  Then forget about what I said.

However, it would be nice if the documentation would state the
equivalence of #f and ISO-8859-1 in a single place.

>> 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.

OK, with an xref to that part of the doc right after the description of
the ‘b’ flag.  :-)

> But do you agree with the idea that Guile should force 8-bit encoding when
> a legacy binary port is opened?

Yes.

>   Or should it still inherit %default-port-encoding?  Which if those
> does not violate the 'principle of least surprise'?

ISO-8859-1 is probably best in that respect.

Thanks,
Ludo’.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]