Re: Emacs Lisp's future

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> The competition is severe, and there are many very strong alternatives
> for the use cases Guile would like to serve: Java, Python, Perl, and
> Ruby, and you can add PHP for web applications.  Guile can't afford to
> acquire the kind of reputation that PHP had for carelessness in
> security matters.

I don't buy the claims that the ability to faithfully represent
arbitrary input in a consistent and reprodusible manner fully supported
by all internal operations and kept unconfusable with other characters
equals "carelessness in security".

In fact, not being able to even _look_ at such material or have a
representation for it seems like a much more severe shortcoming.

Now you claim that you want such support but only if very explicitly
requested, making it a second-class citizen.

This set of priorities has left XEmacs without a round-trippable UTF-8
representation even to date.  I've also already given an example of
GUILE code that is unable to losslessly pass a string through a string
port (the standard mechanism for _accumulating_ a string).  Again, this
is an outcome of the "let's cater primarily for good encodings"
philosophy that is at the bottom of _many_ security problems.  And of
course a perfect vector for denial of service attacks.

An engine that is not able without extra measures to reproduce its input
is not going to win friends.  And it's not like this is an actual
security feature.

What's next?  Text processors that cut off lines after column 80 as a
security feature?  Because people might not see those characters, it is
safer to remove them?

-- 
David Kastrup