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. 823e444052817ee120d87a3575acb4f767f17475 Date: Thu, 28 May 2009 12:57:37 -0700 (PDT) Message-ID: <972327.22408.qm@web37904.mail.mud.yahoo.com> References: <87tz38u8jr.fsf@gnu.org> <799701.86503.qm@web37908.mail.mud.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1243540672 29968 80.91.229.12 (28 May 2009 19:57:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 May 2009 19:57:52 +0000 (UTC) Cc: =?iso-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu May 28 21:57:48 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 1M9ljX-0002Xw-QS for guile-devel@m.gmane.org; Thu, 28 May 2009 21:57:48 +0200 Original-Received: from localhost ([127.0.0.1]:42730 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9ljW-0000f5-Vs for guile-devel@m.gmane.org; Thu, 28 May 2009 15:57:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9ljU-0000el-Oe for guile-devel@gnu.org; Thu, 28 May 2009 15:57:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9ljP-0000dk-PO for guile-devel@gnu.org; Thu, 28 May 2009 15:57:44 -0400 Original-Received: from [199.232.76.173] (port=48520 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9ljP-0000da-Jb for guile-devel@gnu.org; Thu, 28 May 2009 15:57:39 -0400 Original-Received: from web37904.mail.mud.yahoo.com ([209.191.91.166]:42525) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1M9ljO-0007uf-TS for guile-devel@gnu.org; Thu, 28 May 2009 15:57:39 -0400 Original-Received: (qmail 23259 invoked by uid 60001); 28 May 2009 19:57:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243540657; bh=WXxlMc8CgxToH4HoDYjTKLYrl+wAIx1tEiG7KmeeF48=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mDgMfsGHQ58+mNafvvh0LKQ2k1k39VejIReThHDhBHqfPT49rV9zXSitl+mLu4jdcNZ1OInx9CwxJeiSlVdYF8EqMDFOtdWyuh5PcvBeprTWg+irsrHzdB5em/betIbVKQ7wds/WAQEGMdtjHjDKo+gXoVFPqnOCo2S8h6AbSVo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5fFnlqGXrQnFQrwG1MRDsIw2bXDD1jBUMsvrUyz6Eu0qHAlkllaSSt9s1WJf9EvgTUvX+FIecaETI8eNsSxiKm82huja/caJCDpJlsBE2jilnmbAqEH/XyprmwQk+dI5lldRk8obSaSGO4huuSOldvyNkOS1KXf8DIMwjWuTY/k=; X-YMail-OSG: hgekUcMVM1nTJZb8Tp9pMcHfnJUbOb65uRsXxSbkmWTK5nYD30AKvLHtp2exsq7gb3f1vAWld3bFnn4vsOGqbFSakqb20.4ungQdi5Jg0n3Ucjml2w09NhCxUZ9fKyt7ZBgoTzIj0Kmv8N1mB5K_5fBfJPJviFiFsJMXkrXDrWNQ.T2qEdpmHE_BL8cctW211lk2AekMJJmI6eJZfgr.5hB3jm3x6939llTYq_vP0FX9dgXvt82Edr_jMIVPFv8qOwhqb4uVFaNzUF6Bkh5HkA.8SCW45auvvMlwhY.opZ8EwSKfS.fD5Zvm6b899v0hvDZD5Bh6fpFae136oPLbGw-- Original-Received: from [64.52.12.130] by web37904.mail.mud.yahoo.com via HTTP; Thu, 28 May 2009 12:57:37 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) 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:8551 Archived-At: > From: Andy Wingo =0A> =0A> Hi Mike,=0A> =0A> > The reade= r could probably preprocess the file looking for where =0A> > the text "cod= ing: XXXXX" appears within a comment in the top dozen=0A> > lines of a sour= ce code file. Or perhaps a line that is explicitly=0A> > ";;;; #pragma codi= ng: XXXXX" in the top few lines of a file.=0A> =0A> This sounds almost sane= to me. I think python has a standard for this:=0A> =0A> =A0 http://www.pyt= hon.org/dev/peps/pep-0263/=0A> =0A> This is complicated in Guile by #!. A r= easonable thing would be to have=0A> the reader have a bit on whether it ac= tually saw an expression yet or=0A> not. If not, "^;+ [^\n]*coding: ..." wo= uld set the file's encoding.=0A=0AWorks for me.=A0 I'll do that.=A0=0A=0AAl= so, just for the record, it seems obvious that this character =0Aencoding p= ragma should only work on files, which is fine.=A0 I think=0Athat is the wa= y it would work.=A0 Once could imagine a use=A0where=0Asomeone loaded code = into a string and then passed it to scm_read()=0Afor interpretation.=A0 In = this case, I think "coding: XXXX" or=0Awhatever should not be interpreted.= =0A=0Ascm_read() can't handle this on its own because it has no "state".=0A= It is called once per expression.=0A=0AThis all means that grepping the cod= ing is a true preprocessing=0Astep, divorced from the reader.=0A=0A--=0A=0A= While we're on the topic, here's some serious pedantry about it all.=0AFasc= inating to me, of course.=A0 Less so to others, I'm sure.=A0 Feel=0Afree to= zone out...=0A=0AI went back and forth on the idea as to whether each port= should have=0Aits own dedicated character encoding, or if it was okay to h= ave a=0Asingle encoding for all ports in a thread.=A0 I've been going with = the=0Asingle-encoding plan because R6RS I/O ports have a strong API for=0At= hat, while legacy Guile port API=A0does not consider it.=A0 I've been=0Atry= ing not to=A0modify Guile API.=0A=0AFor backwards compatibility, if no loca= le or encoding is set, Guile=0Aports should still function exactly as befor= e.=A0 I don't want to break=0Aanything.=0A=A0=0AThe medium-term plan it tha= t if a program wants to read/write data that=0Ais not in its locale encodin= g, it should prefer R6RS ports.=A0 If it =0Awants to read/write data in its= current locale and encoding, Guile =0Aports or R6RS ports should handle th= at transparently.=0A=0AThe procedure scm_read is firm API and takes a port,= which means =0Athat the s-expression it reads will be interpreted in the c= ontext of=0Athe port's encoding.=A0 It is the default reader.=0A=0ABut, if = the reader is modified to take its character encoding from=0Athe top of the= file, then the reader can't use scm_read directly =0Aas it would use the p= ort's encoding.=0A=0AIt isn't as simple as pushing the old encoding, interp= reting =0Aunder the file's encoding, and then popping the old encoding, bec= ause=0Athe output to stdout and stderr would then appear in the file's=0Aen= coding and not the terminal's locale's encoding.=0A=0ASo it neads a new rea= der, scm_read_with_encoding() or some such.=0A=0A=0A=0A-Mike Gran=0A