Re: Emacs contributions, C and Lisp

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>> It is more or less the same loss.  The case I'm concerned about is that
>> it become normal to use GCC with proprietary add-ons.
>
> My understanding is that people are satisfied with the current GCC
> plugin licensing.  What is at stake here is the development of a stable
> output that gives enough info for things like refactoring.
>
> IOW the issue is not disallowing proprietary add-ons (we're all pretty
> happy to disallow them, IIUC), but making it impossible to use GCC
> within a proprietary product (e.g. a proprietary IDE).

I don't think that there is much that we can do here.  It's always going
to be able to use GCC from within proprietary IDEs.  And any feature
that we are going to implement for making GCC do work for Emacs as an
IDE will definitely be open to proprietary IDEs equally.

What we do have is the problem of timing.  Richard is asking the GCC
developers, as far as I understand, what is doable now in order to get
support for smart completion into Emacs.  This will always be an option
for integration on-demand, and it means that there are no large time
windows where some feature is actually _only_ getting used by
proprietary applications/IDEs, giving them a competitive advantage over
our own environments.

On the other hand, "on-demand" introduces large time delays and
dependencies and makes spontaneous hacking lots harder if possible at
all.

>> Nowadays GCC does allow plug-ins -- we came up with a safe way to do
>> it (or at least I hope it's safe).  The issue now is to convince
>> people to work on improvements to GCC.
>
> Maybe that's the issue for GCC, but for Emacs the issue is to get
> detailed info out of GCC, which is a different problem.  My
> understanding is that you're opposed to GCC providing this useful info
> because that info would need to be complete enough to be usable as
> input to a proprietary compiler backend.

My long-term approach to integrating Emacs and GCC components more
tightly while still retaining a competitive technological argument over
the coupling into proprietary components is to tie things together not
at the basic I/O layer and not via dynamical linking or mapped memory,
but rather by having shared data structures and a common execution
model.

For Emacs/GCC, the way to do that would likely by making both run
through GUILE.  In the not so long-term perspective, data exchange would
be performed using simple LISP/Scheme data structures or dumps.  That
would at least favor integration and processing with Emacs LISP and make
it fast to exchange data.

Going in that direction would also facilitate using the existing parsing
frameworks for just-in-time compilation experiments.

Again, anything that is layered through independent modules will be
susceptible to reuse in proprietary components.  Having a GUILE runtime
as the executor will, however, at least make it harder to exploit the
modularity without either adopting Emacs-friendly data exchange methods
or getting into muddy water regarding the independence of modules
according to the expected court interpretations.

At any rate, the most feasible compromise between advantages for hacking
within our own copylefted software universe and not enabling approaches
bypassing our preferred technologies and/or principles would be to me to
move to a common reasonably integrateable platform at least on the
driver/control layer of compilation.  One probably still would want some
sort of separation for C-programmed components to avoid GCC bugs
crashing Emacs (which would be nightmarish to debug).  But it might be
possible to design systems ping-ponging Scheme data structures across
process boundaries.

That kind of setup would have the advantage that the political decisions
for accommodating integration of GCC/Emacs workings would not imply
having to deal with unexpected additional hurdles for tackling
integration tasks, but with unexpectedly fewer hurdles.

Putting GCC info out in LISP/Scheme reader compatible form would be a
first such step.  But that would also imply that typical batch
processing _not_ using Emacs would likely preferably be done using GUILE
(presumably preferredly) or some other LISP system (rep?).

It's clear that we are not going to find a satisfactory solution for
everything in a rush, even though that's what many approaches are being
advertised for.  But at least navigating the compromise between reuse
and modularity within GNU and reuse and modularity within proprietary
frameworks might be a bit nicer when we focus basing the reuse and
modularity on technology that is more on our home turf than "industry
standards".

Modularity will always be modularity, and consequently open to other
applications including non-free ones.  But we can at least try to make
the flavor of modularity one that might appeal more to people moving in
the GNU universe than outside.

-- 
David Kastrup