Re: Emacs contributions, C and Lisp

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Tue, 25 Feb 2014 23:36:33 +0100
> 
> 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'.

Would it be so bad if it showed 2 candidates instead of one?

And what happens if you add

  B baz(char);

to the above -- will it show 2 candidates or just one?

> 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.

I don't know why you are saying this.  E.g., a "parser armed with some
ad-hoc heuristics" that we have in ebrowse seems to be able to catch a
significant subset of C++, certainly of C++ that existed when ebrowse
was written.  Why couldn't we base this feature on an extended ebrowse
engine?

ECB also supports mart completion.  4 years ago people complained that
it's slow, but machines became faster since then, so perhaps things
are not so bad now, and we could use Semantic for this purpose.

> >> 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...

Are there any Emacs packages that support those features?

> One was already mentioned by Stephen Leake: refactoring.

The only Emacs package for this that I could find is proprietary
(Xrefactory).  Do you happen to know about any free ones?

> 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.

Doesn't ECB already support such features?

> > 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.

Only if you need to be 110% accurate, which is certainly a requirement
for a compiler.  But we don't need such strict requirements for the
features we are discussing, I think.

> >> 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.

I'm trying to keep this part of the thread out of politics and into
something that could hopefully lead to a working implementation.