Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> We advocate a default that is safer for the user,

GUILE is not a user application but a programming language.

> who may lose their life savings if a filter for 419 phish fails

Can we have terrorism with that scaremongering?

> because a character is encoded with "long" UTF-8, and fails to match
> the regexp which expects the character and not rawbytes.

I am glad that Emacs and sed and other utilities don't trash PostScript
files by default in order to save me from phishing.

> I don't know that there are any Emacs MUA users who have ever fallen
> for a phishing message, but I assure you that I personally have
> observed "long" UTF-8 in messages that are otherwise duplicates of
> correctly encoded spams.  Those bastards don't miss a trick.

So?  Does that mean that string operations should throw an error when
encountering $$$$$$$$$$$$$ in a string?  To save the user from scams?

If you keep confusing the responsibilities of platform, application and
user, you arrive at a system you have to work around with constantly
because it knows better than you what you want.

A network application that throws exceptions internally when fed
non-UTF-8 byte combinations is an attack vector for denial-of-service
attacks.  And since the naive programmer does not expect exceptions for
just reading strings, this is a very real danger.  And since GUILE is an
extension language, implicit conversions for C/GUILE call gates are hard
to avoid, and when every call gate is locked towards passing strings
representing arbitrary data, you will not be able to use libraries
without having access to the semantics of every call gate.

At any rate, there is no point to this discussion.  It tends to solve
itself in practice by developers at some point of time becoming tired of
ever the same application programmer level problems getting reported,
and application programmers becoming tired of ever the same developer
attitude regarding internals that refuse to "simply work".

At least I am still allowed to call cons without triggering an error
when the second argument is not a list.

-- 
David Kastrup