From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sun, 12 Oct 2014 14:34:53 +0200 Message-ID: <874mv91n6a.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> <83y4srjaot.fsf@gnu.org> <83r3yhiu8c.fsf@gnu.org> <83siiw9c6t.fsf@gnu.org> <83zjd3846e.fsf@gnu.org> <8738auyxke.fsf@netris.org> <874mvaoys7.fsf@uwakimon.sk.tsukuba.ac.jp> <87h9z91y52.fsf@fencepost.gnu.org> <871tqdpjoi.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413117319 19742 80.91.229.3 (12 Oct 2014 12:35:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2014 12:35:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 12 14:35:13 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XdIMi-0002gS-Ow for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 14:35:12 +0200 Original-Received: from localhost ([::1]:57205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdIMi-0002Z2-Df for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 08:35:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdIMR-0002Yo-8o for emacs-devel@gnu.org; Sun, 12 Oct 2014 08:34:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdIMQ-00027w-Bp for emacs-devel@gnu.org; Sun, 12 Oct 2014 08:34:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdIMQ-00027s-8E for emacs-devel@gnu.org; Sun, 12 Oct 2014 08:34:54 -0400 Original-Received: from localhost ([127.0.0.1]:45737 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdIMP-0004wR-Gt; Sun, 12 Oct 2014 08:34:53 -0400 Original-Received: by lola (Postfix, from userid 1000) id 0FA4EE0691; Sun, 12 Oct 2014 14:34:53 +0200 (CEST) In-Reply-To: <871tqdpjoi.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sun, 12 Oct 2014 21:16:29 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175288 Archived-At: "Stephen J. Turnbull" 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