Re: Emacs contributions, C and Lisp

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Sat, 01 Mar 2014 12:04:04 +0100
> 
> > I actually don't understand why are we talking about compilers as the
> > only viable infrastructure for the features being discussed.
> 
> It's basically the UNIX philosophy to employ dedicated tools for the job
> they have been written for.

I'm not at all sure this philosophy is applicable to the issue at
hand, or to complex interactive environments the kind of Emacs in
general.  We are a long way from the classic batch-mode Unix pipeline,
where (AFAIK) this philosophy originated.

This is a topic worthy of a separate non-trivial discussion, but just
to hint on the potential problems, you may wish to reflect on Emacs
features that do try to use this approach: Dired, GUD, and spellers.
My take from that is that the success is limited at best, and even
then only when those "dedicated tools" go out of their way to support
Emacs, i.e. became "dedicated" to Emacs.  That's already a far cry
from the Unix philosophy mentioned above, which assumes tools
dedicated to their respective tasks, not to their consumers, certainly
not to one particular consumer.

But even if one accepts the philosophy, all we are talking about is
whether to prefer one parser to another.  That one of them is written
in Emacs Lisp is an implementation detail; it is still a "dedicated
tool", just like GCC.  (GCC can, and usually does, do much more than
just parsing and semantic analysis, but that is not important for the
issue at hand.)

OTOH, using an ELisp-based package brings a tremendous advantage,
starting with the fact that such a parser has no problems accessing
Emacs buffers, something external programs can only dream about.  This
alone tells me that CEDET based solutions could be integrated with
interactive editing much more easily than any other solution, and in
particular, several problems simply don't exist with CEDET.

> Well, if we get to stage where we can say "get a language supported by
> GCC, and Emacs will provide good highlighting, semantic completion, nice
> formatting", then that would be a very strong selling point for GCC as
> well as Emacs.

It cannot be Emacs's task to provide selling points for GCC, exactly
as GCC doesn't provide selling points for Emacs.  If GCC acquires
these features, it will make sense to add support for them in Emacs;
but as long as it doesn't, no one can or should ask Emacs to sell GCC
by refraining from using a similar tool that already exists in Emacs.
No project can be requested to be that altruistic.

> And that's exactly because it would avoid duplication of work.  However,
> it would also require incremental parsing to be really good.  Could an
> incremental and/or differential parser (reparse just part of a file and
> update all info about the whole compilation unit) be fit in the GCC
> framework?  An interesting starting point would be, of course, trying to
> make Bison skeletons that work for that purpose.  Unfortunately, the
> highest-profile languages by GCC don't use Bison IIRC.

It is IMO impractical to expect that this particular development will
be advanced by Emacs.  Emacs is the main interested party in this
development, but our knowhow is nowhere near what is needed for any
serious hacking of GCC internals, especially on the level of GIMPLE
representation.

By contrast, improving infrastructure for this written in Emacs Lisp
is a much more practical solution, especially since it already exists
and does its job.  It is IMO silly not to exploit the potential we
have there.

> An any rate, it is a much more realistic goal to get 60% of all computer
> users to use GCC than it is to get 60% of all computer users to use
> Emacs.

That's not the correct comparison, IMO.  We are talking about a user
who already has Emacs and uses it, and who will be using it even if
those advanced features will not be available.  When that user doesn't
have, or cannot use GCC, asking her to install GCC is not practical at
best.

> We have the statement here (and far too little attention has been paid
> to it) that -fdump-xref and associated programs of the GNAT project
> would do the trick for the editing task currently at issue.  So there is
> a prototype people could be testing and experimenting with instead of
> doing flame wars.

I agree that prototyping and comparative testing would be a much
better use of time and efforts invested in this discussion (and many
others similar to it).  But the question that bothers me is what would
be the next step?  It is almost certain that trying to use that option
will discover shortcomings -- who will fix them when they are found?
Unless GCC as a project supports that option and is willing to
maintain and improve it, we are again at a dead end.

> > This is IMO
> > the preferred direction: make Emacs features depend on nothing but
> > Emacs packages. [...]
> > If we need policy decisions in this matter, _that_ is the only one
> > that should be made.  To me, it is almost a no-brainer; I wonder why
> > it is not clear-cut to others here.
> 
> Well, that is not really much in need of a policy since Emacs can
> support multiple feature sets.

Emacs can only support features that exist for which the corresponding
front ends were written in Emacs Lisp.  I don't quite see those
queuing up for providing the features we are discussing.  So there are
no multiple feature sets to support, as yet.

When several potential ways exist for implementing a feature, it is
the task of the project leadership to define the preferences, and then
encourage volunteers to go in those directions that are preferred.
These are the policy decisions I alluded to.  They should remove the
confusion over what we want as a project, and let volunteers work in
those directions without risking that their work will not be used.

> I would prefer if we needed no policy decisions at all in this
> matter.  We don't get that, obviously.  But my next preference is to
> have GCC move/develop in a manner where we would not have needed a
> policy decision.

I think it is impractical to base our development on something
extremely non-trivial that another project needs to do.  Read the GCC
mailing lists, and you will see that the current focus of the project
is very different.  Why should we build our plans on the slim hope
that this focus will change?  It makes very little sense to me.

OTOH, we have a potentially viable solution at our fingertips, and we
have it _now_.  Why trade that for some unsubstantiated hope?

> In other words: things are going wrong with GCC policies upstream
> regarding reusability in Free Software applications that Emacs, as one
> compiler user, is too small too fix.

And we shouldn't.  If GCC acquires these features, we should support
them then, but no earlier.

> If this is not approached in a more general manner in GCC, we'll have
> this problem reoccuring in various iterations on the Emacs list, and it
> will be reoccuring for the maintainers other Free Software which will
> then choose to pick non-copyleft compilers entirely instead of playing
> mix-and-match games or writing their own parsers.

This is a GCC problem, and GCC as a project should solve it.  It could
also be serious enough to become a general problem for the GNU
Project, in which case the FSF should work together with the GCC
project on resolving it.

Emacs cannot do anything constructive to speed up that resolution.
The only constructive way open to us for now is to use CEDET; let's
not wait and do it sooner rather than later.  If we do that now, then
by the time GCC developers get their act together, we will either have
an alternative solution against which to measure theirs, or at least
the necessary front-end for interfacing with them, and enough knowhow
to present them with suitable requirements and to integrate their
solution into Emacs.  In both cases, we win.

The alternative is to effectively do nothing, or, worse, continue
these flame wars.