From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sun, 05 Oct 2014 03:53:18 -0400 Message-ID: <871tqneyvl.fsf@netris.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> <87d2ahm3nw.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412517320 22342 80.91.229.3 (5 Oct 2014 13:55:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Oct 2014 13:55:20 +0000 (UTC) Cc: dak@gnu.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, Stefan Monnier , eliz@gnu.org, stephen@xemacs.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 05 15:55:12 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 1XamHF-0000Y1-Ni for ged-emacs-devel@m.gmane.org; Sun, 05 Oct 2014 15:55:09 +0200 Original-Received: from localhost ([::1]:47550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XamHF-0007qW-EW for ged-emacs-devel@m.gmane.org; Sun, 05 Oct 2014 09:55:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XagdW-00015o-TT for emacs-devel@gnu.org; Sun, 05 Oct 2014 03:53:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XagdQ-0007Im-VU for emacs-devel@gnu.org; Sun, 05 Oct 2014 03:53:46 -0400 Original-Received: from world.peace.net ([96.39.62.75]:54804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XagdE-0007Dw-CJ; Sun, 05 Oct 2014 03:53:28 -0400 Original-Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=jojen) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Xagd5-0006g4-K4; Sun, 05 Oct 2014 03:53:19 -0400 In-Reply-To: (Richard Stallman's message of "Sun, 28 Sep 2014 19:22:36 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-Mailman-Approved-At: Sun, 05 Oct 2014 09:54:56 -0400 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:174990 Archived-At: Richard Stallman writes: > So if we can't make use of Guile's strings because they're not good > enough, then we won't use them. > > Unfortunately, that would put a major crimp in interoperability between > Emacs Lisp programs and Scheme programs. > > Can the Guile developers work on making Guile strings flexible > enough that Emacs can use them? So that they can do the jobs > Emacs Lisp strings do? I would like to change Guile's internal string representation to use a generalization of UTF-8, as used by Emacs. There are two sticking points that require more thought, however: * I'm concerned that there are security implications to supporting the "raw byte" code points. I can expand on this more if you'd like. However, I think this will not be a problem, because the string<->bytevector conversion procedures could support two modes of operation: one mode that supports these raw bytes, for use by emacs and maybe some other purposes (e.g. dealing with POSIX file names), and another mode that refuses to accept or produce invalid UTF-8, which would be used by programs where security is a concern. I'm inclined to make the standard Scheme procedures use the strict mode by default. * I'm not sure that Guile strings should include property lists. One can reasonably assume that competent Elisp programmers will keep in mind that Elisp strings are more than just characters, but we cannot expect that of Scheme programmers, and they've never had any tools to deal with it in any case. Emacs lisp includes procedures such as 'substring-no-properties', but Scheme has never had anything like that. Supporting property lists in Scheme raises difficult questions such as: * What should the Scheme procedures 'string=?' and 'equal?' do when comparing two strings with the equal character sequences but unequal property lists? * Should Scheme procedures such as 'substring', 'string-append', 'string-upcase', etc, propagate the associated property list data? * Are there security implications to carrying around and possibly propagating (via Scheme's "substring") extra information that is effectively invisible to all procedures that have ever been available in Scheme? * What should Scheme's 'write' do when applied to a string that includes a property list? ('write' is analogous to 'prin1'). Security concerns are more important for Guile than for Emacs, because Guile is already being used to implement network programs such as web servers, and generally aims to support a much wider range of applications. At the very least, we can plan to eventually make Emacs strings representable as Guile strings plus property lists. Going further will require more consideration, I think. * * * While we're on the subject of interoperability between Emacs Lisp and Scheme programs, I'm concerned about nil. Modern Scheme requires that () and #f are distinct objects, and that () is treated as true by 'if'. This has been the case for long enough now that it's not uncommon for modern Scheme code to depend on these facts. Of course, Elisp code depends on the end-of-list and false values being the same object. The way we're coping with this is by having three distinct objects in Guile: (), #f, and #nil, where both () and #nil are considered end-of-list markers by 'null?', both #f and #nil are considered false by Scheme 'if', and all three are seen as null by Elisp. First of all, clearly this is not quite correct. Scheme code might assume that if a value is false, it cannot be the empty list, or vice versa, but the hope is that it will mostly work in practice. However, I see a problem that will become more common if Scheme and Elisp code become more intertwined. The problem occurs when Elisp code sees that a value 'x' is null and then copies it somewhere, where the original 'x' was conceptually an end-of-list, but the copy is conceptually a boolean false (or vice versa). (I'm aware that for some Elisp values, it may not even be possible to say it's "conceptually an end-of-list" or "conceptually a boolean false", but please bear with me). The problem comes when 'x' originated in Scheme code as (), is later copied by Elisp code into something that's conceptually a boolean, and then that copy is inspected by Scheme code. The intent was that the copied boolean would be false, but the Scheme code will see () and treat it as true. What do you think? Do I worry too much? :) Mark