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: Sun, 11 Jan 2015 11:15:45 +0100 Message-ID: <87fvbhk4ha.fsf@fencepost.gnu.org> References: <54B1B97E.9070204@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420971369 29709 80.91.229.3 (11 Jan 2015 10:16:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 10:16:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jacob Bachmeyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 11:16:04 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 1YAFYv-0000vF-IR for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 11:16:01 +0100 Original-Received: from localhost ([::1]:57840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFYu-0001nq-LK for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 05:16:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFYh-0001nl-Va for emacs-devel@gnu.org; Sun, 11 Jan 2015 05:15:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAFYg-00064u-FH for emacs-devel@gnu.org; Sun, 11 Jan 2015 05:15:47 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFYg-00064n-8d for emacs-devel@gnu.org; Sun, 11 Jan 2015 05:15:46 -0500 Original-Received: from localhost ([127.0.0.1]:49514 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFYf-0002No-PH; Sun, 11 Jan 2015 05:15:46 -0500 Original-Received: by lola (Postfix, from userid 1000) id 5FCF3DF8C9; Sun, 11 Jan 2015 11:15:45 +0100 (CET) In-Reply-To: <54B1B97E.9070204@gmail.com> (Jacob Bachmeyer's message of "Sat, 10 Jan 2015 17:45:02 -0600") 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:181144 Archived-At: Jacob Bachmeyer writes: > I've been reading this in the list archives and as a long-time > GNU/Linux user, feel the need to chime in. > > Perhaps there is a better option? I seem to remember efforts to adapt > Guile to run Emacs Lisp and then to port Emacs to run using Guile > instead of its own runtime. I'm not certain of the difficulty, but > perhaps GCC could be, over time, moved towards an option to build as > Guile extensions? I haven't looked far enough into this to know if it > is feasible, or how much work would be needed, or if I'm completely > mistaken and it isn't feasible at all. That would be a solution that would favor integration of Emacs and GCC and make it convenient. But Lisp/Scheme/Guile is easy to parse, and easy to interface with other tools. That's the reason for Emacs' popularity, and the reason Guile is pitched as GNU's extension language. Anything that is feasible for combining Emacs with GCC will be feasible for combining proprietary tools with GCC. I don't see a way to hack ourselves around that. Other GNU tools like Make and Bison have options to dump their complete parse tree and/or underlying data sets, and there are some applications making use of that (sometimes just for debugging purposes: try tracing down shift/reduce and reduce/reduce conflicts without an extensive dump). Of course, they are not as "mainstream" as context-sensitive programming editors. > A more useful question is "How can GCC most efficiently provide an AST > to Emacs?" Part of the answer is that Emacs already has the complete > text of every file involved. Emacs doesn't care what the name of a > variable is--that's already in the buffer. Emacs cares what part of > the buffer corresponds to a variable name. Dumping an AST that > contains only annotations to text, referring to positions in the > source files instead of actually including text in the AST, looks to > me like a good middle ground. Such an AST (which I will call a > "refAST" because it contains only references to program source text) > would be a significant pain to use as compiler input, since the symbol > names are missing, while also being exactly the information that an > editor needs. We can make it harder to use the refAST to abuse the > GCC frontend by the same expedient that makes the refAST easier for > Emacs to read. Emacs already has the source text, why force it to > read duplicates from the AST dump? That's basically the "make things as convenient for Emacs" road. But anything Emacs can do, comparatively simply external programs can do. We can (and should) favor Emacs, but we won't be locking out non-free uses of the same data set in that manner. Technically, what's good for Emacs is good for other tools. And I don't see a licensing hack working within copyright law that would give us the power to discriminate since copyright does not extend to program interaction and we are working with licensing rather than contracts, namely giving additional permissions over what copyright allows. -- David Kastrup