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: Sat, 01 Mar 2014 12:04:04 +0100 Organization: Organization?!? Message-ID: <87lhwuyycb.fsf@fencepost.gnu.org> References: <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <8338j717oe.fsf@gnu.org> <87zjlf6tdx.fsf@fencepost.gnu.org> <83sir7yue7.fsf@gnu.org> <8761o3dlak.fsf@wanadoo.es> <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> <87d2i9ee8t.fsf@engster.org> <874n3ke1qn.fsf@engster.org> <87vbvzcjv9.fsf@engster.org> <87iorz18fy.fsf@fencepost.gnu.org> <83vbvyv08q.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393671866 4033 80.91.229.3 (1 Mar 2014 11:04:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2014 11:04:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 12:04:34 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 1WJhic-0000KL-8k for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 12:04:34 +0100 Original-Received: from localhost ([::1]:59206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJhib-0002Zy-T9 for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 06:04:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJhiT-0002Zn-EU for emacs-devel@gnu.org; Sat, 01 Mar 2014 06:04:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJhiN-0005Mo-5Z for emacs-devel@gnu.org; Sat, 01 Mar 2014 06:04:25 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:48918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJhiM-0005Md-R9 for emacs-devel@gnu.org; Sat, 01 Mar 2014 06:04:19 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WJhiK-0000Bd-QI for emacs-devel@gnu.org; Sat, 01 Mar 2014 12:04:16 +0100 Original-Received: from x2f41c58.dyn.telefonica.de ([2.244.28.88]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Mar 2014 12:04:16 +0100 Original-Received: from dak by x2f41c58.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Mar 2014 12:04:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 179 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f41c58.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:Jok/U4NI+Q1V5834DPy6gXjl2IA= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:169984 Archived-At: Eli Zaretskii writes: >> From: Juanma Barranquero >> Date: Fri, 28 Feb 2014 18:31:53 +0100 >> Cc: Emacs developers >> >> It would be interesting to measure (somehow ;-) whether that "Emacs >> leverage" is enough to preserve GCC's importance. I mean, if using >> the clang libraries allows much powerful, developer-friendly >> environments for C/C++ programmers, do we think that a significant >> number of them will still choose GCC because of Emacs? If the answer >> is "yes", Richard's position strenghtens GCC without prejudice for >> Emacs. If the answer is "not", that position hurts Emacs without >> helping GCC. > > I actually don't understand why are we talking about compilers as the > only viable infrastructure for the features being discussed. It's basically the UNIX philosophy to employ dedicated tools for the job they have been written for. Parsing is a nontrivial task, so using an existing parser makes sense. Particularly when we are talking about languages with complex namespace and type rules and overloading and ambiguous grammar and three aspects of compiler technology (preprocessing, normal execution, template instantiation) working largely independently with partly surprising consequences. Now we only want to have parsing and no code generation. That's a kind of task that GCC does not currently offer separately, and part of the reason for it is that others might find it useful for creating non-free applications around such functionality. It's my opinion that this is a cost we hardly can avoid paying without also creating serious road blocks for the creation of free tools. In the context of possibilities to refactor GCC to make parts of it separately useful and/or allow other ways of plugging things together, Richard tends to be conservative, and indeed it's a cat that would be pretty hard to stuff back in the bag if one eventually finds the consequences different than what one hoped for. In the current situation, the GPLv3 with its patent protection clauses provides enough of a disincentive in my book that one would have to be overly afraid of creating proprietary spinoffs in the compiler technology area. However, there _are_ hopeful signs that the current patent madness will eventually be fixed by legislational means, and in that case the patent clauses of the GPLv3 would be quite less of an influence on a big proprietary business' bottomline. But should patents lose much of their sting, it would also mean a hit in the general attractiveness of LLVM over GCC: the GPLv3 is more or less cited as the main reason several proprietary vendors stopped working with GCC. So _iff_ the poison pill of the GPLv3 would become inert, we have a situation where we'd want to be able to play to our strengths for making proprietary vendors (and others) pick the GCC and thus provide their users with some degree of freedom. And that will basically happen on technical merit. > We already have elaborate infrastructure for this kind of features: > CEDET and in particular Semantic. Moreover, we included CEDET in > Emacs several releases ago precisely _because_ we wanted to move in > the direction of making Emacs a better IDE. If we need more of what > is in ECB and the upstream CEDET, we can bring that in. This is IMO > the preferred direction: make Emacs features depend on nothing but > Emacs packages. Then all this prolonged discussion about GCC vs clang > is a moot point, and we also gain independence of other projects' > priorities and policies as a nice bonus. Well, if we get to stage where we can say "get a language supported by GCC, and Emacs will provide good highlighting, semantic completion, nice formatting", then that would be a very strong selling point for GCC as well as Emacs. In particular if the output enabling those kinds of feature can be used by other IDEs than Emacs. And that's exactly because it would avoid duplication of work. However, it would also require incremental parsing to be really good. Could an incremental and/or differential parser (reparse just part of a file and update all info about the whole compilation unit) be fit in the GCC framework? An interesting starting point would be, of course, trying to make Bison skeletons that work for that purpose. Unfortunately, the highest-profile languages by GCC don't use Bison IIRC. An any rate, it is a much more realistic goal to get 60% of all computer users to use GCC than it is to get 60% of all computer users to use Emacs. And compilers are really important. We should really think about how we can leverage GCC to make, say, manufacturers of proprietary hardware open up their hardware in order to use GCC rather than just go somewhere else. And that's a somewhat pressing problem. > If we need policy decisions in this matter, _that_ is the only one > that should be made. To me, it is almost a no-brainer; I wonder why > it is not clear-cut to others here. The main problem I see here is that our policy decisions regarding Emacs are, to a large degree, trickle-down decisions because of the role GCC can or should play for computing. In the concrete situation we have here, basically company-mode offering semantic assistance based on Clang/LLVM, the solution I'd have preferred to see is, "Oh, that's a shortcoming, but easily fixed. Let's just hack up something that works with current GCC, and then people have a choice." The current situation with GCC is such that "let's just hack up something that works with current GCC" seems to be out of reach. There are two ways to address that: one is hacking something up in GCC that works for that particular purpose. We have the statement here (and far too little attention has been paid to it) that -fdump-xref and associated programs of the GNAT project would do the trick for the editing task currently at issue. So there is a prototype people could be testing and experimenting with instead of doing flame wars. It means using a specific version of GCC, but it would be easy enough to turn that into a default version if we consider that a priority. And I think we should. Really, really, really. That could be a feasible approach to address the "batch data collection for semantic completion" angle. Now the Ada thing is a stroke of luck in its timing, and we should not waste it. But that still gives the question: "how about the longterm viability to use GCC and its parsers to hack up something fast that does not require changes to GCC"? Because this would avoid all the discussion and friction and give people the freedom to hack up their own solutions centered around GCC. Including solutions we don't want to see. I think that in this particular case, the cost of tight control beyond that offered by the GPLv3 (which will likely change along with the patent landscape) for the underlying code base) is likely to be a cause for repeated roadblocks of the kind we are seeing here with Emacs. This particular Emacs flame war has been less than pretty. But it is more or less a downstream flamewar. The current code and also partly policy situation with GCC are what are at issue here. While this particular situation might be curable with -fdump-xref eventually, the respective decision-making in the context of Emacs appears heavy-handed, and there are few other applications where a heavy hand could even reach. So I think that a long-term tenable solution of the problem will require work and/or policy changes on GCC that would have made this a non-issue or moderate-effort issue for Emacs. To get back to what I replied to: > This is IMO > the preferred direction: make Emacs features depend on nothing but > Emacs packages. [...] > If we need policy decisions in this matter, _that_ is the only one > that should be made. To me, it is almost a no-brainer; I wonder why > it is not clear-cut to others here. Well, that is not really much in need of a policy since Emacs can support multiple feature sets. I would prefer if we needed no policy decisions at all in this matter. We don't get that, obviously. But my next preference is to have GCC move/develop in a manner where we would not have needed a policy decision. Because Emacs is, all in all, not a particularly effective venue for making policy decisions matter in the great play. If we can get to a stage where our preferred action would also be in accord with running policies, that means that the preferred action in non-policed applications would be the same. In other words: things are going wrong with GCC policies upstream regarding reusability in Free Software applications that Emacs, as one compiler user, is too small too fix. If this is not approached in a more general manner in GCC, we'll have this problem reoccuring in various iterations on the Emacs list, and it will be reoccuring for the maintainers other Free Software which will then choose to pick non-copyleft compilers entirely instead of playing mix-and-match games or writing their own parsers. -- David Kastrup