From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jacob Bachmeyer Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Mon, 12 Jan 2015 17:20:40 -0600 Message-ID: <54B456C8.6010506@gmail.com> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> Reply-To: jcb62281@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421104867 30879 80.91.229.3 (12 Jan 2015 23:21:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2015 23:21:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 13 00:21:01 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 1YAoI7-0002Ej-47 for ged-emacs-devel@m.gmane.org; Tue, 13 Jan 2015 00:20:59 +0100 Original-Received: from localhost ([::1]:36675 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoI6-0006Ws-Af for ged-emacs-devel@m.gmane.org; Mon, 12 Jan 2015 18:20:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoI1-0006Wi-JZ for emacs-devel@gnu.org; Mon, 12 Jan 2015 18:20:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAoI0-0005YX-7F for emacs-devel@gnu.org; Mon, 12 Jan 2015 18:20:53 -0500 Original-Received: from mail-ob0-x236.google.com ([2607:f8b0:4003:c01::236]:39580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoHw-0005Xg-Db; Mon, 12 Jan 2015 18:20:48 -0500 Original-Received: by mail-ob0-f182.google.com with SMTP id wo20so24881552obc.13; Mon, 12 Jan 2015 15:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zTgbv8R6sCcbZiK4rp09+yDOImRfy8W5Z7OzB21tYRg=; b=oOK57Ni/PSREWbpK2QFpPNTE2LLIzbo6laq69TOXu/pWCuUUYNRpcV2sXou15LREIj 571ePBrLdDsJXmzjVztWozCrPAhUDgLXdiy46s59+ZXnmuNR7R/Xx+bRb7NdZYek9sPy QvuEeaiNezHefyREiR/VOJYUp5c/YpeARcj50XxkFz5x7TM4kGVxdAVApxcwmlXT6vkt XSCxS7nq/XHxt7kqT21EShBWR2cJbKVNylHa6yAuO0yFpRaIULBmXwFk3/ZtbnUc4tkw LLXsK/cgrlaYV9KYL5AJrUCI2N6icKKBtoaSH/FN1uzCDb0ALPc8GJ4psg58T4xr8QXl zwvQ== X-Received: by 10.202.62.6 with SMTP id l6mr17894375oia.59.1421104847576; Mon, 12 Jan 2015 15:20:47 -0800 (PST) Original-Received: from [192.168.2.42] (adsl-70-133-148-241.dsl.ablntx.sbcglobal.net. [70.133.148.241]) by mx.google.com with ESMTPSA id o5sm9716795obz.9.2015.01.12.15.20.46 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 15:20:46 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 In-Reply-To: <87fvbhk4ha.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::236 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:181197 Archived-At: David Kastrup wrote: > Jacob Bachmeyer writes: > > >> 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. > > Not quite in this case. The GPL would still apply to GCC built as Guile extensions and therefore would still apply to any code that calls into GCC through Guile, just like Guile's current readline module. Guile puts everything into the same process and isn't "arm's length" at all. Emacs is GPL, so it can call into GCC through Guile with no problem. A proprietary tool doing the same gets dropped right into a copyright quagmire. >> 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. > > Correct, an external program could easily enough convert a refAST back into a full AST. The goal is to make things as convenient for Emacs (and other editors, particularly Free ones) as possible, while also making a proprietary developer's job harder, particularly reading it into another compiler. While convenience for Emacs is more important than pain for others, having only locations in the AST dump provides both, except for other editors. > 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. > > The limits of the GPL's reach, as best as I can see, is "arm's length", whatever that precisely is. In any case, the position I've always seen taken is that linking, especially when using a novel API, is within the scope of "derived work" and thus can be subject to requirements in the GPL. Which leads to another idea that I think may have been mentioned: Does Emacs have the ability to load C plugins from shared objects? That would open two new options: (1) a very efficient binary dump format that is a huge pain to read, unless you are using the provided (GPL, of course) library that would be very efficient, but would have knowledge of GCC internals, and (2) a GCC plugin that holds compilation after parsing and exposes the AST through some tightly-coupled IPC mechanism to a corresponding Emacs-side plugin. Both of these options require a more-or-less stable API presented to Emacs, but work best with a platform-specific ball-of-mud link between Emacs and GCC, both ends of which should probably come from GCC. Passing GCC internal structures and references thereto over the link should be encouraged, as long as the editor side in the end gets a full AST (or at least an interface to one) without too much difficulty. Because the Emacs plugin would need a stable API, it could also be used by other Free editors, but because it would be GPL, proprietary software would not be permitted to use it. This is basically a simpler, "make something quickly" version of the longer term Guile/Emacs/GCC combination, which should remain a goal, both to get rid of this ridiculous hack I propose here, and to make GCC more available to other programs under the GNU system as well.