Re: Emacs contributions, C and Lisp

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>> The point is to give people a strong motivation to implement the
>> necessary support with GCC.
>
> I don't see how avoiding clang support in Emacs provides motivation for
> GCC hackers to add this support, that's been lacking for several
> years now.
>
>
>         Stefan "who'd favor a GNU clang effort, extending clang with new
>                 exciting features distributed under the GPL"

Well, if I understood correctly, part of the reason such support in GCC
is not easily forthcoming is because of technical restrictions that are
a consequence of policy decisions.  So we are shooting ourselves in our
own foot here.

Inherently this boils down to the "viral nature" of the GPL, namely
coercing newly created extensions to fall under the GPL automatically
when distributed, requiring to cover a work "as a whole", and the point
of modularity as a software design goal is to separate works into
reasonably separate aggregates.

This coercive nature of the GPL has bargained us the Objective C
frontend to GCC.  With a high amount of modularity and nice compiler
building blocks, this frontend might have stayed proprietary.

As it stands, Objective C is nowadays very much constrained to fringe
status except on proprietary platforms like those of Apple.  And I doubt
GCC is used to any significant degree for compiling Objective C code.
Which is disappointing.

My personal preference would be to allow general purpose interfaces and
modularity where they provide obvious benefit for Free Software
development of uncoordinated parties.  Of course, where the only
imminent usage (and motivation for factoring out interfaces) would be by
a proprietary program, the mere "it _could_ be used for Free Software"
should not really drive forward a feature, nor should special cases be
added for proprietary software.

But the main problem we are dealing with is that modularity and
general-purpose interfaces weaken the power of the GPL, while at the
same time allowing for more reuse of software and for a better scaling
of developers since they can drive their own projects forward in a less
lockstepped manner.  And the speed and lags of software development
these days make lockstepped development really expensive.

I am not sure that the balance regarding modularity and integration we
are striking these days serves best our goals of promoting Software
Freedom and extending the amount of copylefted software available and
useful.  The easiest way for a large number of people to cooperate, and
there _is_ a large number of people writing copylefted software, is to
make sure this cooperation requires a minimal amount of interaction, and
that means modular and versatile tools.  After all, that's what UNIX,
after which GNU has been moduled, is all about.

But we are obviously not going to turn on a dime regarding policies long
in the making.

-- 
David Kastrup