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: Fri, 10 Oct 2014 16:41:43 -0400 Message-ID: <87lhonlks8.fsf@yeeloong.lan> 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> <871tqneyvl.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412973811 19981 80.91.229.3 (10 Oct 2014 20:43:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Oct 2014 20:43:31 +0000 (UTC) Cc: dak@gnu.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org, stephen@xemacs.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 10 22:43:23 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 1Xch21-00045u-W7 for ged-emacs-devel@m.gmane.org; Fri, 10 Oct 2014 22:43:22 +0200 Original-Received: from localhost ([::1]:50985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xch21-0003LN-Ep for ged-emacs-devel@m.gmane.org; Fri, 10 Oct 2014 16:43:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xch1j-0003L6-11 for emacs-devel@gnu.org; Fri, 10 Oct 2014 16:43:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xch1d-0006gG-3p for emacs-devel@gnu.org; Fri, 10 Oct 2014 16:43:02 -0400 Original-Received: from world.peace.net ([96.39.62.75]:36275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xch1Q-0006TZ-Id; Fri, 10 Oct 2014 16:42:44 -0400 Original-Received: from turntable.mit.edu ([18.160.0.29] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Xch18-0004LZ-Ko; Fri, 10 Oct 2014 16:42:26 -0400 In-Reply-To: (Richard Stallman's message of "Sun, 05 Oct 2014 17:49:47 -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-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:175240 Archived-At: Richard Stallman writes: > Supporting property lists in Scheme raises difficult questions > > Do you mean text properties in strings, as in Emacs Lisp? Yes. Having mulled it over, I've come to the conclusion that we can add text properties to Guile strings without adding new security risks to competently written Scheme code, with the following caveat: text properties must be invisible to all existing Scheme procedures, including 'equal?' and 'write'. However, as an exception to the caveat above, I think we can allow existing Scheme string operations such as 'substring' and 'string-append' to propagate the text properties. If you'd like to learn how I came to these conclusions, continue reading, otherwise you can stop here. * * * Guile already supports weak-key (eq) hash tables, upon which we've trivially implemented something called "object-properties": (define my-property (make-object-property)) (set! (my-property ) 'foo) (my-property ) => foo Effectively, this allows anyone to add a new private field to any object. The new field is invisible to anything that doesn't know about the object property, including equality predicates and all other standard procedures. So we could use object-properties to add text properties to Guile strings. Therefore, we can regard it as a mere efficiency hack to add a new field to our string objects, as long as the semantics are the same as if the new field was an object-property. However, this still leaves open the question of whether *propagating* these text properties to newly-allocated strings (by 'substring', 'string-append', etc) adds new risks. This next step makes me a bit uneasy, but I think it will also be okay, because standard Scheme does not require 'eq?' to be usable on characters, i.e. it does not require characters to be immediates or even interned. This means that we could, in principle, use object-properties to associate text properties with the characters themselves, instead of with the string objects. This would quite naturally lead to them being copied by string operations such as 'substring' and 'string-append'. Therefore, it seems to me that adding text properties to Guile strings does not add any security issues that are not already present in standard Scheme. What do you think? Mark