Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> David Kastrup wrote:
>> Jacob Bachmeyer <jcb62281@gmail.com> writes
>>>
>>> What stops nonfree software from doing that is that the mechanism used
>>> to get access to internals of GCC is very low-level (using ptrace(2)
>>> to directly access GCC's memory would not be out of the question) and
>>> transfers GCC internal structures over the link, which are interpreted
>>> within the Emacs process.  According to the GPL FAQ:  "Using shared
>>> memory to communicate with complex data structures is pretty much
>>> equivalent to dynamic
>>> linking."(<URL:http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins>)
>>> I expect that GCC's internal trees qualify as "complex data
>>> structures".  There is certainly not a nice, readable, text AST dump
>>> involved at any point.
>
>> At any rate, does not sound like an interface one could keep steady
>> across different GCC versions.  To make that the case, you need
>> something describing the internals' meaning, akin to how debug
>> information describes memory layout.  Once you have that kind of "my raw
>> memory means $x" description, this constitutes an interface.  Possibly
>> an awkward interface, but that's not legally significant.
>
> That's the point--the interface between the underlying processes is
> not stable across GCC versions and the "description" of the internals'
> meaning comes in the form of a C DSO that Emacs can load to get Emacs
> Lisp bindings to GCC's own API for accessing these structures.  The
> "description" is a program component that must be combined with any
> program that uses it.

So what?  You do that with a minimal program you license under the GPL
and then dump the AST in a generically useful form.  Then you get a
sanely usable dump of generally useful information you and other
proprietary programs can use conveniently while any program from the GNU
project has to go through a binary mess by decree.

We are shooting ourselves much more in the foot that way than anybody
else.

> Reverse engineering one version of the interface would allow non-free
> software to use that version of GCC, yes, but doing that repeatedly as
> GCC changes, without it ever becoming a derived work, would quickly
> become more expensive than simply writing a new parser.  Especially
> since the two halves of the link plugin are only required to talk to
> each other, and are built together, so they can change easily.  The
> link protocol could even be made polymorphic in some way, so that
> every pair of binaries built would have a subtly different link
> protocol.

So any version of Emacs will work only with a particular version of GCC?
Remind me: whose life were we trying to make harder?

>> And our limited and distributed resources and skills as free software
>> developers mean that our success depends on interoperation within
>> free software.  We can't afford this process every time we want
>> something to work together.
>>   
>
> We are at a point where continued inaction will eventually make GNU
> irrelevant, the right action will put GNU far ahead of all the others
> for the foreseeable future,

Reality check: with regard to interoperation we will not be "far ahead
of all the others" period.  And that has never been much of a focus for
the GNU project anyway.  If we ever wanted to get "far ahead" in that
category, talking about interfaces that are not robust or generic enough
to be considered an interface (because once there is a proper interface,
it can be used by non-free applications) is like discussing what plate
armor is best for ballet dancing.

> and the wrong action will... well, extending the metaphor about the
> defensive wall around our city that RMS has used, the wrong action
> could destroy our defensive wall entirely.

At the current point, we have a defensive wall around our armory and
can't get in.

> It is very important that we find and carry out the right action.

I think we missed the point of time where that would have been very
important.  We dropped the ball quite thoroughly already.  But since
this is a principal problem, it will come up again.  And again.  And the
real danger is that we continue to fumble and drop every time.

It is my personal conviction that in the area of interfacing, the kind
of micromanaging that would be required to manage GCC/Emacs plugins let
alone an integration will not work.  If we need to have this kind of
discussion everytime some GNU components want to operate closer, this
cannot work.  GNU is designed and intended to work as one, and if we
need to micromanage every step where it does that, we will not be
getting anywhere.

This issue and the associated decisions will not disappear overnight.
There is no urgency for action: both damage and benefits of a particular
decision will be accumulative for a long time.

But what we need is a long-term strategy here.  We can't muddle through
like that forever, pissing everyone off in the process.

Richard needs to come to a basic yes/no decision regarding whether he
wants to see independent GNU applications to be combined in new manners
without micromanaging each instance (and I am very unconvinced that this
is even possible, for legal, technical, and social reasons) or not.  A
"yes" will very likely imply that this kind of combination cannot be
barred from being done with non-free independent components.  A "no"
will mean that the GNU universe as a whole will permanently be
disadvantaged regarding regarding interoperation compared to a more
permissively managed infrastructure.

Having certainty about that will make it possible for people to choose
which projects under which guidance to participate in without wasting
their time and emotions on things they are powerless to change.

We need a strategic decision, and that's Richard's responsibility.  For
the issue at hand, smart completion and possibly refactoring tools based
on a combination of Emacs and Gcc, it may come too late to make much of
a difference any more, at least regarding those people who wanted to
volunteer this time.  That's possibly a waste and a shame but it may be
that the pieces of clockwork are now too broken to pick them up.

But there is no point in having that kind of waste occur again and again
and again.  The strategy "wait until the issue occurs next time and then
repeat what we did last time until it goes away" is undignified.

-- 
David Kastrup