[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp's future
From: |
Richard Stallman |
Subject: |
Re: Emacs Lisp's future |
Date: |
Sun, 05 Oct 2014 17:49:47 -0400 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Supporting property lists in Scheme raises difficult questions
Do you mean text properties in strings, as in Emacs Lisp? These are
more complicated than an ordinary property list on an object as a
whole.
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?
* What should Scheme's 'write' do when applied to a string that
includes a property list? ('write' is analogous to 'prin1').
The obvious first suggestion is to handle each one as Emacs Lisp does.
For printing, a different syntax might be needed to fit in with Scheme
printed representation conventions, but that is ok.
* 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?
There are many ways to pass data from one piece of Scheme code to
another. Is there any real, usable "security" now, that this would
reduce? Can you give an example?
Given a self-contained Scheme program, it should be easy to determine
whether it ever examines or sets string text properties. Is that enough
to provide the same "security" benefits in practice?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/06
- Re: Emacs Lisp's future, David Kastrup, 2014/10/06
- Re: Emacs Lisp's future, Mark H Weaver, 2014/10/06
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Florian Weimer, 2014/10/11
Re: Emacs Lisp's future,
Richard Stallman <=
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/05
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/08
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/08
- Re: Emacs Lisp's future, David Kastrup, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09
Re: Emacs Lisp's future, Richard Stallman, 2014/10/10