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:
>>
>>   
>>> Perhaps there is a better option?  I seem to remember efforts to adapt
>>> Guile to run Emacs Lisp and then to port Emacs to run using Guile
>>> instead of its own runtime.  I'm not certain of the difficulty, but
>>> perhaps GCC could be, over time, moved towards an option to build as
>>> Guile extensions?  I haven't looked far enough into this to know if it
>>> is feasible, or how much work would be needed, or if I'm completely
>>> mistaken and it isn't feasible at all.
>>>     
>>
>> That would be a solution that would favor integration of Emacs and GCC
>> and make it convenient.  But Lisp/Scheme/Guile is easy to parse, and
>> easy to interface with other tools.  That's the reason for Emacs'
>> popularity, and the reason Guile is pitched as GNU's extension language.
>>
>> Anything that is feasible for combining Emacs with GCC will be feasible
>> for combining proprietary tools with GCC.
>>
>>   
> Not quite in this case.  The GPL would still apply to GCC built as
> Guile extensions and therefore would still apply to any code that
> calls into GCC through Guile, just like Guile's current readline
> module.  Guile puts everything into the same process and isn't "arm's
> length" at all.

> Emacs is GPL, so it can call into GCC through Guile with no problem.
> A proprietary tool doing the same gets dropped right into a copyright
> quagmire.

Not if it does just the same as Emacs since that means it uses a
generically useful interface.

> Which leads to another idea that I think may have been mentioned: Does
> Emacs have the ability to load C plugins from shared objects?

No, and the reason is again not technical but political: it would make
Emacs generally useful as a component in compound applications not
reached by the GPL.

At one point of time, we'll probably need to rebalance the needs for
being able to rearchitecture and retool against the reach we would like
the GPL to have.

If we limit all our architecting choices to extensions in reach of the
GPL of the original core, we won't be able to interconnect big
independent GPLed applications, like Emacs and GCC are, because that
would also provide the technical means to interconnect with a big
non-GPLed application while keeping it independent.

So the "plugins/AST for GCC" question and "callable modules for Emacs"
question is pretty much tied down for the same reason: any reasonably
powerful connection mechanism between Emacs and GCC will make it
possible to connect Emacs with proprietary tools, and GCC with
proprietary tools.

I think it would be too expensive for us to _not_ pay this price.
Throwing a spanner into modularity and versatility whenever things get
interesting is going to be too expensive.  I would state "we should be
happy copyright can't reach everywhere", but with regard to software
licensing that is not all that convincing since most "licensing" mostly
relies on contractual conditions far exceeding copyright and
consequently has not much control to lose from increased possibilities
of interaction due to a changing technical landscape.

-- 
David Kastrup