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, 17 Jan 2015 09:09:42 +0100 Message-ID: <878uh1de0p.fsf@fencepost.gnu.org> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> <54B456C8.6010506@gmail.com> <8761cbhvhb.fsf@fencepost.gnu.org> <54B5AA10.7080606@gmail.com> <54B6F8EF.7020401@gmail.com> <54B8326B.90804@gmail.com> <54B889CC.9030401@gmail.com> <54B9BA48.9000903@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421482197 5358 80.91.229.3 (17 Jan 2015 08:09:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2015 08:09:57 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Jacob Bachmeyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 17 09:09:56 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 1YCOSC-0007JR-8B for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 09:09:56 +0100 Original-Received: from localhost ([::1]:58521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCOSA-0004rK-UO for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 03:09:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCOS7-0004r1-Ho for emacs-devel@gnu.org; Sat, 17 Jan 2015 03:09:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCOS6-0002Ec-HD for emacs-devel@gnu.org; Sat, 17 Jan 2015 03:09:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCOS6-0002EY-Dv for emacs-devel@gnu.org; Sat, 17 Jan 2015 03:09:50 -0500 Original-Received: from localhost ([127.0.0.1]:44258 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCORz-0002Jg-2L; Sat, 17 Jan 2015 03:09:43 -0500 Original-Received: by lola (Postfix, from userid 1000) id AF5E7E0FEF; Sat, 17 Jan 2015 09:09:42 +0100 (CET) In-Reply-To: <54B9BA48.9000903@gmail.com> (Jacob Bachmeyer's message of "Fri, 16 Jan 2015 19:26:32 -0600") 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:181368 Archived-At: Jacob Bachmeyer writes: > This is why I am proposing a two-faced (one face for GCC, one for > Emacs) link plugin that gets the AST from GCC via some (currently > unspecified, but using ptrace(2) is not out of the question) > host-platform-specific binary means and presents it to Emacs as some > kind of in-memory data structure. Although, after it was pointed out, > I now see the possible problem that someone could write Emacs Lisp > code to dump that structure as text. > > But all this is sounding more and more like we could not stop someone > who really wanted the AST in any case. Using Emacs as an AST dumper would be an inconvenience. Not more, not less. Emacs can be used as a batch script engine, and in today's inflated resource needs, it would not even consume noticeably more memory than calling some Java program. At any rate, if Emacs is fast enough to work for working with the AST in Emacs, it will be fast enough to export it. > If a developer of non-free software could use any facility we develop > to import an AST from GCC into Emacs, what stops that same developer > from simply writing their own AST export plugin for GCC and making > just the AST dumper GPL? That too, if it is a general purpose export plugin. But at least they'd have to do it themselves. Which is a pretty small threshold. >> This is why there is danger in generating the AST as text. > > This is why I do not propose exporting a text AST. Transforming data is not much of a problem if it is designed to be not much of a problem for at least _some_ use case. And it would be pointless to make it a problem for ourselves. The most we can hope to do is tilt the table: export as Lisp data. Still easy to parse, but easier still for us. And make Emacs really useful for manipulating the data. The more GNU and GPLed components fit together like a jigsaw puzzle, the more annoying it becomes for programmers to refit a a non-free component into this universe. Even when they are legally allowed to do it. It's not a large hurdle, sure. But at least it is not a hurdle for ourselves. -- David Kastrup