From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.bugs Subject: bug#18520: string ports should not have an encoding Date: Mon, 22 Sep 2014 22:39:29 +0200 Message-ID: <87d2anl79a.fsf@gnu.org> References: <87iokgmttc.fsf@fencepost.gnu.org> <87mw9rq20u.fsf@gnu.org> <87sijjlqx0.fsf@fencepost.gnu.org> <87sijjmvlr.fsf@gnu.org> <87bnq7lgg9.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411418437 30040 80.91.229.3 (22 Sep 2014 20:40:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2014 20:40:37 +0000 (UTC) Cc: 18520@debbugs.gnu.org To: David Kastrup Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Sep 22 22:40:28 2014 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XWAPH-0005WF-Eb for guile-bugs@m.gmane.org; Mon, 22 Sep 2014 22:40:23 +0200 Original-Received: from localhost ([::1]:49132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWAPG-0005jS-TS for guile-bugs@m.gmane.org; Mon, 22 Sep 2014 16:40:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWAP8-0005iN-Jl for bug-guile@gnu.org; Mon, 22 Sep 2014 16:40:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWAP2-0000rX-NS for bug-guile@gnu.org; Mon, 22 Sep 2014 16:40:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWAP2-0000nH-KP for bug-guile@gnu.org; Mon, 22 Sep 2014 16:40:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XWAOw-0002xl-Tn for bug-guile@gnu.org; Mon, 22 Sep 2014 16:40:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 22 Sep 2014 20:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18520 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 18520-submit@debbugs.gnu.org id=B18520.141141837611345 (code B ref 18520); Mon, 22 Sep 2014 20:40:02 +0000 Original-Received: (at 18520) by debbugs.gnu.org; 22 Sep 2014 20:39:36 +0000 Original-Received: from localhost ([127.0.0.1]:49229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWAOV-0002wt-9u for submit@debbugs.gnu.org; Mon, 22 Sep 2014 16:39:35 -0400 Original-Received: from hera.aquilenet.fr ([141.255.128.1]:55955) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWAOR-0002wj-Rv for 18520@debbugs.gnu.org; Mon, 22 Sep 2014 16:39:33 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 7714A3AE8; Mon, 22 Sep 2014 22:39:29 +0200 (CEST) Original-Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rti5oj3j8ye2; Mon, 22 Sep 2014 22:39:29 +0200 (CEST) Original-Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 032F43509; Mon, 22 Sep 2014 22:39:28 +0200 (CEST) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 1 =?UTF-8?Q?Vend=C3=A9miaire?= an 223 de la =?UTF-8?Q?R=C3=A9volution?= 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 In-Reply-To: <87bnq7lgg9.fsf@fencepost.gnu.org> (David Kastrup's message of "Mon, 22 Sep 2014 19:20:54 +0200") User-Agent: Gnus/5.130011 (Ma Gnus v0.11) Emacs/24.3 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7575 Archived-At: David Kastrup skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> David Kastrup skribis: >> >>> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its >>> own UTF-8 verification, error flagging, processing and indexing. >> >> Do I understand correctly that LilyPond expects Guile strings to be byte >> vectors, which it can feed with UTF-8 byte sequences that it built by >> itself? > > Not really. LilyPond reads and parses its own files but it does divert > parts through GUILE occasionally in the process. Some stuff is passed > through GUILE with time delays and parts wrapped into closures and > flagged with machine-identifiable source locations. OK. >>> If you take a look at >>> , >>> ftell on a string port is here used for correlating the positions of >>> parsed subexpressions with the original data. Reencoding strings in >>> utf-8 is not going to make this work with string indexing since ftell >>> does not bear a useful relation to string positions. >> >> AIUI the result of =E2=80=98ftell=E2=80=99 is used in only one place, wh= ile >> =E2=80=98port-line=E2=80=99 and =E2=80=98port-column=E2=80=99 are used i= n other places. > > The ftell information is wrapped into an alist together with a closure > corresponding to the source location. At a later point of time, the > surrounding string may be interpreted, and the source location is > correlated with the closure and the closure used instead of a call to > local-eval (which does not have the same power of evaluating materials > in a preserved lexical environment as a closure has). > >> The latter seems more appropriate to me when it comes to tracking >> source location. > > For error messages, yes. For associating a position in a string with a > previously parsed closure, no. But wouldn=E2=80=99t a line/column pair be as suitable as a unique identifi= er as the position in the file? Also, if the result of =E2=80=98ftell=E2=80=99 is used as a unique identifi= er, does it really matter whether it=E2=80=99s an offset measured in bytes or in charac= ter? (Trying to make sure I understand the problem.) Thanks, Ludo=E2=80=99.