From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sat, 27 Sep 2014 18:25:23 +0200 Message-ID: <87d2ahm3nw.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411835158 9378 80.91.229.3 (27 Sep 2014 16:25:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 16:25:58 +0000 (UTC) Cc: handa@gnu.org, Eli Zaretskii , dmantipov@yandex.ru, stephen@xemacs.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 27 18:25:52 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XXuoa-0001HC-VE for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 18:25:45 +0200 Original-Received: from localhost ([::1]:56489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXuoW-0000RY-2D for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 12:25:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXuoQ-0000RI-PO for emacs-devel@gnu.org; Sat, 27 Sep 2014 12:25:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXuoN-0004Ff-O9 for emacs-devel@gnu.org; Sat, 27 Sep 2014 12:25:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXuoN-0004FO-Gz for emacs-devel@gnu.org; Sat, 27 Sep 2014 12:25:31 -0400 Original-Received: from localhost ([127.0.0.1]:48618 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXuoG-0006wP-93; Sat, 27 Sep 2014 12:25:24 -0400 Original-Received: by lola (Postfix, from userid 1000) id CC7B3E08F5; Sat, 27 Sep 2014 18:25:23 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Sat, 27 Sep 2014 11:57:37 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174748 Archived-At: Stefan Monnier writes: >>>> The GUILE bridge is there. Robin Templeton's status of the port is th= at >>>> it is mostly complete, with strings/buffers being the most notable part >>>> obliterating acceptable performance via thick glue layers between Emac= s' >>>> and GUILE's different implementations of similar concepts. >>> Do you know this to be a fact? >> is about keeping >> them separate. >> lists "Unify Elisp >> and Scheme strings". >> I thought I read something from Robin about buffers/strings being a >> performance issue, but searching on the respective developer lists >> points rather to dynamic scopes and/or buffer-local variables. > > IOW, you do *not* know for a fact that this lack of unification is > a current source of performance problems. > Thought so. Shrug. I'm currently working on integrating GUILE 2.0 into LilyPond, and GUILE 2.0 has Unicode strings which are either UCS-8 or UCS-32 in the strings and UTF-8 in string ports (which are sort of like Emacs buffers on steroid withdrawal). So at the current point of time, Emacs and GUILE strings would need reencoding/decoding at every call gate anyway as long as string access is not abstracted well enough in the Emacs code base that the different internal coding would not require code changes. The VM costs would be negligible in comparison with that. I don't think that having to retain a separate implementation of strings in Emacs makes much sense in the course of integrating GUILE and Emacs. "reencode at every call gate" is not feasible for tight interaction, and tight interaction is desirable for an extension language after all. In our case, LilyPond has a lot of head-scratching to do in order to arrive at a state where GUILE and C++ strings can be passed through the system reasonably efficient since LilyPond _is_ designed to tightly interact with GUILE. The basic expediency mechanism is to tell GUILE "this is all latin-1" which it will then keep in UCS-8. Whenever there is an interest in Unicode string processing, we need to reencode. LilyPond itself is actually talking UTF-8 to its users. This kind of "we work with UTF-8, but consider it to be UCS-8 instead since we cannot or do not want to afford the price you demand for treating it as UTF-8" is not really a satisfactory solution, and I expect this to become an issue in other applications. So I pretty much expect that we'll see GUILE migrating to an UTF-8-based string representation eventually, with all the head-scratching regarding indexing and rewriting strings (aset anybody?) that Emacs has seen. In=A0case that happens, matching Emacs strings would make a lot of sense. Admittedly, that is more a problem of GUILE than Emacs. --=20 David Kastrup