Re: Emacs Lisp's future

[Christopher Allan Webber <cwebber@dustycloud.org>]

Mark H Weaver writes:

> Richard Stallman <rms@gnu.org> 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

It sounds, if I am reading this right, that the mechanism by which
properties are being added to scheme strings means that no actual
changes need to be made to Guile strings' datastructures.  If true, that
sounds like a very efficient and ideal solution because it is so
generic.

In fact, I gave it a whirl... you mean something like this?

  (define elisp-properties (make-object-property))
  
  (define (elisp-propertize string . args)
    (let ((copied-string (string-copy string)))
      (set! (elisp-properties copied-string) args)
      copied-string))
  
  (define my-monkey
    (elisp-propertize "monkey" 'eats 'bananas))
  ;; => "monkey"
  
  (elisp-properties my-monkey)
  ;; => (eats bananas)

That's awesome!  And it doesn't feel like we're changing Guile in any
core way just to accomodate elisp, and it seems bidirectionally
compatible...

But as for copying around property lists when copying strings, making
substrings, etc, I think I'm more uncomfortable with that idea using
default Guile methods.  That seems like changing the language in a
substantial way that may even have strange performance issues or
unexpected side effects... would we do such a thing if this were
anything other than Emacs?  Would we do it for Javascript?

But it doesn't seem to me like we need to worry: why not just add a
library like this:


  (use-module (language elisp string-tools))
  
  (elisp-substring (elisp-propertize "monkeys" 'eat 'bananas) 3 6)
  ;; => this would return "key", but with object properties of
  ;;    (eat bananas)
  
  (elisp-substring "monkeys" 3 6)
  ;; => this would return "key", but with no object properties

  (elisp-substring (elisp-propertize "monkeys" 'eat 'bananas) 3 6)
  ;; => this would return "key" with no object properties


The version of substring provided in emacs lisp would of course be
elisp-substring, and strings would work between guile and emacs, but as
for copying around strings with properties, only functions in guile
which care about this would have to deal with it and deal with any
related concerns.

 - Chris