Re: Emacs contributions, C and Lisp

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I understand the potential difficulties, but since we only need a
>> > relatively small part of parsing,
>> 
>> Why do we need a small part of parsing? For implementing C++ smart
>> completion on a reliable way, you need semantic analysis.
>
> Can you explain why?  I'm probably missing something.

See this simple example:

struct A {
  int foo();
};

struct B {
  int bar();
};

A baz(int);
B baz(A);

int quux(char c) {
  return baz(c). ???????????
}

For knowing the correct completion candidates at the point indicated by
the question marks you need to know which `baz' overload to choose,
which in turn requires to know that `c' is a `char' and then knowing
that a `char' is acceptable by the `baz' overload that takes an `int'.
Therefore you know that the correct `baz' overload returns an `A' and
therefore the list of completion candidates is `foo'.

Even this very simple case requires knowing the semantics of C++. Even
if this looks approachable by a parser armed with some ad-hoc
heuristics, those will surely fail by just adding/modifying a couple of
lines on the test case above, unless those heuristics implement semantic
analysis under cover.

>> Furthermore, people here are talking too much about completion
>
> Well, that's the only thing that clang has that prompted this thread,
> right?

Clang provides code completion as a sample of its capabilities.
Clang/LLVM in fact is a set of libraries for dealing with C/C++ code.
You can use those libraries for code completion and for any other
feature that requires accessing/processing information contained on
source code: extracting declarations, sanitizing, instrumenting,
optimizing, generating object code...

>> but there are other features that require whole-program semantic
>> analysis and hence are out of reach of the approaches mentioned here
>> based on gcc spitting not-quite-comprehensive information.
>
> Can you list those features?

One was already mentioned by Stephen Leake: refactoring. Actually,
anything that requires semantic knowledge of the source code you are
working on. You could ask for a listing of places dependent of word
size, for instance, or highlight the places where certain idiom is used.

>> > perhaps it's worth trying first?  If push comes to shove, what was
>> > implemented in GCC can be reimplemented in Emacs Lisp, no?
>> 
>> Right now the available systems for smart code completion are annoyingly
>> slow. They are implemented on C/C++. It is reasonable to expect from a
>> Elisp-based solution to be unbearably slow, not to mention the
>> complexity.
>
> We can always prototype in Lisp, then reimplement the slow parts in C
> if needed.

IIRC I already told you this a few weeks ago, but I'll repeat: a C++
front-end (even without code generation capabilities) requires an
immense amount of work from highly specialized people, and then needs
improvements as new standards are published.

>> Why reinvent the wheel?
>
> Because we cannot get the one that's already invented?

"we cannot" isn't the right expression. "we are not allowed" is the
correct description.

As others pointed out, the cat is out of the bag. Emacs will have
Clang-based features provided as external packages. Sincerely, I don't
care much if the Emacs project does not allow those features into the
core distribution or ELPA. People will install them from alternative
repositories, that's all.