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: Wed, 12 Mar 2014 15:54:40 +0100 Message-ID: <87a9cvjwlr.fsf@fencepost.gnu.org> References: <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> <87d2i9ee8t.fsf@engster.org> <874n3ke1qn.fsf@engster.org> <87sir336qn.fsf@fencepost.gnu.org> <20140301215057.GA19461@thyrsus.com> <87fvn1y0vx.fsf@fencepost.gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> <8761nusb90.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 1394636099 12910 80.91.229.3 (12 Mar 2014 14:54:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2014 14:54:59 +0000 (UTC) Cc: stephen@xemacs.org, Richard Stallman , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 12 15:55:08 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 1WNkYl-0007dg-OF for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2014 15:55:07 +0100 Original-Received: from localhost ([::1]:32900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNkYl-0004VN-Bc for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2014 10:55:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNkYh-0004QR-0H for emacs-devel@gnu.org; Wed, 12 Mar 2014 10:55:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNkYf-0002jT-LN for emacs-devel@gnu.org; Wed, 12 Mar 2014 10:55:02 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNkYf-0002iY-Ir for emacs-devel@gnu.org; Wed, 12 Mar 2014 10:55:01 -0400 Original-Received: from localhost ([127.0.0.1]:59240 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNkYX-0001lH-Ql; Wed, 12 Mar 2014 10:54:54 -0400 Original-Received: by lola (Postfix, from userid 1000) id 0917FE08A9; Wed, 12 Mar 2014 15:54:40 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Wed, 12 Mar 2014 09:36:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.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:170297 Archived-At: Stefan Monnier writes: >> It is more or less the same loss. The case I'm concerned about is that >> it become normal to use GCC with proprietary add-ons. > > My understanding is that people are satisfied with the current GCC > plugin licensing. What is at stake here is the development of a stable > output that gives enough info for things like refactoring. > > IOW the issue is not disallowing proprietary add-ons (we're all pretty > happy to disallow them, IIUC), but making it impossible to use GCC > within a proprietary product (e.g. a proprietary IDE). I don't think that there is much that we can do here. It's always going to be able to use GCC from within proprietary IDEs. And any feature that we are going to implement for making GCC do work for Emacs as an IDE will definitely be open to proprietary IDEs equally. What we do have is the problem of timing. Richard is asking the GCC developers, as far as I understand, what is doable now in order to get support for smart completion into Emacs. This will always be an option for integration on-demand, and it means that there are no large time windows where some feature is actually _only_ getting used by proprietary applications/IDEs, giving them a competitive advantage over our own environments. On the other hand, "on-demand" introduces large time delays and dependencies and makes spontaneous hacking lots harder if possible at all. >> Nowadays GCC does allow plug-ins -- we came up with a safe way to do >> it (or at least I hope it's safe). The issue now is to convince >> people to work on improvements to GCC. > > Maybe that's the issue for GCC, but for Emacs the issue is to get > detailed info out of GCC, which is a different problem. My > understanding is that you're opposed to GCC providing this useful info > because that info would need to be complete enough to be usable as > input to a proprietary compiler backend. My long-term approach to integrating Emacs and GCC components more tightly while still retaining a competitive technological argument over the coupling into proprietary components is to tie things together not at the basic I/O layer and not via dynamical linking or mapped memory, but rather by having shared data structures and a common execution model. For Emacs/GCC, the way to do that would likely by making both run through GUILE. In the not so long-term perspective, data exchange would be performed using simple LISP/Scheme data structures or dumps. That would at least favor integration and processing with Emacs LISP and make it fast to exchange data. Going in that direction would also facilitate using the existing parsing frameworks for just-in-time compilation experiments. Again, anything that is layered through independent modules will be susceptible to reuse in proprietary components. Having a GUILE runtime as the executor will, however, at least make it harder to exploit the modularity without either adopting Emacs-friendly data exchange methods or getting into muddy water regarding the independence of modules according to the expected court interpretations. At any rate, the most feasible compromise between advantages for hacking within our own copylefted software universe and not enabling approaches bypassing our preferred technologies and/or principles would be to me to move to a common reasonably integrateable platform at least on the driver/control layer of compilation. One probably still would want some sort of separation for C-programmed components to avoid GCC bugs crashing Emacs (which would be nightmarish to debug). But it might be possible to design systems ping-ponging Scheme data structures across process boundaries. That kind of setup would have the advantage that the political decisions for accommodating integration of GCC/Emacs workings would not imply having to deal with unexpected additional hurdles for tackling integration tasks, but with unexpectedly fewer hurdles. Putting GCC info out in LISP/Scheme reader compatible form would be a first such step. But that would also imply that typical batch processing _not_ using Emacs would likely preferably be done using GUILE (presumably preferredly) or some other LISP system (rep?). It's clear that we are not going to find a satisfactory solution for everything in a rush, even though that's what many approaches are being advertised for. But at least navigating the compromise between reuse and modularity within GNU and reuse and modularity within proprietary frameworks might be a bit nicer when we focus basing the reuse and modularity on technology that is more on our home turf than "industry standards". Modularity will always be modularity, and consequently open to other applications including non-free ones. But we can at least try to make the flavor of modularity one that might appeal more to people moving in the GNU universe than outside. -- David Kastrup