emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: Mark H Weaver
Subject: Re: Emacs Lisp's future
Date: Fri, 10 Oct 2014 16:41:43 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (gnu/linux)

Richard Stallman <address@hidden> 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 <obj>) 'foo)
  (my-property <obj>) => 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]