Re: Emacs contributions, C and Lisp

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Tue, 25 Feb 2014 10:41:42 +0100
>> 
>> The "annotated syntax tree" question would become more relevant for
>> things like sourcecode highlighting.  But in the interest of usefully
>> fast feedback when editing, it would likely make more sense to let Emacs
>> do the highlighting with local rules on its own and only converse with
>> GCC when it becomes necessary to resolve ambiguities (like
>> declaration/expression distinctions): GCC can only make helpful
>> suggestions regarding the last time the source code was syntactically
>> correct, so most of the time Emacs will need to go ahead with _some_
>> idea anyway.
>
> Is it certain that we actually need a compiler for that?  Did someone
> investigate whether CEDET infrastructure is capable of doing something
> like that?  Since, as you point out, a compiler will probably choke on
> syntactically incorrect input, shouldn't we try to look elsewhere?
> After all, we don't need to parse the source completely, only as much
> as needed for completion.

Nobody can parse C++ reliably.  GCC has given up on trying to teach
Bison (aka LALR(1) and then some) how to parse C++ and has implemented
its own hand-written parser.  Existing C++ compilers went through years
of bugfixing until they got things standard-compliant most of the time.
Since C++ has overloaded functions and operators and a rather complex
type conversion lattice, figuring out just _which_ fully qualified
function or operator will get called in a large composite expression is
quite a hard feat.

If you want to be able to reliably follow references to their
_corresponding_ definition, it's almost inavoidable to ask some compiler
for its opinion just what fully qualified function/operator is to be
considered to correspond to the source.

Things like indentation and syntax highlighting are somewhat more
amicable since overloading resolution does not influence things like
expression priorities.

-- 
David Kastrup