From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: `mike-port-encodings' branch (bug #29643) Date: Wed, 16 Jun 2010 23:13:44 +0200 Message-ID: <877hlyk7ef.fsf@gnu.org> References: <87typdyx8o.fsf@gnu.org> <604202.69520.qm@web37905.mail.mud.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1276722852 29234 80.91.229.12 (16 Jun 2010 21:14:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2010 21:14:12 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jun 16 23:14:10 2010 connect(): No such file or directory Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OOzw1-0001du-LA for guile-devel@m.gmane.org; Wed, 16 Jun 2010 23:14:09 +0200 Original-Received: from localhost ([127.0.0.1]:41086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOzw0-0006jF-Kz for guile-devel@m.gmane.org; Wed, 16 Jun 2010 17:14:08 -0400 Original-Received: from [140.186.70.92] (port=52566 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOzvt-0006gn-HA for guile-devel@gnu.org; Wed, 16 Jun 2010 17:14:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOzvs-00008r-1M for guile-devel@gnu.org; Wed, 16 Jun 2010 17:14:01 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:40855) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOzvr-00007H-IO for guile-devel@gnu.org; Wed, 16 Jun 2010 17:13:59 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OOzvl-0001X4-OT for guile-devel@gnu.org; Wed, 16 Jun 2010 23:13:53 +0200 Original-Received: from acces.bordeaux.inria.fr ([193.50.110.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jun 2010 23:13:53 +0200 Original-Received: from ludo by acces.bordeaux.inria.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jun 2010 23:13:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 67 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: acces.bordeaux.inria.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 28 Prairial an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:z23iNGo8QMf7uvfGEostp//wwTM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10502 Archived-At: Hi Mike, Mike Gran 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’.