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 contributions, C and Lisp Date: Fri, 09 Jan 2015 12:14:01 +0100 Message-ID: <87fvbknr46.fsf@fencepost.gnu.org> References: <83bnxuzyl4.fsf@gnu.org> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <83ppat84hk.fsf@gnu.org> <20150106143933.0090bc83@jabberwock.cb.piermont.com> <83r3v77ij6.fsf@gnu.org> <20150106154539.3d0752c4@jabberwock.cb.piermont.com> <87wq4ype3z.fsf@fencepost.gnu.org> <20150108083211.5a85a077@jabberwock.cb.piermont.com> <877fwxpb63.fsf@fencepost.gnu.org> <83r3v55me9.fsf@gnu.org> <87wq4xqnlr.fsf@wanadoo.es> <83ppap5jp7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420802384 28830 80.91.229.3 (9 Jan 2015 11:19:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Jan 2015 11:19:44 +0000 (UTC) Cc: ofv@wanadoo.es, Eli Zaretskii , emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 09 12:19:39 2015 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 1Y9XWC-00015X-Pj for ged-emacs-devel@m.gmane.org; Fri, 09 Jan 2015 12:14:17 +0100 Original-Received: from localhost ([::1]:50061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9XWB-0000Yt-Lu for ged-emacs-devel@m.gmane.org; Fri, 09 Jan 2015 06:14:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9XW8-0000Yj-5I for emacs-devel@gnu.org; Fri, 09 Jan 2015 06:14:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9XW5-0006y9-NH for emacs-devel@gnu.org; Fri, 09 Jan 2015 06:14:12 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9XW5-0006y4-Kk for emacs-devel@gnu.org; Fri, 09 Jan 2015 06:14:09 -0500 Original-Received: from localhost ([127.0.0.1]:44254 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9XVy-0006iv-8Q; Fri, 09 Jan 2015 06:14:02 -0500 Original-Received: by lola (Postfix, from userid 1000) id A9071E06B2; Fri, 9 Jan 2015 12:14:01 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Thu, 08 Jan 2015 19:02:13 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:181097 Archived-At: Richard Stallman writes: > [[[ 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. ]]] > > > E.g., if it turns out that we need 99% of what is already in the > > AST, the argument for using it will be much more substantiated. > > For me, the concern is rather, > what IS in the AST that we DON'T need. A technical framework sculpted around making a particular limitation unavoidable is likely to end up cumbersome. It's definitely a good idea to provide a mechanism providing only the information necessary for a particular task. But predefining those bunches of compiler information a programmer is allowed to access or not is just putting a block on what functionality programmers may be inspired to implement on top of GCC. We don't want to end up with micromanaging restriction management of the "I'm sorry Dave, but I am afraid I can't do that" kind. GCC allows compiling binaries that are proprietary: at some point of time we draw a line of where we try exerting control over what people use tools for. It is a greater problem for us to definitely block free applications from being developed, either completely or by putting up prohibitely high administrative or technical hurdles, than it is to accept the possibility of non-free ones here. -- David Kastrup