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: Tue, 04 Mar 2014 09:28:08 +0100 Message-ID: <8738iyjrl3.fsf@fencepost.gnu.org> References: <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <83sirj9cyp.fsf@gnu.org> <20140217203145.71a849f7@forcix.jorgenschaefer.de> <837g8t8ouc.fsf@gnu.org> <20140219080524.25689b6b@forcix.jorgenschaefer.de> <83k3cr58o2.fsf@gnu.org> <530BAEE5.9040004@online.de> <87ppmatkpe.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgfsxsr.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgf37n4.fsf@fencepost.gnu.org> <87ha7gshu9.fsf@uwakimon.sk.tsukuba.ac.jp> <871tyko9l5.fsf@fencepost.gnu.org> <87eh2ks897.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvn0mk25.fsf@fencepost.gnu.org> <87bnxorlol.fsf@uwakimon.sk.tsukuba.ac.jp> <877g8bmxal.fsf@fencepost.gnu.org> <877g8asfl0.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 1393921720 25538 80.91.229.3 (4 Mar 2014 08:28:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2014 08:28:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 04 09:28:50 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 1WKkiU-0003X0-OE for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 09:28:46 +0100 Original-Received: from localhost ([::1]:43692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKkiU-0003bb-Bf for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 03:28:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKkiO-0003YI-GU for emacs-devel@gnu.org; Tue, 04 Mar 2014 03:28:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKkiL-0005Cl-Bb for emacs-devel@gnu.org; Tue, 04 Mar 2014 03:28:40 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKkiL-0005Ch-93 for emacs-devel@gnu.org; Tue, 04 Mar 2014 03:28:37 -0500 Original-Received: from localhost ([127.0.0.1]:41686 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKkiK-0005Sd-Pm; Tue, 04 Mar 2014 03:28:37 -0500 Original-Received: by lola (Postfix, from userid 1000) id 410DBDF3DC; Tue, 4 Mar 2014 09:28:08 +0100 (CET) In-Reply-To: <877g8asfl0.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 04 Mar 2014 14:22:35 +0900") 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:170126 Archived-At: "Stephen J. Turnbull" writes: > David Kastrup writes: > > "Stephen J. Turnbull" writes: > >> David Kastrup writes: > >>> "Stephen J. Turnbull" writes: > >>>> David Kastrup writes: > > >>>>> It only weakens the GPL > > [big snip and back to David] > > > The GPL can _always_ be enforced by the copyright holder. > > Collecting the assignments makes sure that the FSF has the full > > ability to enforce > > You could have stopped there. *You* said "weaken the GPL" when what > you really meant was "weaken the FSF." OK, conceded. It weakens the GPL when the FSF applies it to software where it cannot hope to successfully defend the GPL in court. > And then your main point: > > > It doesn't weaken the GPL. It weakens GCC, and with it, the GNU > > project. Part of the strength of the GNU project lies with GCC > > setting language and performance standards, > > Except that last is now an exaggeration. Obviously GCC no longer sets > performance standards, If you want to believe the summaries of Phoronix' Michael Larabel rather than his numbers... > and since the reason I switched my default to Clang was to get better > error messages, in at least one aspect it seems to be lagging on > language standard-setting. (But see discussion below, especially > fn. 1.) You are confusing "being helpful with figuring out compliance with C++ standards" with "introducing its own features that are so good that they are eventually accepted into standards". GCC has had variable length arrays (also multidimensional) decades before they made it into C99, and C++ still hasn't caught up. > > and it's bad if the most thorough modes we make available with > > Emacs are not able to support the GCC dialects. > > Now that, as Richard would say, is a misrepresentation. Of course > nothing prevents Emacs from supporting GCC dialects, certainly not a > fiat from Mt. Olympus. Of course Emacs *should* support them. Of course Emacs could not possibly hope to support them if its language parsing relied on Clang. Which is what this thread is about. > And if such support was lacking or weak, I think there's some chance > that Richard would come around and encourage development of that mode. > Don't you? How can Richard encourage Clang developers to develop better parsing of GCC-only features? I think you overestimate his influence. > AFAICS, the issue at hand is supporting unique features of free > software whose licenses do not defend freedom according to Richard. The issue at hand is relying on Clang as infrastructure for cross-referencing/completing features in C/C++ modes. The issue is _not_ to "support unique features" but rather to have Emacs operations _depend_ on unique features of Clang. It's not the first time I've corrected this statement. > There are a lot of such licenses, including those used by TeX, Perl, > Python, Ruby, ncurses, X11, and Apache. Why doesn't the logic that > applies to LLVM apply to them too? Because Emacs does not rely on those to the detriment of GNU-internal solutions of the GCC calibre and importance. > > So in this case GCC and the GNU project were in the situation of > > creating a de facto standard. Once Emacs supports what Clang > > provides rather than what GCC provides, not even Emacs will support > > any new features of GCC. > > Hm. You've said that twice, now. This is a leap that I cannot > follow. Would you explain? If Emacs only understands C/C++ by using Clang for its parsing, the dialects it will support will be those of Clang. This can't be that hard to understand. > I understand the rest of your argument that *compiler users* could > abandon GCC en masse. What I don't see is why that would prevent > Emacs from supporting unique GCC features any more than it prevents > Emacs from supporting a zillion true niche applications (eg, modes for > .Xresource and RGB.txt manipulation). Emacs does not get to choose which language features it supports when it uses Clang for understanding source files. > Furthermore, my personal estimate is that GCC's capacity for relevant > innovation has been sapped by its dominant position and by the focus > on internal issues that comes with high-stakes standard-setting. And > furthermore, refactoring to make internal data structures available to > cooperating applications has been forbidden for a decade or so. Just > where are those "unsupportable" new features going to come from? There has been no ban on "features". Instead, the ban has been on generic infrastructure making it easy to hack up features without requiring changes to GCC. Each individual feature can be supported by custom code in GCC. The cost of sacrificing modularity and generic interfaces is that development and deployment of those features is then coupled to upstream GCC development and its release cycles. If the purpose of a discussion is to readjust the basis for decision-making, constant misrepresentation of the salient points is leading nowhere. The way to tip a scale is not blowing it up. > No, at least based on current behavior, you don't want *GCC* to *do* > anything. You want *LLVM* to *fail to innovate* in the same way that > GCC is *prohibited* from innovating. The effect is the same, but your > statement suggests that GCC is being defended, when in actual fact > what is happening here is that Emacs is being commanded to attack LLVM > (in the sense of "trade war", ie, withdraw cooperation from an > external entity whose competence threatens a protected local > industry). That's total rubbish and you know it. Emacs is not "being commanded to attack LLVM". It is in no position to do anything of that sort. And it is most certainly not an "attack" if Emacs developers are told that Emacs' C/C++ modes should not be equipped with features that can only work by using Clang internally, consequently restricting the supported languages and more important language dialects to those of Clang as well as introducing a permanent dependency on a compiler not under our control. > This is only to the detriment of Emacs and LLVM users. It is to the detriment of Emacs users who don't care about GCC and ultimately the fate of the GNU project. Yes. The GNU project was never about making everybody happy. It was about making sure its users have free software available where they have access to the full sources, and making sure that this is not just a temporary state. Whether or not its users are interested in it. It turns out that most aren't. Which is hardly a surprise if you take a look at the takeup of operating systems like Windows and MacOSX. That GNU and GNU/Linux nowadays don't look ridiculous in popularity contests does not mean that this is the metric we now should be pursuing. It is a dead end now as much as before. > That justifies redoubling efforts to innovate in GCC, while respecting > the self-imposed limitation on acceptable areas for innovation. It > doesn't justify "trade war". It is no war if we decide what we are going to use ourselves as a critical part of our infrastructure. There is just no point in pulling down our defenses in order to drag a pretty wooden horse in. > > When put to the choice, we'd rather give up on Android than GNU. > > And us having to take that choice at some point of time is what > > Clang/LLVM are working towards. > > I rather think you overstate the importance of GNU in the thinking of > LLVM developers. I think you utterly fail to comprehend that it does not matter at all what LLVM developers think. We have to take into account the effect of their actions, not their motivations. > > > Once Clang/LLVM become the compiler for Android, it is a matter of > > time and hipness before it becomes the default compiler for the > > Linux kernel. > > > > Once the kernel is bootstrapped using Clang/LLVM, it is a matter of > > time before the userland of big distributions is compiled using > > Clang/LLVM as well, with GCC becoming optional. > > > > At some point of time, it will become harder to compile the Linux > > kernel with GCC out of the box, and bootstrapping a full GNU system > > will mean that we need to revert to the HURD, mostly relying on > > using Linux drivers. > > A sad future history indeed. And you think that refusal to integrate > Emacs modes that use Clang to improve the Emacs user experience To improve the Emacs user experience for those users that are willing to forego GCC as compiler > is the finger in the dike that will save Holland, er, the GNU Project? The GNU project started by sticking up a finger in a sea of propretary software. That's where it started, and it will end when nobody is willing to stick up for it. Complacency and resignation are not the way to anything. > The obvious fact is that GNU can't stop the process you've described > -- it all happens outside of GNU! Which means that if we cannot stop the processes outside of GNU, we can at least keep things as they should be inside of GNU. That is nothing that can be taken away from us unless we give it up voluntarily. > Specifically, it wants to be universal but denies the clearly > expressed aspirations and preferences of the rest of the > free-software-producing world and their users. The GNU project never aspired "to be universal". It has always been an enclave because of a world that has gone mad in its laws and business processes. The FSF has a mission to make the world less mad, and it would be great if at some point of time the GNU project would become unnecessary because software was free anyway. But making the world less mad and maintaining GNU are two separate endeavors, and they will not become the same in our life time. > And now, it's denying the aspirations of some of its own members, > merely to spite those with different beliefs about defending freedom. Shrug. What do you hope to achieve with inflammatory spins like that? Trying to work with those resources one has under one's own control and reducing external dependencies where feasible is Economics 101. If I tend to my own orchard instead of buying apples at the market, is that merely to spite those merchants at the market with different beliefs about planting trees? -- David Kastrup