From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Sun, 11 Jan 2015 11:00:38 +0100 Message-ID: <87fvbhskl5.fsf@engster.org> References: <54B1B97E.9070204@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420970471 15262 80.91.229.3 (11 Jan 2015 10:01:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 10:01:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jacob Bachmeyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 11:01:06 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 1YAFKT-00043i-Gh for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 11:01:05 +0100 Original-Received: from localhost ([::1]:57793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFKS-0004gJ-Rg for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 05:01:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFKF-0004gC-6Q for emacs-devel@gnu.org; Sun, 11 Jan 2015 05:00:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAFKB-0001DT-Uf for emacs-devel@gnu.org; Sun, 11 Jan 2015 05:00:51 -0500 Original-Received: from randomsample.de ([5.45.97.173]:41605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAFKB-0001Cf-MY for emacs-devel@gnu.org; Sun, 11 Jan 2015 05:00:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=nl2Sgq5iiljK/v3CJy+udoYPEGcODDDdOleRWZkEB+A=; b=u3ZtYMrBSRTUc79gIBGEiymNQfr31eqiDgiB2/UkBX/Qcqeoc31aFKCNO3T3iy3xHkeffjBbad6CfEql5Au8Ft8tnlGdoTpsg4TTCeZlunXnHqvjZyUD5FTe4DkW98pK; Original-Received: from ip4d154cb9.dynamic.kabel-deutschland.de ([77.21.76.185] helo=spaten) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YAFK4-0006pl-Mq; Sun, 11 Jan 2015 11:00:40 +0100 In-Reply-To: <54B1B97E.9070204@gmail.com> (Jacob Bachmeyer's message of "Sat, 10 Jan 2015 17:45:02 -0600") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:181142 Archived-At: Jacob Bachmeyer writes: > Obviously, it should still be possible to build "stand-alone GCC", but > having the compiler be available from Guile could easily solve the > issue at hand here, especially if the extension presents a Lisp-like > API for the GCC internal structures. This would also address the > concerns about the GCC front-end being abused to feed nonfree > backends, since the tree would only be present in memory behind a GPL > interface. > > But this is years away at best As always, people are needed to actually code that. > and doesn't solve the immediate problem, which is that Emacs needs a > parse tree "now". There are three options for how to get that: > > (1) Write a C parser in Emacs Lisp. Already done. Works reasonably well for C, is lacking for C++. Improving it would still be my first option, but no one is interested in helping. > 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, There's no significant pain in looking up the names from the source files. Also, I see absolutely no point in somehow obfuscating the AST, since for feeding things like LLVM, there are much simpler options, like you have noticed yourself (see below). > Further, the refAST needs to resemble the source text as closely as > possible. Most of GCC's value is from the optimizer and code > generators. Parsing is relatively simple compared to the rest of GCC. I don't think the guys maintaining the C++ frontend would agree... > If the refAST is dumped after optimization, it will be next to useless > for editing the source. So the refAST must be dumped prior to any > optimization. My knowledge of GCC internals is lacking, but a glance > at gccint suggests that Emacs needs a dump of GENERIC, which, > incidentally, can "also be used in the creation of source browsers, > intelligent editors, ..." Yes. > Further reading reveals that for better or for worse, this ship has > already sailed and GCC has had an option to dump GIMPLE > representation, which is probably far more useful for abusing the > frontend than an AST dump, for some time now. That's what I said from the beginning, and it's my main point why all this discussion about somehow obfuscating the AST dump is so completely absurd. My guess is that DragonEgg does exactly what you describe. Richard chose to not respond to this fact. -David