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 00:11:00 +0100 Message-ID: <87sifijkor.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> <878uherlf3.fsf@wanadoo.es> <20150108194342.1bd83ed1@jabberwock.cb.piermont.com> <20150109131335.1a39f892@jabberwock.cb.piermont.com> <20150110170754.5190cc81@jabberwock.cb.piermont.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420932016 15756 80.91.229.3 (10 Jan 2015 23:20:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Jan 2015 23:20:16 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 00:20:11 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 1YA5KE-0004NZ-GL for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 00:20:10 +0100 Original-Received: from localhost ([::1]:56422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA5KD-0006Ph-AS for ged-emacs-devel@m.gmane.org; Sat, 10 Jan 2015 18:20:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA5K0-0006Pb-7M for emacs-devel@gnu.org; Sat, 10 Jan 2015 18:19:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YA5Jy-0005GR-Ve for emacs-devel@gnu.org; Sat, 10 Jan 2015 18:19:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA5Jy-0005GN-Sa for emacs-devel@gnu.org; Sat, 10 Jan 2015 18:19:54 -0500 Original-Received: from localhost ([127.0.0.1]:42070 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YA5Jr-0003Vh-M0; Sat, 10 Jan 2015 18:19:48 -0500 Original-Received: by lola (Postfix, from userid 1000) id 6B659E080F; Sun, 11 Jan 2015 00:11:00 +0100 (CET) In-Reply-To: <20150110170754.5190cc81@jabberwock.cb.piermont.com> (Perry E. Metzger's message of "Sat, 10 Jan 2015 17:07:54 -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:181134 Archived-At: "Perry E. Metzger" writes: > Here, for example, is a list of the sorts of refactorings that > IntelliJ, a proprietary editor, makes available for Java > programming. You can read them and decide for yourself how many of > these could be done without access to an AST -- I suspect the answer > is "only a few, and with difficulty". I am pretty sure that the answer is "every single one of them". However, if you form the _superset_ of all the information required for implementing every single one of them, it will no longer be markedly different from the AST. Instead of dumping we could write a query interface for Emacs into GCC where Emacs can ask some GCC module questions. But programs other than Emacs would be able to use it. We could dump the AST in Lisp form. But one of the points of Lisp is that its data is simple to read by computer. Now let's step back and put all the details aside for a moment: whatever we are afraid of others implementing as a compellingly useful proprietary application built for some proprietary tool could be implemented as a compellingly useful free application built for Emacs or other free tools. For better or worse, Emacs _is_ a framework that can be used for tying separate independent components into a compelling and cohering whole. So it does not really make all that much sense allowing or prohibiting certain kinds of applications, but rather allowing them in lockstep with people doing the actual work on Emacs, just to avoid others making a headstart with our own tools. One problem with that approach is that it requires micromanagement. Why is that bad? Let's explain with a joke: The physics faculty goes to the university president asking for more funding for a particle accelerator. The president is oblivious "All that money! Can't you take the mathematics department as model? We just need to provide them with pencils, paper, and wastebaskets, and they are able to work for years. And the philosophy department does not even need wastebaskets." Now for programmers, and possibly more so programmers of free software, the wastebasket is indeed one of the most important resources. Micromanaging means that one needs to manage before even getting to the wastebasket stage. That's expensive. Also potentially embarrassing: my wastebasket is actually rather private; I don't actually enjoy parading my mistakes and misestimates in full detail in public. They are part of my own creative process. So since anything useful in a free program may be useful in a proprietary one as well, and since Emacs is an independent application and we cannot really make it reach into GCC in a manner where they become a single application with regard to licensing, the moment where we need to think about enabling some possible interaction is when people are seriously working on an actual implementation. That's when it actually makes sense to step aside and let the horses out of the stable. And we can't avoid getting the proprietary ones out at the same time than the free ones: the best we can do is keeping the doors locked until our own horses are at the start, so they at least don't get a headstart. But at least we can make the racetrack as friendly to our own horses as we can. Like dumping the information in a form that Emacs can directly read. As to the question "does it need to be the full annotated syntax tree"? For almost any single application, I am pretty sure the answer is "no". But it is one natural starting point for figuring out just _what_ information a particular application may want to need. Another starting point is the information of visible identifiers and data types at every source point location. Compressing that into a reasonably concise offline data structure is a challenge of its own. At the current point of time, I don't really see that we can hope to make people enjoying working with and on free software without handing them control of their own wastebasket and letting themselves figure out where they can go with all the information they can ask for. Yes, all that information is equally useful for proprietary applications. We cannot really stop that by micromanagement. There might be some licensing hack that could discriminate free/proprietary but I cannot really think of one, and if there was one I'd be surprised if it would not have to be much more invasive than the GPL. So I'd really be happy if the decision-making following this discussion would result in more than a solution for contextual completion. It really calls for a general strategy for the question of how to make Emacs, the ultimate application glue, actually get access to everything that free software programmers want to glue together. Even if it means that other people can replicate the process using non-free glue. -- David Kastrup