From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Gran Newsgroups: gmane.lisp.guile.devel Subject: Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. fc50695e8d6a5cc0cebc3a8fcd0833ec1ff316a2 Date: Sun, 07 Jun 2009 21:51:33 -0700 Message-ID: <1244436693.2499.12953.camel@localhost.localdomain> References: <87d49ibwk0.fsf@gnu.org> <1244212019.2499.8500.camel@localhost.localdomain> <87d49hqywf.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1244436740 18375 80.91.229.12 (8 Jun 2009 04:52:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jun 2009 04:52:20 +0000 (UTC) Cc: Guile Devel To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 08 06:52:17 2009 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.50) id 1MDWqG-0005Lh-Va for guile-devel@m.gmane.org; Mon, 08 Jun 2009 06:52:17 +0200 Original-Received: from localhost ([127.0.0.1]:39846 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDWqG-0003qK-HZ for guile-devel@m.gmane.org; Mon, 08 Jun 2009 00:52:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDWpi-0003gh-Kq for guile-devel@gnu.org; Mon, 08 Jun 2009 00:51:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDWpg-0003gC-D7 for guile-devel@gnu.org; Mon, 08 Jun 2009 00:51:41 -0400 Original-Received: from [199.232.76.173] (port=43695 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDWpg-0003g4-2W for guile-devel@gnu.org; Mon, 08 Jun 2009 00:51:40 -0400 Original-Received: from smtp104.prem.mail.sp1.yahoo.com ([98.136.44.59]:35065) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MDWpf-0006PD-GP for guile-devel@gnu.org; Mon, 08 Jun 2009 00:51:39 -0400 Original-Received: (qmail 99842 invoked from network); 8 Jun 2009 04:51:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-Id:Mime-Version:X-Mailer:Content-Transfer-Encoding; b=CfDPHJoq/YxsdDW6XzYlBMyPH+1ov9wLC19GNfX47ZMmu9gai8qcfp2tiGCqv8S03CnSd+CG1tJr3Ofz3CEaZeb3MpB6Py6V6mHPh1YRF9nH8FYw2bHNUoozcgFeYayDJwzRAnaZpN1jz9q8Y91qLSYToRPpF3IVd8v5exDAsww= ; Original-Received: from ppp-71-140-200-82.dsl.irvnca.pacbell.net (spk121@71.140.200.82 with plain) by smtp104.prem.mail.sp1.yahoo.com with SMTP; 07 Jun 2009 21:51:37 -0700 PDT X-Yahoo-SMTP: FzNaA9iswBDuBl1BmgaIRDaP9Q-- X-YMail-OSG: CEsPK5gVM1mu_77qN7TnaYvqseHGxhuBDnoq38h6yMaiASmKoWVU.AQivJiwJ0.Dq0iRzfmeJv6uei09uoYyX6VeQpATmebLy.J9jaHPExKEy0Wm8p2m1YU2Sj46T4lGtPk8BAGqB7B_wSVdumhQSCYyu35xaxt_BzWBuA2wcY946_z4KhkXbV.4E.e_Oz2YiWoKq6Jzz1ETj5tVHtz7QLfcvndHyz4M6.OLxsTDI8_vWFCCQfS_w00ckLVqQpWld.qRJSzY02J1d7vwUjv.jMU6zuAFTZEL3YFtr8JR6PuWaosgAW9._a6s2DyrN1zonXKW_dcuZz3Y6V60rX34fV_X3rGczlE3kG_9 X-Yahoo-Newman-Property: ymail-3 In-Reply-To: <87d49hqywf.fsf@gnu.org> X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:8646 Archived-At: On Sat, 2009-06-06 at 15:23 +0200, Ludovic Courtès wrote: > Hi Mike, > > Mike Gran 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