[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Sat, 17 Jan 2015 09:09:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Jacob Bachmeyer <address@hidden> 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

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]