Re: Emacs contributions, C and Lisp

[David Kastrup]

"Perry E. Metzger" <address@hidden> writes:

> Here, for example, is a list of the sorts of refactorings that
> IntelliJ, a proprietary editor, makes available for Java
> programming. You can read them and decide for yourself how many of
> these could be done without access to an AST -- I suspect the answer
> is "only a few, and with difficulty".

I am pretty sure that the answer is "every single one of them".
However, if you form the _superset_ of all the information required for
implementing every single one of them, it will no longer be markedly
different from the AST.

Instead of dumping we could write a query interface for Emacs into GCC
where Emacs can ask some GCC module questions.  But programs other than
Emacs would be able to use it.  We could dump the AST in Lisp form.  But
one of the points of Lisp is that its data is simple to read by
computer.

Now let's step back and put all the details aside for a moment: whatever
we are afraid of others implementing as a compellingly useful
proprietary application built for some proprietary tool could be
implemented as a compellingly useful free application built for Emacs or
other free tools.

For better or worse, Emacs _is_ a framework that can be used for tying
separate independent components into a compelling and cohering whole.

So it does not really make all that much sense allowing or prohibiting
certain kinds of applications, but rather allowing them in lockstep with
people doing the actual work on Emacs, just to avoid others making a
headstart with our own tools.

One problem with that approach is that it requires micromanagement.  Why
is that bad?  Let's explain with a joke:

   The physics faculty goes to the university president asking for more
   funding for a particle accelerator.  The president is oblivious "All
   that money!  Can't you take the mathematics department as model?  We
   just need to provide them with pencils, paper, and wastebaskets, and
   they are able to work for years.  And the philosophy department does
   not even need wastebaskets."

Now for programmers, and possibly more so programmers of free software,
the wastebasket is indeed one of the most important resources.
Micromanaging means that one needs to manage before even getting to the
wastebasket stage.  That's expensive.  Also potentially embarrassing: my
wastebasket is actually rather private; I don't actually enjoy parading
my mistakes and misestimates in full detail in public.  They are part of
my own creative process.

So since anything useful in a free program may be useful in a
proprietary one as well, and since Emacs is an independent application
and we cannot really make it reach into GCC in a manner where they
become a single application with regard to licensing, the moment where
we need to think about enabling some possible interaction is when people
are seriously working on an actual implementation.  That's when it
actually makes sense to step aside and let the horses out of the stable.
And we can't avoid getting the proprietary ones out at the same time
than the free ones: the best we can do is keeping the doors locked until
our own horses are at the start, so they at least don't get a headstart.

But at least we can make the racetrack as friendly to our own horses as
we can.  Like dumping the information in a form that Emacs can directly
read.

As to the question "does it need to be the full annotated syntax tree"?
For almost any single application, I am pretty sure the answer is "no".
But it is one natural starting point for figuring out just _what_
information a particular application may want to need.  Another starting
point is the information of visible identifiers and data types at every
source point location.  Compressing that into a reasonably concise
offline data structure is a challenge of its own.

At the current point of time, I don't really see that we can hope to
make people enjoying working with and on free software without handing
them control of their own wastebasket and letting themselves figure out
where they can go with all the information they can ask for.  Yes, all
that information is equally useful for proprietary applications.  We
cannot really stop that by micromanagement.  There might be some
licensing hack that could discriminate free/proprietary but I cannot
really think of one, and if there was one I'd be surprised if it would
not have to be much more invasive than the GPL.

So I'd really be happy if the decision-making following this discussion
would result in more than a solution for contextual completion.  It
really calls for a general strategy for the question of how to make
Emacs, the ultimate application glue, actually get access to everything
that free software programmers want to glue together.  Even if it means
that other people can replicate the process using non-free glue.

-- 
David Kastrup